В USB-драйвере caiaq (http://www.alsa-project.org/main/index.php/Matrix%3AMod...) найдена уязвимость (http://labs.mwrinfosecurity.com/advisories/linux_kernel_caia.../), позволяющая инициировать переполнение буфера и выполнение кода злоумышленника через подключение к работающему под управлением Linux компьютеру специально сконфигурированного USB-устройства. Используя данную уязвимость, злоумышленник может воспользоваться имеющимися в продаже недорогими программируемыми USB-платами для организации выполнения своего кода в любой системе, к USB-порту которой он может получить доступ.
Драйвер caiaq, разработанный в рамках проекта ALSA для звуковых плат компании Native Instruments, входит в базовую поставку Linux-ядра и поставляется в составе большинства Linux-дистрибутивов, включая серверные системы. Приводящая к уязвимости ошибка представляет собой (http://labs.mwrinfosecurity.com/files/Advisories/mwri_caiaq-......URL: http://labs.mwrinfosecurity.com/advisories/linux_kernel_caia.../
Новость: http://www.opennet.me/opennews/art.shtml?num=29834
Ещё одно доказательство того, что строки неизвестной длины с завершающим нулём в качестве признака конца данных этого типа данных, никуда не годятся — паскалевский тип строки с указанием точной длины в заголовке безопасный и предсказуемый.EPIC FAIL C/C++.
Ну а в PHP даже указателей нет. Так что паскалю с сями до него как пешком до Китаю..
И в Java нет , и что с того ? Недавно оба засветились с переполнениями базовых типов. Нет совершенных систем, ошибки можно найти везде.А по поводу топика - не более чем локальная уязвимость с повышением привилегий, только тяжелее в реализации по сравнению с прочими уязвимостями такого рода
> И в Java нет , и что с того ? Недавно оба засветились с переполнениями базовых типов. Нет совершенных систем, ошибки можно найти везде.Вы про баг с плавающей запятой?
Переполнения нашли в реализации интерпретатора PHP, а не в пользовательских приложениях как в этом случае. К тому же, код интерпретатора PHP написан C.
Вообще, в случае Java/PHP и им подобных достаточно исправить переполнение в сам компиляторе/интерпретаторе, в случае C вся ответственность ложиться на плечи разработчиков приложений. Панацеи пока нет, а хотелось бы - лично я вижу решение в мощном безопасном рантайме (минимиизирует ошибки на низком уровне) и мощной системе типов (минимизирует ошибки на всех уровнях).
C/C++ изначально создавались как языки сочетающие в себе высокий уровень программирования и низкоуровневую эффективность. Ответственность за содеянное лежит на программисте. Хочешь быстро ехать - отключай ABS, ESP, traction control и пр.. Новичок разобъётся, профессионал даст нужный результат. В конце концов если молотком ударил по пальцу, то виноват не инструмент. ;-)
> C/C++ изначально создавались как языки сочетающие в себе высокий уровень программированияи низкоуровневую эффективность.
Я понимаю что историю сейчас знать ни к чему, но вообще то C лепился кое-как чтоб было хоть чуть получше ассемблера. Ну и чтоб можно было работать на компе с 8 кБ ОЗУ (отсюда и так называемый лаконичный синтаксис). Ну а C++ лепился кое-как чтоб было чуть получше С.
> Ну а в PHP даже указателей нет.но при этом в PHP забыли сделать слабые ссылоки (weak ref)... о боже -- этоже ЛОЛ:-D
таким образом PHP обречён на _цыклические_ ссылочные _сильные_ связи :-) :-) :-) [что совершенно не важно если приложение не должно жить более чем пару десятков милисекунд. поэтому всем php-web-программистом пофиг на отсутствие weak refs :-), а вот написать долгоиграющщую не-web-программу уже не получится :-)]
Языки из разных категорий. Сравнивать их может только новичек в программировании =)
Кто такие новичеки?
>Ну а в PHP даже указателей нет. Так что паскалю с сями до него как пешком до Китаю..Оберон - наше всё!
> Ну а в PHP даже указателей нет. Так что паскалю с сями до него как пешком до Китаю..Это Вам наверное в PHP порушенные поинтеры не встречались, а мне как-то довелось с ними пободаться - когда по ходу встроенной функции по какой-то причине генерируется warning, изза этого переаллоцируется стек, а локальные переменные уже хранят указатели на прошлый stack frame. Вот результаты скрипта потом весело выглядят :)
Да, в 5.3 это исправили.
Ок, для успешной индексации строк с over 2 млрд. символов всегда надо будет хранить лишних 4 байта, для любой строки, удачи !
> Ок, для успешной индексации строк с over 2 млрд. символов всегда надо
> будет хранить лишних 4 байта, для любой строки, удачи !да хоть 8 байт, хоть 32-а, это один фиг лучше, чем рут полученный через переполнение.
Т.е. хранить 32 байта с длинной строки, когда сама строка занимает один байт это нормально?
Поле длины строки необязательно должно быть фиксированной длины — есть алгоритмы кодирования длины произвольной последовательности. И лучше, чтобы оно всё-таки было в заголовке данных, а не в конце в виде завершающего нуля, чтобы ядро не занималось счётом байтов и динамическим перевыделением памяти под неизвестное число байтов, пока не будет считан последний байт строки, а заранее знало, сможет оно вместить всю строку в доступную память или нет.
> есть алгоритмы кодирования длины произвольной последовательности.Это дополнительная сложность и время. Спорный оверхед, в общем. Может где-то и нужно, в большинстве применений - нет.
>> есть алгоритмы кодирования длины произвольной последовательности.
> Это дополнительная сложность и время. Спорный оверхед, в общем. Может где-то и
> нужно, в большинстве применений - нет.а перераспределение памяти и поиск конца строки это не лишние ресурсы?
Проще разработать 1024битную архитектуру с sizeof(int) == 1024, запихать туда 2^1024 ОЗУ и не парится храня там ежесекундные снапшоты вселенной.
> Поле длины строки необязательно должно быть фиксированной длины — есть алгоритмы
> кодирования длины произвольной последовательности.... только парсить долго :) а теперь представь что тебе придется рюхать миллион таких полей? А миллиард не хочешь? Не как тупо 1 регистровую операцию, как раньше, что быстро, а как целая уйма хитрых операций с регистрами и прочая, т.к. проц не умеет нативно работать с таким представлением.
>> Поле длины строки необязательно должно быть фиксированной длины — есть алгоритмы
>> кодирования длины произвольной последовательности.
> ... только парсить долго :) а теперь представь что тебе придется рюхатьЧто парсить? Как рюхать?
> миллион таких полей? А миллиард не хочешь? Не как тупо 1
Да чо уж там, берите сразу триллион - он в тыщу раз внушительнее миллиарда звучит.
> регистровую операцию, как раньше, что быстро, а как целая уйма хитрых
> операций с регистрами и прочая, т.к. проц не умеет нативно работать
> с таким представлением.Так бы и написали: "Все это очень сложно и очень затратно. Правда-правда."
>> ... только парсить долго :) а теперь представь что тебе придется рюхать
> Что парсить? Как рюхать?Я так понимаю что изен про кодирование интегеров с переменной длиной или типа того. Бывает такое, можно и правда закодировать интегер произвольного диапазона более компактно чем обычно. И такое кодирование часто попадается в транспортных протоколах двинутых на компактности любой ценой :). Расплатой за это обычно является некоторая геморность парсинга всего этого - на реконструкцию интегера из такой конструкции требуется несколько лишних операций. Одно дело погрузить в регистры проца число "как есть" и другое - пачка хитрых преобразований чтобы понять какой реально размер у variable-length integer и получить его в нормальном виде понятном процу. В итоге выигрывается в занимаемом числом месте (в байтах) - малые числа получаются короче. Но проигрывается в трудоемкости разбора этого представления.
>> миллион таких полей? А миллиард не хочешь? Не как тупо 1
> Да чо уж там, берите сразу триллион - он в тыщу раз
> внушительнее миллиарда звучит.А тут все просто: вы не заметите 10 микросекунд вместо 1. Зато вы легко заметите 10 часов вместо 1 часа. Хотя в обоих случаях разница в все те же 10 раз, совершенно одинаковые ;)
> Так бы и написали: "Все это очень сложно и очень затратно. Правда-правда."
Ну одно дело тупо затолкать число в регистры (в лучшем случае аж 1 команда проца будет), а другое varibale-length кодирование сперва расколупать для этого :). Как бы будет некоторая разница в числе команд которые потребны для одного и того же действа - некое число доступно теперь процу для обработки в виде который был изначально задуман :)
> Я так понимаю что изен про кодирование интегеров с переменной длиной или
> типа того. Бывает такое, можно и правда закодировать интегер произвольного диапазона
> более компактно чем обычно. И такое кодирование часто попадается в транспортных
> протоколах двинутых на компактности любой ценой :). Расплатой за это обычноОн вообще-то о строках, как я понял. В нормальных языках это происходит просто: вы параметризуете строковый тип максимальным размером строки, а компилятор выбирает, сколько байт под величину размера выделить. Не говоря о наличии возможности работать с нуль-терминированными строками и прочей ересью, если приспичило.
> А тут все просто: вы не заметите 10 микросекунд вместо 1. Зато
> вы легко заметите 10 часов вместо 1 часа. Хотя в обоих
> случаях разница в все те же 10 раз, совершенно одинаковые ;)Это спекуляции о постороннем, но я таки замечу, что на современных суперскалярах всё не так очевидно, как в листинге ассемблера. Хотите узнать оверхед, надо профилировать, а не спекулировать.
> Он вообще-то о строках, как я понял.Я так понял что он предлагал хранить длину строки как variable length integer?
> В нормальных языках это происходит просто: вы параметризуете строковый тип
> максимальным размером строки, а компилятор выбирает, сколько байт под
> величину размера выделить.А при нужде интероперабельно с остальными слить это на диск в файл или передать по сети в *предсказуемом* виде, который потом ремота/другая программа сможет распарсить без привязки к языку, платформе, етц - мы жесточайше факаем мозг, делаем не слишком тривиальные преобразования и что там еще, в общем как обычно. Известное дело, ага. Не, ну можно конечно себе поднасрать на ровном месте, затребовав сложную сериализацию-десериализацию, но это похоже на создание себе проблем сначала, а потом героическую борьбу с ними. Нахрена бы? :)
> Не говоря о наличии возможности работать с нуль-терминированными строками
> и прочей ересью, если приспичило.Ну, эта ересь как-то исторически прижилась, поэтому она есть. Если так придираться, UTF-8 с его переменным числом байтов на символ - тоже не подарок, только вот кодировать каждую букву как 32 или более битов ради того чтобы японцы/китайцы могли свои иерглифы пропихивать - жирновато будет, не? :)
> Это спекуляции о постороннем, но я таки замечу, что на современных суперскалярах
> всё не так очевидно, как в листинге ассемблера.Ессно, зависит от, но в общем случае чем больше инструкций, обращений к памяти и прочая - тем дольше они выполняются. И чем жирнее код - тем меньше шансов что он целиком попадет в кеш и резко выиграет в скорости.
> Хотите узнать оверхед, надо профилировать, а не спекулировать.
Ну да, всякие там жабисты любят дрюкаться с профайлером: их софт вечно тормозит, поэтому они зеленеют в профайлерах намного больше чем сишники/сиплюсплюсники, я это заметил, ыгы :))). И главное почему-то никто не пишет критичные к скорости программы на этих ваших крутых и правильных языках. Почему-то игры, сжатие, шифрование, кодеки, ну 3D и прочая навернутая математика которую надо в реалтайме успевать - все как одно на сях или плюсах. Хотя казалось бы JIT дает кучу теоретических преимущесв и что там еще. Обычно умудряются эти преимущества легко похерить кучей рантайм проверок, излишне задрюканными сущностями типа "интегер - это объект" и прочими наворотами.
>> Он вообще-то о строках, как я понял.
> Я так понял что он предлагал хранить длину строки как variable length integer?Грубо говоря, я предложу такую структуру:
struct String {
len_of_len; //длина поля длины в байтах
len_of_data;//поле длины строки в символах
data;//ссылка на контейнер данных перечислимого типа [1...len_of_data]
}Плюсы такой структуры:
+ независимость структуры от базовых типов short, int, long, ограничивающих длину строки и отсутствие избыточности служебной информации для коротких строк;
+ элементы данных строки счётны от 1 до len_of_data без нужны вычислять конец строки и идиотского "нулевого элемента", принятого в C для элементов массива (по-мне, так символы в строке — это не массив!);
+ контейнер данных может поддерживать любой доступ к элементам строки (хранить разреженные строки, например), но перечислимость [1...len_of_data] элементов должен обеспечивать — это даёт нам гибкость в абстрагировании от конкретной реализации контейнера.
>> Он вообще-то о строках, как я понял.
> Я так понял что он предлагал хранить длину строки как variable length
> integer?
>> В нормальных языках это происходит просто: вы параметризуете строковый тип
>> максимальным размером строки, а компилятор выбирает, сколько байт под
>> величину размера выделить.
> А при нужде интероперабельно с остальными слить это на диск в файлТрололо, придумаем проблему и выделим ей абзац в нашей простыне.
> или передать по сети в *предсказуемом* виде, который потом ремота/другая программа
Ха, данные по сети всегда передаются с таким оверхедом по заголовкам, что сравнивать его с 32/64-битной величиной длины строки - вообще срам. ;)
> сможет распарсить без привязки к языку, платформе, етц - мы жесточайше
> факаем мозг, делаем не слишком тривиальные преобразования и что там еще,Это всё чушь. Поточная сущность ввода-вывода позволяет подставить любые заголовки до или после строк. Хоть терминировать '\0', хоть записать размер в беззнаковое целое - как угодно. А уж вес этих операций делает любые разговоры об оверхеде на пару-тройку операций с двойным словом просто неприличными. Это всё троллинг. iZEN вообще всех затроллил - начал тред и сел смотреть на массакр. :)
> в общем как обычно. Известное дело, ага. Не, ну можно конечно
Угу, да. Не, ну конечно же можно.
> себе поднасрать на ровном месте, затребовав сложную сериализацию-десериализацию, но это
> похоже на создание себе проблем сначала, а потом героическую борьбу с
> ними. Нахрена бы? :)Вот именно, нахрена бы?
> Ну, эта ересь как-то исторически прижилась, поэтому она есть. Если так придираться,
Вы уже определитесь, вам ASCIIZ-строки не нравятся или их альтернативы? ;)
> UTF-8 с его переменным числом байтов на символ - тоже не
Вот уж где оверхед, так это парсинг не-ASCII текста в UTF-8! Правда, даже этот оверхед в большинстве случаев ничего не решает, и мы тут просто троллим порожняком.
> подарок, только вот кодировать каждую букву как 32 или более битов
Кодировать! О, кошмар! О, ужас!!!1 Бегом переходить на UTF-8 за полчаса - уж там-то, наверное, кодирования нет. ;)
> ради того чтобы японцы/китайцы могли свои иерглифы пропихивать - жирновато будет,
> не? :)Гы. Лол.
>> Это спекуляции о постороннем, но я таки замечу, что на современных суперскалярах
>> всё не так очевидно, как в листинге ассемблера.
> Ессно, зависит от, но в общем случае чем больше инструкций, обращений кТролололо в общем случае.
> памяти и прочая - тем дольше они выполняются. И чем жирнее
> код - тем меньше шансов что он целиком попадет в кеш
> и резко выиграет в скорости.И чем дольше, тем жирнее, ага. ;)
> Ну да, всякие там жабисты любят дрюкаться с профайлером: их софт вечно
> тормозит, поэтому они зеленеют в профайлерах намного больше чем сишники/сиплюсплюсники,
> я это заметил, ыгы :))). И главное почему-то никто не пишет
> критичные к скорости программы на этих ваших крутых и правильных языках.Потому что пока правильные языки проектировались с учётом требований и обязывали производителей компиляторов к стандартизации для применения торговых марок-названий языка, академическое сообщество весело и задорно клепало экосистему Си-подобных языков, включая ОС, и её апологетов, привлекая внимание индустрии к тому, что уже освоено и "is just good enough".
> Почему-то игры, сжатие, шифрование, кодеки, ну 3D и прочая навернутая математика
> которую надо в реалтайме успевать - все как одно на сяхНа ассемблере.
> или плюсах. Хотя казалось бы JIT дает кучу теоретических преимущесв и
Или фортране. Алсо, спидфаг детектед.
> что там еще. Обычно умудряются эти преимущества легко похерить кучей рантайм
> проверок, излишне задрюканными сущностями типа "интегер - это объект" и прочими
> наворотами.Потому что спидфаги нихрена не целевая аудитория мелких транснациональных конторок, которые клепают эти платформы. Что в позе неуловимых Джо позволяет первым прокачать ЧСВ и набухнуть от чувства сопричастности с Самым Быстрым Языком (нужный подчеркнуть).
> Потому что спидфаги нихрена не целевая аудитория мелких транснациональных конторок,
> которые клепают эти платформы. Что в позе неуловимых Джо позволяет первым прокачать ЧСВ > и набухнуть от чувства сопричастности с Самым Быстрым Языком (нужный подчеркнуть).я бы посмотрел, как мир бы тужился с виндоус и линукс на джаве или питоне,
спидфаги, говоришь, хреновы?
>> Потому что спидфаги нихрена не целевая аудитория мелких транснациональных конторок,
>> которые клепают эти платформы. Что в позе неуловимых Джо позволяет первым прокачать ЧСВ > и набухнуть от чувства сопричастности с Самым Быстрым Языком (нужный подчеркнуть).
> я бы посмотрел, как мир бы тужился с виндоус и линукс на
> джаве или питоне,
> спидфаги, говоришь, хреновы?Когда я пишу "другие низкоуровневые языки", обвиняют в отсутствии конкретики, когда пишут "Ада", переводят разговор на джавы и питоны. Что за жизинь, э! ;)
Удивительно, но в ядре "вражеской" системы от МС этот тип строк используется повсеместно. Наверняка там работают тупые придурки, которые для безопасности пространства ядра бездарно тратят целых 2 байта на строку. (там для длины строки используется word тип)
Ну и как, сильно безопасное получилось?
> Ну и как, сильно безопасное получилось?Несильно, ибо строки не единственная и даже не самая серьёзная проблема си.
> Несильно, ибо строки не единственная и даже не самая серьёзная проблема си.Да уж. Индусы успешно доказывают что обделаться с критичными последствиями можно и на яве, питоне, пхп, [insert your favorite language here]. Ну не переполнение буфера так ремот инклюд, sql иньекция, XSS, CSRF ... - вам как, сильно полегчало? Ну упрет хацкер 100500 аккаунтов от гмыльников, фэйсовконтактов и прочая и вообще базу похерит/изменит, наприер - не факт что это нанесет меньше ущерба чем какое-то там переполнение буфера. В конечном итоге хакерье нынче давно уже не интересует возможность выполнить код ради возможности выполнить код. Это их интересует чтобы поиметь профит или данные пользователей. И возможность с дикими извращениями при физическом доступе к машине поиметь доступ к 1 машине - далеко не самая страшная дырень в свете таких реалий. Куда моднее массовое, ремотное поимение, bulk-рассылка спама, массовой кражи конфиденциальных и ценных данных, при том первое как правило нужно в основном для второго и третьего. Самое странное в этом то что дыры в сишном коде при работе с сетью встречаются весьма редко - дыр в web-приложениях например почему-то в 100500 раз больше оказывается. Хотя, казалось бы, переполнений буферов нет, стек хрен сорвешь, ну что еще этим ... не хватает для безопасного написания программ?!
> Т.е. хранить 32 байта с длинной строки, когда сама строка занимает один
> байт это нормально?блин - проверка должна быт ьи в функцию должна передаваться длина строки
> блин - проверка должна быт ьи в функцию должна передаваться длина строкиКонечно должна. Это же какой контроль!
> Т.е. хранить 32 байта с длинной строки, когда сама строка занимает один
> байт это нормально?Ненормально - путать биты с байтами и забывать о возможности параметризации типов.
> Ок, для успешной индексации строк с over 2 млрд. символов всегда надо будет хранить лишних 4 байта, для любой строки, удачи !А тебе успешного выяснения длинны строки. Жди когда найдет заветный байт в 2хгиговом куске данных
> А тебе успешного выяснения длинны строки. Жди когда найдет заветный байт в
> 2хгиговом куске данныхА в чем принципиальная разница по скорости: проверять ли байт на то что он равен нулю, и если да - то забить, или проверять что счетчик байтов дотикал до нужного значения, и если равен - то забить? С точки зрения трансформации в машинный код - получится примерно одинаково. С точки зрения попадания в кещ - по идее в него не попадет только 2Гб данных, остальное уместится даже в самый мизерный в кеш. Я что-то упустил и в каком-то месте наступает зверский профит?
В некоторых алгоритмах желательно иметь длину строки заранее, например, для склеивания двух строк должна быть известна длина первой, т.е. имеем бесполезное пробегание циклом по строке. В результате, если надо склеить 10 строк по 10 символов, получаем 10*(1+2+...+9) = 450 чтений символов. Для 100-символьной строки замедление в 6 раз, круто? )
> В некоторых алгоритмах желательно иметь длину строки заранее, например, для склеивания
> двух строк должна быть известна длина первой,Это только в том (относительное редком) случае, если destination совпадает с первой строкой, там есть достаточно места куда можно отрастить результат и допустимо менять содержимое. Хотя черт с вами, уговорили, можно таскать счетчик отдельно и иногда это и правда будет эффективнее. А какая проблема сделать это на си если такая задача есть и ее скорость критична? :) А то что все и вся не пихают по дефолту - ну так если впихать все и вся по принципу "а вдруг пригодится?!" - получится еще одна ява, где можно уснуть пока hello world стартанет...
>> В некоторых алгоритмах желательно иметь длину строки заранее, например, для склеивания
>> двух строк должна быть известна длина первой,
> Это только в том (относительное редком) случае, если destination совпадает с первой
> строкой, там есть достаточно места куда можно отрастить результат и допустимо
> менять содержимое. Хотя черт с вами, уговорили, можно таскать счетчик отдельно
> и иногда это и правда будет эффективнее. А какая проблема сделать
> это на си если такая задача есть и ее скорость критична?Проблема в том, что в сях оно будет не на уровне компилятора, а где-то "сбоку" в левой библиотечке, о которой многие разработчики будут не в курсе, и будут писать собственные велосипедики, несовместимые с ней.
>> В некоторых алгоритмах желательно иметь длину строки заранее, например, для склеивания
>> двух строк должна быть известна длина первой,
> Это только в том (относительное редком) случае, если destination совпадает с первой
> строкой, там есть достаточно места куда можно отрастить результат и допустимоА если не совпадает, длину обеих строк не обязательно знать для выделения буфера под результат, ага-ага. ;)
> менять содержимое. Хотя черт с вами, уговорили, можно таскать счетчик отдельно
> и иногда это и правда будет эффективнее. А какая проблема сделать
> это на си если такая задача есть и ее скорость критична?Проблема не в том, чтобы сделать это на Тюринг-полном языке, а в том, что что решение получится относительно неудобным. Можно вообще проставить вопрос, зачем Си если есть лисп, фортран и ассемблер?
> :) А то что все и вся не пихают по дефолту
> - ну так если впихать все и вся по принципу "а
> вдруг пригодится?!" - получится еще одна ява, где можно уснуть пока
> hello world стартанет...Закупайте Фейри в цистернах. :Р
> А если не совпадает, длину обеих строк не обязательно знать для выделения буфера под результат, ага-ага. ;)А если не совпадает, обе строки пробегаются в любом случае, и разницы по времени никакой, что со счетчиком, что без.
Другое дело, что это далеко не каждый случай. В том же примере со строками 10х10 очень накладно будет перебрасывать строки между буферами туда-сюда, выделять память каждый раз, это же страшно медленно, лучше заранее выделить буфер с запасом. Существует рекомендация выделять память блоками по 2^N байт, это здорово сокращает фрагментацию и количество выделений-освобождений, при этом прога сжирает максимум вдвое больше памяти, чем ей реально нужно.> Проблема не в том, чтобы сделать это на Тюринг-полном языке, а в том, что что решение получится относительно неудобным. Можно вообще проставить вопрос, зачем Си если есть лисп, фортран и ассемблер?
Стандарт скоро не перепишешь, а отдельно взятый компилер (GCC) - запросто. В настройках компиляции переключатель типов строк по умолчанию, и строковая библиотека в двух вариантах.
> А если не совпадает, обе строки пробегаются в любом случае, и разницы
> по времени никакой, что со счетчиком, что без.Не в любом случае, а в ряде случаев. В любом случае как раз нужно знать длину каждой строки ("пробежаться" по обеим один раз), выделить буфер размером с обе и "пробежаться" по строкам второй раз, при копировании.
> Другое дело, что это далеко не каждый случай. В том же примере
> со строками 10х10 очень накладно будет перебрасывать строки между буферами туда-сюда,Обсуждение абстрактных алгоритмов класса "туда-сюда" вносит конструктив и способствует взаимопониманию.
> выделять память каждый раз, это же страшно медленно, лучше заранее выделить
> буфер с запасом. Существует рекомендация выделять память блоками по 2^N байт,
> это здорово сокращает фрагментацию и количество выделений-освобождений, при этом прога
> сжирает максимум вдвое больше памяти, чем ей реально нужно.Я так понял, когда та же джава разом выделяет память под кучу, сишники тычат в неё пальцами и сравнивают такой расход памяти с утечками. А прижмешь их на предмет эффективной работы со строками, начинают рассказывать о преаллокации и оверхеде "максимум вдвое больше". Очень показательно.
Наверное, если спросить про сериализацию строк с предварительным указанием размера в заголовках (тот же HTTP), они будут рассказывать о хранении длины в структурах и массивах. Ведь это же так медленно, пересчитывать её каждый раз! Поэтому в Си всё быстро, и контроль полный (ну ведь можно же хранить в структурах, кто не даёт-то?). То ли дело в других языках - всё джавой накрылось и дотнет полный.
> Стандарт скоро не перепишешь, а отдельно взятый компилер (GCC) - запросто. В
> настройках компиляции переключатель типов строк по умолчанию, и строковая библиотека в
> двух вариантах.Дооо, нужно просто допилить GCC, добавить строковый тип (который не нужен, ведь оверхед максимум вдвое больше!), и всё пучком. Других проблем нет.
> Не в любом случае, а в ряде случаев. В любом случае как раз нужно знать длину каждой строки ("пробежаться" по обеим один раз), выделить буфер размером с обе и "пробежаться" построкам второй раз, при копировании.
strcat не выделяет память. И я вроде уже писал, что выделять каждый раз память зело накладно, особенно если заранее известна предельная длина результата.
> Обсуждение абстрактных алгоритмов класса "туда-сюда" вносит конструктив и способствует взаимопониманию.
См выше. Попробуйте представить, что будет в том примере 10х10, если каждый раз под результат будет выделяться память, и оцените быстродействие. Помимо указанной задержки в 6 раз на лишнее копирование/пробегание будет задержка при выделении огрызков 10, 20, ..., 90, 100 байт, которые по окончании операции станут не нужны и освободятся, отлично фрагментировав память. Неужели не проще выделить буфер на 100 байт _один раз_ и работать с ним?
> Я так понял, когда та же джава разом выделяет память под кучу, сишники тычат в неё пальцами и сравнивают такой расход памяти с утечками. А прижмешь их на предмет эффективной работы со строками, начинают рассказывать о преаллокации и оверхеде "максимум вдвое больше". Очень показательно.
Это вы сами с собой разговариваете? Красиво у вас там все, должно быть, черт побери
> Дооо, нужно просто допилить GCC, добавить строковый тип (который не нужен, ведь оверхед максимум вдвое больше!), и всё пучком. Других проблем нет.
Вас сишники в магазине что ли обвешали? Или в детстве отнимали деньги на обеды?
> strcat не выделяет память. И я вроде уже писал, что выделять каждыйЕщё бы выделял. Всё руками.
> раз память зело накладно, особенно если заранее известна предельная длина результата.
Накладно, но всегда возможно или допустимо, в отличие от преаллокации по оценке сверху. И давайте без strcat как-то уже. Или проверку на выход за границы буфера в общем случае тоже можно не делать? :) Алсо, с вами скучно троллить.
> выделить буфер на 100 байт _один раз_ и работать с ним?
В этом случае проще. А когда нужно дать отлуп пользователю (источнику входных данных), если результат не вместится в буфер? Предложите начать копировать, а ошибку вернуть в случае заполнения буфера? Нет, вы спросите, что мешает пользователю передать размер строки вместе со строкой (как собственно и происходит чаще всего). То есть, предложите так или иначе пробросить передачу размера по всей цепочке вызовов. Мол, пользователь знает длину строки, поскольку он её откуда-то получил, вот пусть и передаст. И вроде бы проблема решена, но традиционно для Си - нагибая пользователей API. А если API чего-то не предусматривает (плохие проектировщики изначально сделали его простым) - это не проблема языка. Ведь так?
И потом, конкатенация - частный случай. Как думаете, сложно найти задачу по эффективной работе со строками, для которой придётся переизобрести строки с хранимой длиной? С подстроками у си как? Ах, ну да: изобретаем свой структурный тип (не совместимый с нуль-терминацией и стандартными функциями), и всё замечательно. Полный контроль. И не рассказывайте мне, что таких задач нет - есть, решал пару месяцев назад и плевался.
> Это вы сами с собой разговариваете? Красиво у вас там все, должно
> быть, черт побериЭто я рассуждаю вслух. Вам, вот, повод поёрничать дал. А вы продолжайте, не стесняйтесь - ваши догадки о причинах моей нелюбви к Си весьма любопытны.
> Вас сишники в магазине что ли обвешали? Или в детстве отнимали деньги
> на обеды?Ну конечно же дело во мне. Придумал проблемы, которых нет.
А если мне нужна строка > 255 символов? Думай прежде, чем писать
учил turbo pascal? Выходи из анабиоза, есть строки в паскале превышающие 255...>Думай прежде, чем писать
ты хотя бы думай. Хоть когда нибудь.
ну и какое отношение имеют стандартные библиотеки C, которые ориентрируются на терминирующий нулевой символ к коду ядра линукс, где этих библиотек нет и быть не может? не надо путать язык и используемые им библиотеки. да, покормил.
прошу прощения, невнимательно читал новость.
>связанный с использованием для копирования содержимого строки небезопасной функции strcpy(), вместо учитывающего длину строки варианта strlcpy().таки они скопировали часть функций в ядро. впрочем, всё равно, это недостаток этих функций, а никак не языка.
> таки они скопировали часть функций в ядро. впрочем, всё равно, это недостаток
> этих функций, а никак не языка.Конечно-конечно. Уж в языке-то есть тип данных, позволяющий отказаться от ручного управления границами. И стандарт на библиотеки есть, и их реализаций - пруд пруди. А виноваты программеры, да.
ВНЕЗАПНО! И С, и тем более С++ позволяют реализовать строку именно так, как вам это нужно.
С любыми проверками и любой оптимизацией - по вкусу. Без хитрых хаков для кривых костылей...
Именно так! А еще, в ряде случаев, можно сделать проверки длин и расстановку защитных '\0' в концах массивов ДО вызова продедур копирования/сравнения/и т. п. и не тратить время на лишние проверки на каждой итерации циклов.
> ВНЕЗАПНО! И С, и тем более С++ позволяют реализовать строку именно так,
> как вам это нужно.
> С любыми проверками и любой оптимизацией - по вкусу. Без хитрых хаков
> для кривых костылей...Особенно в Си. Прямо бери и реализуй литералы и неявные преобразования типов. Ага, ну-ну. А в С++ кроме строк проблем нет, конечно же - полный контроль над адресной арифметикой, ага. Ну-ну. ;)
Вы не любите языки, на которых нельзя написать фреймворк и сделать вид, что это другой язык? Тогда низкоуровневые языки просто не для вас.
Проблема, которую вы пытаетесь придумать, решается одной функцией. Если в вашем коде используется только определенный вами тип строк и любая входящая строка преобразуется к вашему типу через одну, предусматривающую вероятность переполнения, функцию, то в вашем коде переполнения строки не будет. Вот и все...
> Вы не любите языки, на которых нельзя написать фреймворк и сделать вид,
> что это другой язык? Тогда низкоуровневые языки просто не для вас.Пляска вокруг убогой системы типов и её последствия - фамильная черта языков семейства Си. В нормальных низкоуровневых языках этого нет.
> Проблема, которую вы пытаетесь придумать, решается одной функцией. Если в вашем коде
Реальная, а не абстрактная, проблема, отсутствие которой вы пытаетесь придумать, воплощена в массе унаследованного кода. Обсуждаемая новость - об одном из её проявлений. Предлагаемые структурные строковые типы на Си - это неудобный костыль без нативной поддержки в языке и библиотеках, который используют единицы из тысяч, в лучшем случае.
> используется только определенный вами тип строк и любая входящая строка преобразуется
> к вашему типу через одну, предусматривающую вероятность переполнения, функцию, то в
> вашем коде переполнения строки не будет. Вот и все...Действительно, вот и всё: и удобно, и все пользуются, и унаследованный код сам себя переписал, и все остальные проблемы Си решились сами собой.
Фамильная черта тех, кто гонит на С - упоминание неких "нормальных языков" без конкретизации...
Каким образом людям, писавшим драйвера, удалось унаследовать у кого-то код - для меня загадка.
> Фамильная черта тех, кто гонит на С - упоминание неких "нормальных языков"
> без конкретизации...Ада.
> Каким образом людям, писавшим драйвера, удалось унаследовать у кого-то код - для
> меня загадка.А отгадка в том, что вы вынимаете слова из контекста.
Конечно! Нет унаследованного кода - нет проблемы!
> Конечно! Нет унаследованного кода - нет проблемы!Да что вы говорите! Ещё раз: у Си полно проблем помимо кривых строк. Чтобы их решить, нужно превратить Си в Cyclone. Никакой пляской с идиомами и API здесь не отделаться.
> Ада.Ну и где операционки на ней и желающие на оной их писать? Не хочу ничего сказать, но все навороты типизации и излишние умничания компилера при работе с железом будут только жесточайше МЕШАТЬСЯ, когда потребуется например загнать ровно 4 байта да еще в строго определенном endianess'е в регистры вон той железяки. И заметьте, железяка хочет только так и никак иначе. На сях это даже относительно реально делать без огроменного геморроя. Как раз в силу простоты типов и отсутствия наворотов там где они только мешаются.
> Ну и где операционки на ней и желающие на оной их писать? Не хочу ничего сказать, но все навороты типизации и излишние умничания компилера при работе с железом будут только жесточайше МЕШАТЬСЯ, когда потребуется например загнать ровно 4 байта да еще в строго определенном endianess'е в регистры вон той железяки. И заметьте, железяка хочет только так и никак иначе. На сях это даже относительно реально делать без огроменного геморроя. Как раз в силу простоты типов и отсутствия наворотов там где они только мешаются.Непосредственно загнать 4 байта в регистры вон той железяки - это примерно 0 целых хрен десятых % от трудоемкости общего кода ядра. Решается минимальным тоненьким врапером над непосредственным доступом к физической памяти/регистрам/etc хоть на ассемблере. Который вылизывается до блеска специальным стадом котов. Все остальное - это самый обычный код. В котором собственно и делают те самые неприятные ошибки самые обычные люди. И уже на этом уровне 'широкие возможности C' - это скорее геморрой нежели благо. Никому в трезвом умен и здравом сознании не приходит в голову браться писать на C действительно сложный ответственный код в 21м веке. Как минимум - выбор за C++. А зачастую и что-то куда более высокоуровневое - жаба, эрланг, те или иные скриптовые решения - зависит от конкретной ситуации. Но никак не ассемблер или C.
> Непосредственно загнать 4 байта в регистры вон той железяки - это примерно
> 0 целых хрен десятых % от трудоемкости общего кода ядра.Угу, а код драйверов вы смотреть не пробовали? Там такого кода - хоть отбавляй, и драйвера - весьма существенный кусок ядра, собссно :)
> Решается минимальным тоненьким врапером над непосредственным доступом
> к физической памяти/регистрам/etc хоть на ассемблере. Который вылизывается
> до блеска специальным стадом котов. Все остальное - это самый обычный код.Этот обычный код в основном занимается как раз довольно необычными низкоуровневыми задачами. Может я что-то и не понимаю в этой жизни, но общематематические и прикладные задачи (ака "обычный код") не являются целью ради которой делают ядра ОС. Ядра как раз по задумке именно прослойка между железом и прикладным софтом, не привязанным к железу и желательно особенностям низкоуровневой реализации конкретной ОС. Предлагаете делать врапперы в врапперах? А в тех врапперах не надо врапперов? :)
> В котором собственно и делают те самые неприятные ошибки самые обычные люди.
> И уже на этом уровне 'широкие возможности C' - это скорее геморрой нежели благо.Ну так пишите программы работающие с юсб через юзермод на чемнить высокоуровневом, правда мне почему-то кажется что это будет не самым безгеморройным начинанием :)
> Никому в трезвом умен и здравом сознании не приходит в голову браться
> писать на C действительно сложный ответственный код в 21м веке.Именно сложный - да, только странная какая-то цель: "написать сложный код". Код должен быть простым и прозрачным.
> Как минимум - выбор за C++. А зачастую и что-то куда более высокоуровневое
> - жаба, эрланг, те или иные скриптовые решения -Ну так напишите на этом кернель, а я посмотрю на параметры и подумаю - надо оно мне, или в сад. На кой хрен мне враппер между моей программой и оборудованием писаный на жабе, а? Тем более что ява - затевалась для независимости от оборудования, по поводу чего она сама нуждается в враппере, ибо там "немного забыли" реализовать свои дрова для тех же юсб-звуковух и прочая :)
> зависит от конкретной ситуации. Но никак не ассемблер или C.
Ха, вы будете учить системщиков как им надо писать кернелы? Не, хренушки, так не катит. Давайте вы сделаете ваше крутое, правильное, и на чем вам там надо? И вот когда оно всех зарулит - тогда ваш тезис "никак не ассемблер или C" и будет доказан, имхо :). Только вот высокоуровневые сложные конструкции ИМХО не очень просто и быстро трансформируются в простые наборы байтов и даже битов с которыми работает железо, если что. А приколитесь, бывают железки которые хотят, допустим не 8 и не 16 битов. А 12 битов, например. Ничему не противоречит послать по сериальной шине именно 12 битов, а вовсе не 8 или 16. Интересно было бы посмотреть как вы 12-битные слова, нативные для железки будете в высокоуровневые абстракции упаковывать и какая будет скорость враппинга всего этого :).Особенно если чипмейкер не искал легких путей и сделал так что первые 9 битов - одно поле, а еще три - другое. Во вы там наврапаетесь то :)
> Угу, а код драйверов вы смотреть не пробовали? Там такого кода -
> хоть отбавляй, и драйвера - весьма существенный кусок ядра, собссно :)Теоретики такие теоретики: на дворе XXI век, а они до сих в порты по 4 байта пишут. :D
> Этот обычный код в основном занимается как раз довольно необычными низкоуровневыми задачами.
На той же Аде все эти низкоуровневые задачи решаются быстрее и надёжнее. :Р
> Может я что-то и не понимаю в этой жизни, но общематематические
:D
> и прикладные задачи (ака "обычный код") не являются целью ради которой
> делают ядра ОС. Ядра как раз по задумке именно прослойка междуДа-да, в [s]СССР[/s] ядре линукса алгоритмов нет. :)))
> железом и прикладным софтом, не привязанным к железу и желательно особенностям
> низкоуровневой реализации конкретной ОС. Предлагаете делать врапперы в врапперах? А в
> тех врапперах не надо врапперов? :)Ну может вы что-то знаете, чего мы не знаем? Вот Аде, например, какие врапперы нужны? Они ведь нужны, да?
> Ну так пишите программы работающие с юсб через юзермод на чемнить высокоуровневом,
> правда мне почему-то кажется что это будет не самым безгеморройным начинанием
> :)Ага, лишние апи, лишние баги в ядре... Тут уж без Релифа никуда. :D
> Именно сложный - да, только странная какая-то цель: "написать сложный код". Код
> должен быть простым и прозрачным.Простым и прозрачным прям как опухшее монолитное ядро. :D
>> зависит от конкретной ситуации. Но никак не ассемблер или C.
> Ха, вы будете учить системщиков как им надо писать кернелы? Не, хренушки,Ну так и Вирт тоже учит. Давайте Вирта попинаем за академичность и отрыв от практики - это уже становится модно. :)
> так не катит. Давайте вы сделаете ваше крутое, правильное, и на
> чем вам там надо? И вот когда оно всех зарулит -Та гуано вопрос. 30 миллионов евро, и через 5 лет будет вам ядро.
> тогда ваш тезис "никак не ассемблер или C" и будет доказан,
Школоло. :Р Всех можно в контру зарулить, а ОС - они разные все, со своими достоинствами, недостатками и сферами применения. Я тут слышал тезис, согласно которому, обероны и системы на Аде, которые работают в критических промышленных и военных отраслях - это нифига не промышленный уровень. :) Промышленны - это видимо, когда много, везде, и хомячку видно. :Р
> имхо :). Только вот высокоуровневые сложные конструкции ИМХО не очень просто
> и быстро трансформируются в простые наборы байтов и даже битов сИ даже кубитов, чо уж там.
> которыми работает железо, если что. А приколитесь, бывают железки которые хотят,
Гыгы.
> допустим не 8 и не 16 битов. А 12 битов, например.
> Ничему не противоречит послать по сериальной шине именно 12 битов, а
> вовсе не 8 или 16. Интересно было бы посмотреть как вы
> 12-битные слова, нативные для железки будете в высокоуровневые абстракции упаковыватьТак 12-битные слова или байты, теоретический вы наш? :)
> и какая будет скорость враппинга всего этого :).Особенно если чипмейкер не
Враппинг!!1
> искал легких путей и сделал так что первые 9 битов -
> одно поле, а еще три - другое. Во вы там наврапаетесь
> то :)Та не говори, заврапало уже врапать (врап-врап).
> Теоретики такие теоретики: на дворе XXI век, а они до сих в порты по 4 байта пишут. :DНесмотря на XXI век, компьютер до сих пор включается в розетку и оперирует битами.
Действительно, чудовищно. Но вы не зацикливайтесь на этом, у вас-то все хорошо...
>> Теоретики такие теоретики: на дворе XXI век, а они до сих в порты по 4 байта пишут. :D
> Несмотря на XXI век, компьютер до сих пор включается в розетку и
> оперирует битами.
> Действительно, чудовищно. Но вы не зацикливайтесь на этом, у вас-то все хорошо...Да, у меня (как впрочем и у вас) дрова давно гоняют данные с/на железо в основном через прямой доступ к памяти, а портовый ввод-вывод присутствует кое-где и кое-как лишь для инициализации и переключения режимов + всякая мишура, вроде сенсоров, последовательных и параллельных портов. Но вы не зацикливайтесь на фактах... ;)
>> Ада.
> Ну и где операционки на ней и желающие на оной их писать?В гугле.
> Не хочу ничего сказать, но все навороты типизации и излишние умничания
> компилера при работе с железом будут только жесточайше МЕШАТЬСЯ, когда потребуетсяМЕШАТЬСЯ!!!!!111 8-***
> например загнать ровно 4 байта да еще в строго определенном endianess'е
Так спидфаг или не спидфаг? А то спидфаги выравнивают структуры даже на CISC-архитектурах (не имею ничего против, кстати). ;)
> в регистры вон той железяки. И заметьте, железяка хочет только так
> и никак иначе. На сях это даже относительно реально делать безИ заметьте, в Аде, в отличие от Си, в котором нет языковых средств безопасного программирования, есть языковые средства небезопасного оптимизированного программирования. Они там используются по выбору программиста и могут быть запрещены на уровне компилятора в рамках отдельных package, чтобы, например, не утруждать себя аудитом кода на предмет наличия неоправданных небезопасных оптимизаций. Вот где контроль, а не в этих ваших сях. :Р
> огроменного геморроя. Как раз в силу простоты типов и отсутствия наворотов
> там где они только мешаются.Все задачи в мире сводятся к тем, которые удобны программисту на Си как раз в силу простоты типов и отсутствия наворотов, ага. ;)
> В гугле.В гугле обычный линух на дешевых серверах :P. Да-да, гуглить для вас будет это решето на говняном х86... :)))
> МЕШАТЬСЯ!!!!!111 8-***
Судя по тому что вменяемых операционок, готовых для использования до сих пор почему-то нет, видимо вы правы с усилением эмоций. Ну или почему все как идиоты пишут оси на сях когда вокруг уже несколько десятков лет как есть более правильные языки?
>> например загнать ровно 4 байта да еще в строго определенном endianess'е
> Так спидфаг или не спидфаг?В идеале программа должна занимать как можно меньше места, работать как можно быстрее, потребляя как можно меньше памяти :))). Я не виноват что эти требования иногда противоречат друг другу :P.
> А то спидфаги выравнивают структуры даже на
> CISC-архитектурах (не имею ничего против, кстати). ;)Как ни странно я тоже ничего против не имею. Если это не ведет к тому что вместо, допустим, мегабайта памяти жрется, скажем, 4. А то мало ли, линух работает и в железках где RAM всего 16 Мб бывает и никакого свопа, например. В общем все хорошо в меру.
> И заметьте, в Аде, в отличие от Си, в котором нет языковых
> средств безопасного программирования, есть языковые средства
> небезопасного оптимизированного программирования. Они там используются
> по выбору программиста и могут быть запрещены на уровне компилятора
> в рамках отдельных package, чтобы, например, не утруждать себя аудитом кода
> на предмет наличия неоправданных небезопасных оптимизаций. Вот где
> контроль, а не в этих ваших сях. :РЗвучит неплохо. Только почему-то никто не пользуется адой, мир почему-то выбрал си. И дурные х86 с ископаемой системой команд и пачкой костылей. И почему-то я бы предпочел кернел где аудит все-таки сделали. А то если есть возможность "не утруждать себя аудитом кода", зная человеков я просто уверен что в итоге получится очередной энтерпрайзный крап где баг на баге и багом погоняет. Улет системы в панику а то и возможность сплойтом получить - явно не способствует тому чтобы плодить баги в коде, т.к. чревато :)
> Все задачи в мире сводятся к тем, которые удобны программисту на Си
> как раз в силу простоты типов и отсутствия наворотов, ага. ;)Вы только представьте себе, а ответная сторона ака фирмвара того же юсб-девайса ... обычно тоже пишется на си, ну, может с кусочками асма (хардкорный вариант - на голом асме, но нынче желающих это делать уже не так много как раньше). Логично что взаимодействовать с ней удобнее всего из тех же сей получается :)
>> В гугле.
> В гугле обычный линух на дешевых серверах :P. Да-да, гуглить для вас
> будет это решето на говняном х86... :)))Поставим ответ иначе: гугль знает.
>> МЕШАТЬСЯ!!!!!111 8-***
> Судя по тому что вменяемых операционок, готовых для использования до сих порНу так сделайте. Линух вон сперва вылез из грязи в князи, а потом крупные игроки пришли. А вы хотите чтобы за вас кто-то что-то делал. А оно этим кому-то надо - делать то что надо ВАМ а не ИМ? :)
> почему-то нет, видимо вы правы с усилением эмоций. Ну или почему
Хомячку не видно, а они есть. ;)
> все как идиоты пишут оси на сях когда вокруг уже несколько
> десятков лет как есть более правильные языки?Ну а почему все как идиоты сидят на винде когда вокруг уже несколько десятков лет есть BSD и линукс? Почему все как идиоты сидят на CISC-процессорах, когда вокруг давно есть RISC и VLIW? Почему все летают на дозвуковых самолётах и ездят на ЖД-поездах? Потому что привыкли, дёшево и сердито. Good enough.
> В идеале программа должна занимать как можно меньше места, работать как можно
> быстрее, потребляя как можно меньше памяти :))). Я не виноват что
> эти требования иногда противоречат друг другу :P.Иногда программа должна быть надёжной и безопасной, написана на привычном и хорошо знакомом, выразительном и хорошо читаемом языке с нативной поддержкой параллельных вычислений, по которому на рынке труда есть спрос и предложение, за которым стоят крупные корпорации, заинтересованные в популяризации своего языка и платформы среди промышленников, военных, бизнеса, хомячков и геймеров. Кто виноват и доколе?
> Как ни странно я тоже ничего против не имею. Если это не
> ведет к тому что вместо, допустим, мегабайта памяти жрется, скажем, 4.Это главное, да.
> А то мало ли, линух работает и в железках где RAM
> всего 16 Мб бывает и никакого свопа, например. В общем все
> хорошо в меру.Ага, всё хорошо в меру всегда и везде. ;)
> Звучит неплохо. Только почему-то никто не пользуется адой, мир почему-то выбрал си.
Вот ответ на вопрос: почему-то! :) И всё встало на свои места! :)
> И дурные х86 с ископаемой системой команд и пачкой костылей. И
Действительно, глупость. Альтернатив-то полно в каждом магазине, и совместимость полная.
> почему-то я бы предпочел кернел где аудит все-таки сделали. А то
> если есть возможность "не утруждать себя аудитом кода", зная человеков яМожно не проводить аудит на предмет конкретных недостатков => аудит не будут проводить вообще. Ага. Btw, его и сейчас никто не проводит, кроме единичных энтузиастов, пентестеров и криминала. ;)
> просто уверен что в итоге получится очередной энтерпрайзный крап где баг
> на баге и багом погоняет. Улет системы в панику а тоГде-то я это уже [s]слышал[/s] видел. ;)
> и возможность сплойтом получить - явно не способствует тому чтобы плодить
> баги в коде, т.к. чревато :)Ага. Железная надёжность и высокий уровень ответственности за безопасность. Именно это мы сейчас и видим. Алсо, свобода - это рабство. ;)
> Вы только представьте себе, а ответная сторона ака фирмвара того же юсб-девайса
> ... обычно тоже пишется на си, ну, может с кусочками асма
> (хардкорный вариант - на голом асме, но нынче желающих это делать
> уже не так много как раньше). Логично что взаимодействовать с ней
> удобнее всего из тех же сей получается :)Согласен, разница просто огромна: на сях я в порт или маппинг пишу/читаю, а на Аде и оберонах я в порти или маппинг пишу/читаю. Вы правы, ту мне возразить нечего.
Я бы на вашем месте прежде чем троллить изучил матчасть, но видимо этот путь не для вас, так вот вопрос, какие именно строки вы имеете ввиду, QString, CString, std::string или какие-то ещё?
Поскольку это ядро, то очевидно не std::string ;)
> Я бы на вашем месте прежде чем троллить изучил матчасть, но видимо
> этот путь не для вас, так вот вопрос, какие именно строки
> вы имеете ввиду, QString, CString, std::string или какие-то ещё?СТЛ ваш ни чем не лучше
> Я бы на вашем месте прежде чем троллить изучил матчасть, но видимо
> этот путь не для вас, так вот вопрос, какие именно строки
> вы имеете ввиду, QString, CString, std::string или какие-то ещё?А я бы на вашем месте изучил языки с более строгими системами типов, прежде чем кичиться формальным наличием выбора в рамках отдельно взятой проблемы (как будто других нет). Но очевидно, это путь не для вас.
> А я бы на вашем месте изучил языки с более строгими системами
> типов, прежде чем кичиться формальным наличием выбора в рамках отдельно взятой
> проблемы (как будто других нет). Но очевидно, это путь не для
> вас.Предлагаете писать ядро на лиспе?
> Предлагаете писать ядро на лиспе?То есть лисп в ваших глазах - это язык со строгой системой типов? :))
хаскель?) окамл?)
уточните, на чем же нада писать ядра?)
> уточните, на чем же нада песать ядра?)Очевидно Ада. На пару с Обероном.
>> уточните, на чем же нада песать ядра?)
>Очевидно Ада. На пару с Обероном.Это просто бред или какая-то очень тонкая ирония?
> Это просто бред или какая-то очень тонкая ирония?А что, разве на Аде и оберонах не написано ни одного ядра?
>> Это просто бред или какая-то очень тонкая ирония?
> А что, разве на Аде и оберонах не написано ни одного ядра?неа
http://en.wikipedia.org/wiki/Oberon_(operating_system)
> http://en.wikipedia.org/wiki/Oberon_(operating_system)Исходники ядра можно?
Да, там свободная лицензия.
>> http://en.wikipedia.org/wiki/Oberon_(operating_system)
> Исходники ядра можно?
>>> http://en.wikipedia.org/wiki/Oberon_(operating_system)
>> Исходники ядра можно?
> ftp://ftp.inf.ethz.ch/pub/ETHOberon/Native/StdAlone/ не?Не, там бинарники и примеры.
> http://en.wikipedia.org/wiki/Oberon_(operating_system)Эта операционка была для Вирта самым большим фейлом в его жизни, IMHO. Крах идеи о том что можно писать академическим подходом вещи применимые на практике - вылизывать байты, когда память дешевеет дикими темпами; не заниматься абстракциями аппаратуры, когда целевая аудитория - пользователи персоналок, со всем уже тогда имевшимся зоопарком железа; совершенно не заботиться о usability пользовательских интерфейсов, хотя примеров удачных (и не очень) реализаций было уже достаточно. Знаете, у новичков такое порой случается: делать то что возможно, вместо того что требуется. Для Вирта это должен был быть конец карьеры.
>> http://en.wikipedia.org/wiki/Oberon_(operating_system)
> Эта операционка была для Вирта самым большим фейлом в его жизни, IMHO.Действительно, фейл. Но не по части инженерных и потребительских качеств. Он долго артачился сделать исходники свободными, академическое сообщество энтузиастов не сколотил и не особенно, на сколько я знаю, старался продвигать свою систему и язык за пределами вуза.
> Крах идеи о том что можно писать академическим подходом вещи применимые
> на практике - вылизывать байты, когда память дешевеет дикими темпами; неhttp://www.sql.ru/forum/actualthread.aspx?bid=16&tid=689811 - там перечислены некоторые случаи применения оберонов на практике.
На базе паскаля была создана Ада, модула летала в космос уже в 80-ых. А крах идеи о том, что что-то можно писать "не академическим подходом", мы наблюдаем сегодня на примере юниксов и Си: проблемы с надёжностью, безопасностью, эффективностью разработки, плюс немасштабируемость выбранных архитектурных решений и потеря контроля за сложностью систем (тех самых моноядерных, одну из которых Торвальдс назвал раздутой и признался, что не видит путей решения этой проблемы).
> заниматься абстракциями аппаратуры, когда целевая аудитория - пользователи персоналок,
Ну да, других целевых аудиторий не бывает же.
> со всем уже тогда имевшимся зоопарком железа; совершенно не заботиться о
> usability пользовательских интерфейсов, хотя примеров удачных (и не очень) реализацийДля своего времени интерфейс оберонов был весьма удобен. Да и не создатели ОС должны его развивать, а сообщество, о формировании которого Вирт как раз и не позаботился.
> было уже достаточно. Знаете, у новичков такое порой случается: делать то
> что возможно, вместо того что требуется. Для Вирта это должен был
> быть конец карьеры.:) В качестве домашнего задания предлагаю подумать, почему на практике этот конец до сих пор не наступил. ;)
> хаскель?) окамл?)
> уточните, на чем же нада песать ядра?)Т.е. вы мне кагбе придлогаите передти от тролинга к розговору по сущиству?
Нет не предлагаю, т.к. по существу вам просто нечего сказать. Иначе б давно сказали)
А уж каким местом статическая типизация к новости про кернел, вообще непонятно.
> Нет не предлагаю, т.к. по существу вам просто нечего сказать. Иначе б
> давно сказали)Я говорил и не раз. Если вы считаете, что нет Тюринг-полных типобезопасных языков на которых были бы написаны реально применяемые ОС, это ваши проблемы.
> А уж каким местом статическая типизация к новости про кернел, вообще непонятно.
И при таком уровне внимания/понимания вы хотите, чтобы я распинался перед вами "по существу"? Сейчас всё брошу и начну, да.
Ядро на Хаскеле - это интересно... Уж оно-то будет отлично параллелизоваться, быть страшно оптимальным и типобезопасным, но я что-то не знаю осей на Хаскеле. Жааль
хехе, красноглазое быдло заминусовало правильный пост. Не только строки но и массивы в целом в С - это epic fail. D к примеру сделал тоже все правильно, массивы представляют собой структуру, содержащую указатель и длину массива.
Что Вам мешает написать собственную реализацию?
Вот к примеру как выглядят строки в ядре Nt:typedef struct _UNICODE_STRING {
USHORT Length;
USHORT MaximumLength;
PWSTR Buffer;
} UNICODE_STRING;
typedef UNICODE_STRING *PUNICODE_STRING;
> Что Вам мешает написать собственную реализацию?
> Вот к примеру как выглядят строки в ядре Nt:
> typedef struct _UNICODE_STRING {
> USHORT Length;
> USHORT MaximumLength;
> PWSTR Buffer;
> } UNICODE_STRING;
> typedef UNICODE_STRING *PUNICODE_STRING;Вот именно, у каждого Васи своя реализация, несовместимая с реализацией Пети. А еще есть алгоритмы которые надо дублировать для контейнеров и строк.
Ну так вперед! Докажите миру что Ваша реализация безопасней, быстрей и удобней!
Все Вам только спасибо скажут...
> Ну так вперед! Докажите миру что Ваша реализация безопасней, быстрей и удобней!Всё уже реализовано и доказано.
> Все Вам только спасибо скажут...
Нет, "все" будут жаловаться на необходимость изучить новое, на непривычное, на отсутствие массового рынка труда, на Отсутствие Контроля и т.п.. Хотят есть кактус, пусть едят.
> D к примеру сделал тоже все правильно, массивы представляют собой структуру, содержащую указатель и длину массива.Да, это помогает избежать сегфолта, разменивая его на логические ошибки, вот только их отлаживать еще труднее.
Ну и результате имеем неустранимый оверхед на рантайм-проверку границ массива.
>> D к примеру сделал тоже все правильно, массивы представляют собой структуру, содержащую указатель и длину массива.
> Да, это помогает избежать сегфолта, разменивая его на логические ошибки, вот только
> их отлаживать еще труднее.
> Ну и результате имеем неустранимый оверхед на рантайм-проверку границ массива.Вы этот оверхед видели, замеряли, реализация таких проверок на ассемблере вам знакома, сравнительный анализ "оверхеда" с вычислением длин строк в средней программе на Си делали? Нет. Зато пафоса и апломба - вагон.
> Вы этот оверхед видели, замеряли, реализация таких проверок на ассемблере вам знакома,
> сравнительный анализ "оверхеда" с вычислением длин строк в средней программе на
> Си делали? Нет.А вы, простите, видели, что я делал а что нет?)
Зато баттхерта и агрессии у вас - вагон)
>> Вы этот оверхед видели, замеряли, реализация таких проверок на ассемблере вам знакома,
>> сравнительный анализ "оверхеда" с вычислением длин строк в средней программе на
>> Си делали? Нет.
> А вы, простите, видели, что я делал а что нет?)Вот я и спрашиваю: вы видели, делали? Если нет, к чему эти юления со смайликами?
> Зато баттхерта и агрессии у вас - вагон)Батхёрт действительно есть, но не по вашей милости. Мне с поделиями на Си ещё работать и работать. Благо, не только с ними. Агрессии? Вы себе льстите.
> Батхёрт действительно есть, но не по вашей милости. Мне с поделиями на
> Си ещё работать и работать.Если вы такой умный и знаете как надо а как ненадо, почему работаете на работе, которая вызывает у вас баттхерт?
> Если вы такой умный и знаете как надо а как ненадо, почему
> работаете на работе, которая вызывает у вас баттхерт?Потому что других ОС у рынка для меня нет.
> Вот я и спрашиваю: вы видели, делали?Вы его не спрашивали, а предположили заранее. Надменность - не лучший способ доказать правоту.
>> Вот я и спрашиваю: вы видели, делали?
> Вы его не спрашивали, а предположили заранее. Надменность - не лучший способ
> доказать правоту.Не лучший, но любые попытки доказать правоту тут как правило тщетны (я уже пытался, в комментариях к другим новостям).
> сравнительный анализ "оверхеда" с вычислением длин строк в средней программе на
> Си делали? Нет. Зато пафоса и апломба - вагон.Ну вон quicklz - одна и та же либа, при том авторами писаны реализации на сях, сишарпе и яве. Бенчмарки можно прямо на их же сайте и посмотреть. Почему-то ява и дотнет стабильно в 2.5 - 3 раза тормознее в этой задаче, несомненно критичной к скорости (либа позиционируется как чемпион по скорости). Наверное, рантайм проверки как раз и делают свое черное дело - подумал Штирлиц. Ну, алгоритм то реализуется одинаковый, блин?! И вообще, почему-то гуры от компрессии советуют начинающим, которые прутся с своими чудо-велосипедами на C# пойти выучить си++, если конечно те хотят чтобы их архивером кто-то еще и пользоваться бы стал хоть немного а параметры (время работы vs степень сжатия) стали бы сравнимы с архиваторами подобного типа. Это наверное вовсе не потому что разница в несколько раз появляется от простой замены сишарпа на си/си++, без изменения самого алгоритма. Ага... :)
> Ну вон quicklz - одна и та же либа, при том авторами
> писаны реализации на сях, сишарпе и яве. Бенчмарки можно прямо на
> их же сайте и посмотреть. Почему-то ява и дотнет стабильно в
> 2.5 - 3 раза тормознее в этой задаче, несомненно критичной кЗначит и Ада сольёт в 3 раза. Тут к гадалке не ходи. В ней же строки тоже немутабельные, и рантайм-проверок(с)тм(r) полно.
> то реализуется одинаковый, блин?! И вообще, почему-то гуры от компрессии советуют
> начинающим, которые прутся с своими чудо-велосипедами на C# пойти выучить си++,Советуют, да.
> если конечно те хотят чтобы их архивером кто-то еще и пользоваться
Почему-то, ага.
> бы стал хоть немного а параметры (время работы vs степень сжатия)
> стали бы сравнимы с архиваторами подобного типа. Это наверное вовсе не
> потому что разница в несколько раз появляется от простой замены сишарпа
> на си/си++, без изменения самого алгоритма. Ага... :)Ну дык. Алсо, "язык программирования Ада" - сразу видно, что его делали мелкософт, оракл, RIAA, масоны и Гитлер. Будет тормозить, просить денег и зигу кидать, это ж очевидно.
Кто вам мешает сделатьstruct my_str {
char *ptr;
size_t len;
};и писать надежно, безопасно, ънтерпрайзно(с)?
ты очень умный, только почему тогда никто этого не сделал, а вместо этого мы имеем целый зоопарк реализаций контейнеров?
> ты очень умный, только почему тогда никто этого не сделал, а вместо
> этого мы имеем целый зоопарк реализаций контейнеров?Это сделала например майкрофост в MFC да и много где еще.
Что значит "никто не сделал" и тут же "зоопарк реализаций"? Противоречишь сам себе.
> Это сделала например майкрофост в MFC да и много где еще.
> Что значит "никто не сделал" и тут же "зоопарк реализаций"? Противоречишь сам
> себе.Ура, он противоречит сам себе! Наличие проблемы заретушировано претензиями к оппонентам! Всё замечательно!
> Ура, он противоречит сам себе! Наличие проблемы заретушировано претензиями к оппонентам! Всё замечательно!Проблема у тебя в голове.
> Кто вам мешает сделать
> struct my_str {
> char *ptr;
> size_t len;
> };
> и писать надежно, безопасно, ънтерпрайзно(с)?Литерал этого типа в студию, для начала.
> Литерал этого типа в студию, для начала.Что еще за "литерал типа"?
В str указатель, в len длина строки, что непонятного?
>> Литерал этого типа в студию, для начала.
> Что еще за "литерал типа"?
> В str указатель, в len длина строки, что непонятного?С вами - всё предельно ясно.
> С вами - всё предельно ясно.Ок!
struct my_str s = { "abc", 3 };
> struct my_str s = { "abc", 3 };Ну вот, вычисление длины строки "на глазок" и ошибка на единицу в простейшем примере. Браво.
Чтобы не морочить себе голову и не ошибиться, можно использовать простой макрос.#define MY_STR(L) { L, sizeof(L)-1 }
struct my_str s = MY_STR("abc");
> #define MY_STR(L) { L, sizeof(L)-1 }
> struct my_str s = MY_STR("abc");Это феерический мрак. sizeof(L) вернёт количество элементов в массиве, включая терминирующий '\0'. У len тип size_t, и хранит он размер массива, а не индекс последнего элемента. Единицу зачем отнимаете?
Что вас удивляет? Что строковые литералы в Си неявно содержат терминирующий NUL? Что поэтому sizeof строкового литерала на 1 больше длины строки?
> Что вас удивляет? Что строковые литералы в Си неявно содержат терминирующий NUL?
> Что поэтому sizeof строкового литерала на 1 больше длины строки?Меня удивляет, что в ответ на замечание об ошибке на единицу вы написали эквивалентный по семантике макрос, а на тему "индекс последнего элемента vs. размер массива" начинаете "недоумевать" только сейчас.
Особенно это странно в колее разговора о strl-функциях, коим в size передаётся размер массива, включая '\0', в чём и заключается их главное отличие от strn-функций. И честно говоря, я уверен, что сейчас вы просто отмазываетесь, не желая признать за собой типичную ошибку.
Я написал, как избежать ошибки в подсчёте числа символов. Да, теперь я вижу в чём была ваша ошибка -- вы почему-то считаете, что длина строки на единицу больше количества символов, содержащихся в ней.Функции strl* принимают размер буфера, который содержит строку и терминирующий NUL. Его размер должен быть по крайней мере на единицу больше предполагаемой длины строки.
> Я написал, как избежать ошибки в подсчёте числа символов. Да, теперь яКакой ошибки? Давайте по порядку.
Если следовать вашей логике, по которой в len показанного структурного типа должна записываться длина строки без учёта '\0', то мой комментарий, на который вы ответили, был ошибочен весь.
Если так, вы могли бы мне возразить, предположив, что автор структурного типа предлагает хранить в len именно длину строки. Но вы этого не сделали.
Вы предложили семантически эквивалентный макрос, который, по вашим словам, помог бы "избежать ошибки в подсчёте числа символов". То есть, прочитав мой комментарий, вы согласились с наличием ошибки в приведённом литерале... Которую теперь не считаете ошибкой?
Так была ли ошибка? Вот эта непоследовательность и склоняет меня к мысли, что вы просто юлите.
> вижу в чём была ваша ошибка -- вы почему-то считаете, что
> длина строки на единицу больше количества символов, содержащихся в ней.Нет. Я считаю, что в len должен храниться размер массива символов, включая '\0', поскольку в операциях со значениями размеров строк без учёта '\0' чаще допускаются ошибки. И авторы strl-функций со мной согласны. К тому же, терминирующий нуль - анахронизм, мешающий применять wide-кодировки с символами постоянной длины, содержащими нулевые байты.
> Функции strl* принимают размер буфера, который содержит строку и терминирующий NUL. Его
> размер должен быть по крайней мере на единицу больше предполагаемой длины
> строки.По-моему, теперь вы делаете вид, что терминирующий '\0' не является частью строки в Си: "строку и терминирующий NUL" - если это ваша изначальная точка зрения, то почему она такая противоречивая и идёт в разрез со стандартной терминологией?
Признаюсь, я неправильно понял ваш первый комментарий. Показалось, что вы намекаете на возможность ошибки в такой записи. То, что вы будет оспаривать, что длина строки из трёх символов равна трём, мне и в голову не пришло. Да, ваш комментарий ошибочен весь.> Нет. Я считаю, что в len должен храниться размер массива символов, включая '\0', поскольку в операциях со значениями размеров строк без учёта '\0' чаще допускаются ошибки. И авторы strl-функций со мной согласны.
Это исключительно ваши личные убеждения. И авторы strl-функций с вами не согласны -- третий аргумент называется size, а не len. Не говоря уже о том, что ASCIIZ-строки к данному представлению вообще не имеют отношения.
> К тому же, терминирующий нуль - анахронизм, мешающий применять wide-кодировки с символами постоянной длины, содержащими нулевые байты.
Да, и поэтому при представлении строки как указателя на массив символов и длины он не нужен.
> По-моему, теперь вы делаете вид, что терминирующий '\0' не является частью строки в Си: "строку и терминирующий NUL" - если это ваша изначальная точка зрения, то почему она такая противоречивая и идёт в разрез со стандартной терминологией?
Да не является. NUL не часть строки в Си, а ограничивающий её символ. Моя точка зрения вполне последовательна и согласуется со стандартной терминологией, как Си, так и общекомпьютерной.
> Признаюсь, я неправильно понял ваш первый комментарий. Показалось, что вы намекаете на
> возможность ошибки в такой записи. То, что вы будет оспаривать, что
> длина строки из трёх символов равна трём, мне и в головуК чему эти абсурдные инсинуации? Вы прекрасно понимаете, что я имел ввиду. В len должен храниться размер массива символов с терминирующим '\0', точка.
> не пришло. Да, ваш комментарий ошибочен весь.
С вашей точки зрения. С моей, структурный строковый тип без нуль-терминации - ни с чем не совместимый нонсенс, который способствует ошибкам переполнения на единицу и создаёт неадекватные трудности при работе с библиотечными функциями, которые принимают нуль-терминированные строки.
> Это исключительно ваши личные убеждения. И авторы strl-функций с вами не согласны
> -- третий аргумент называется size, а не len. Не говоря ужеОни со мной "не согласны" только в названии аргумента, а вы просто юлите.
> о том, что ASCIIZ-строки к данному представлению вообще не имеют отношения.
К какому данному представлению? К структурному? В параллельном мире могут не иметь, а в реальном, если вы делаете свой, более безопасный строковый тип, потрудитесь обеспечить простоту его применения при работе с библиотеками. Жду возражений!
>> К тому же, терминирующий нуль - анахронизм, мешающий применять wide-кодировки с символами постоянной длины, содержащими нулевые байты.
> Да, и поэтому при представлении строки как указателя на массив символов и
> длины он не нужен.Я хотел сказать, что реализовать строковый структурный тип, совместимый и с wide-кодировками, и с нуль-терминированными строками в Си практически невозможно. Но меня интересует другое.
Вы что, считаете, что структурный строковый тип не должен быть совместим с нуль-терминированными строками?
> Да не является. NUL не часть строки в Си, а ограничивающий её
> символ. Моя точка зрения вполне последовательна и согласуется со стандартнойНулевой байт не является частью нуль-терминированной строки, я вас правильно понял?
> терминологией, как Си, так и общекомпьютерной.
Можете назвать источник такой терминологии, что-нибудь для примера?
В len обычно хранят длину строки, а размер массива обычно называют size. Для примера: strlen("abc") == 3, хотя sizeof("abc") == 4. Т.о. хоть нулевой символ и является частью строки, считается, что в ее длину он не входит. По-моему, именование len vs size вполне естественно и интуитивно понятно. Существуют и необычные случаи, но для меня очевидно, что предложенная структура подразумевает хранение ASCIIZ и ее длины в терминах strlen().
> В len обычно хранят длину строки, а размер массива обычно называют size.
> Для примера: strlen("abc") == 3, хотя sizeof("abc") == 4. Т.о. хотьВы мне ещё букварь почитайте по слогам, в едином дидактическом порыве.
> нулевой символ и является частью строки, считается, что в ее длину
> он не входит. По-моему, именование len vs size вполне естественно иА по-моему, вполне естественно хранить не len, а size, независимо от его названия. Особенно, предлагая определение типа в контексте разговора о strl-функциях и проблеме со строками. Но я, кажется, понял, почему собеседники завели этот нелепый спор о совершенно вторичных названиях...
> интуитивно понятно. Существуют и необычные случаи, но для меня очевидно, что
> предложенная структура подразумевает хранение ASCIIZ и ее длины в терминах strlen().И знаете, почему? Похоже, что безопасные строковые типы им в действительности не нужны. Почему не нужны - вопрос отдельный, но такое отношение позволяет им всерьёз рассуждать о структурном типе, не совместимом с ASCIIZ. И именно поэтому они выдвинули формальное решение, не удосужившись, похоже, даже представить, насколько оно жизнеспособно в реальном мире.
Вам очевидно, что структурный тип должен хранить указатель именно на ASCIIZ-строку? Замечательно! Хоть кому-то очевидно.
> Вы мне ещё букварь почитайте по слогам, в едином дидактическом порыве.Вы просили пример, вот я и подумал, что созвучия разбудят вашу интуицию.
> И знаете, почему? Похоже, что безопасные строковые типы им в действительности не
> нужны. Почему не нужны - вопрос отдельный, но такое отношение позволяетНичего за них сказать не могу, может так, а может и эдак.
Лично я не приверженец си/++, но от сожалений о том что "все идиоты" никто мудрее не станет, и писать что-то на стандартных сях ни у кого необходимости не отпадет. Поэтому необходимо, так сказать, знать врага в лицо и разговаривать на его языке; вовремя не отличил сайз от лена -- попал на буфер-оверфло или еще на что-нибудь. По мне так вообще печально, что я вместо компилятора выбираю битовые паттерны для своих данных.
> Вы просили пример, вот я и подумал, что созвучия разбудят вашу интуицию.Не просил. Мне всё равно, как называется атрибут, главное - что он хранит. В случае массивов size и length вообще синонимы.
> Лично я не приверженец си/++, но от сожалений о том что "все
> идиоты" никто мудрее не станет, и писать что-то на стандартных сяхИдиотами я никого не называл и не считаю. В банальных ошибках подозревал, но вариант с безразличием скорее всё расставил по местам.
> Не просил. Мне всё равно, как называется атрибут, главное - что он
> хранит. В случае массивов size и length вообще синонимы.Ну даете, блин.. )
зы: посоветуйте плиз что-нибудь из цикла "Ада за 3 дня не для тупых", я как-то брался, но тогда домашнего интернета в этой стране еще не было, а теперь времени не вагон.
> Ну даете, блин.. )Я изначально говорил о размерах массивов, а не длинах строк. Умеющий читать, да учёл.
> зы: посоветуйте плиз что-нибудь из цикла "Ада за 3 дня не для
> тупых", я как-то брался, но тогда домашнего интернета в этой стране
> еще не было, а теперь времени не вагон.По 2005-ой есть хороший викибук: http://en.wikibooks.org/wiki/Ada_Programming
Квадратные книги видел только по 95-ой, не проникся. Плюс RM не для тупых: http://www.adaic.org/resources/add_content/standards/05aarm/...
> По 2005-ой есть хороший викибук: http://en.wikibooks.org/wiki/Ada_Programming
> Квадратные книги видел только по 95-ой, не проникся. Плюс RM не для
> тупых: http://www.adaic.org/resources/add_content/standards/05aarm/...Сенкс, а то как раз пятница свободная выдалась.
> Это феерический мрак. sizeof(L) вернёт количество элементов в массиве, включая терминирующий
> '\0'. У len тип size_t, и хранит он размер массива, а
> не индекс последнего элемента. Единицу зачем отнимаете?Если у вас есть голова, попробуйте воспользоватся ей. Тогда, может, дойдет, что именно из-за \0 и отнимаем единицу. Т.к. в нем нет нужды раз уж мы указываем длину строки.
Если вы и так все знаете, к чему эти "покажите литералы" и т.п.? Хочецца посамоутверждаться?
> Если у вас есть голова, попробуйте воспользоватся ей. Тогда, может, дойдет, что
> именно из-за \0 и отнимаем единицу. Т.к. в нем нет нужды
> раз уж мы указываем длину строки.В литерале '\0' в конце строки есть, почему в len он учитываться не должен? И правильно ли я вас понял, вы предлагаете сделать структурный строковый тип несовместимым с нуль-терминированными строками, работая с размерами по образу и подобию strn-функций? Какой оригинальный и жизнеспособный замысел! Алсо, ваш литерал с подсчётом количества символов на глазок - это смех и слёзы. Хоть бы макрос предложили, как другой товарищ тут.
> Если вы и так все знаете, к чему эти "покажите литералы" и
> т.п.? Хочецца посамоутверждаться?То есть, армия хамоватых ура-апологетов бездарного Си у меня не может вызывать иных эмоций, кроме желания самоутвердиться? Да вы по себе судите, неуважаемый.
Есть тут ошибка или нет, можно сказать только взглянув на функции, работающие с этой структурой.
> Есть тут ошибка или нет, можно сказать только взглянув на функции, работающие
> с этой структурой.Я ждал этой отмазки, но она не катит, поскольку собеседник отвечал на моё замечание об ошибке на единицу. Его макрос совершает ровно ту же ошибку.
> Я ждал этой отмазки, но она не катит, поскольку собеседник отвечал на
> моё замечание об ошибке на единицу. Его макрос совершает ровно ту
> же ошибку.Где там ошибка-то? Строка из 3 (трех!) элементов, нулл не нужен т.к. указываем непосредственно длину.
>> Кто вам мешает сделать
>> struct my_str {
>> char *ptr;
>> size_t len;
>> };
>> и писать надежно, безопасно, ънтерпрайзно(с)?
> Литерал этого типа в студию, для начала.my_str s = MY_STR("RTFM!");
>EPIC FAIL C/C++Попроси разработчиков ядра FreeBSD, пусть они его на жабе перепишут :))
+1чт оприкольно - они не хотят это изменять
мол какая разница проверку сделает программист или данная проверка уже будет в самой функции - ГОВНО ПОДЕЛИЕ - нету уже доверие всяким стандартным библиотекам
> чт оприкольно - они не хотят это изменять
> мол какая разница проверку сделает программист или данная проверка уже будет в
> самой функции - ГОВНО ПОДЕЛИЕ - нету уже доверие всяким стандартным
> библиотекамЧем будет лучше, если библиотека проверит и обнаружит обращение за границы массива?
Да, по сегфолту не упадем, но ошибка может аукнутся в другом месте.
> Да, по сегфолту не упадем, но ошибка может аукнутся в другом месте.Действительно, ну чем DoS лучше полной компрометации? Да ничем.
Вот почему OpenBSD написали ядро на C и особых проблем не ощущают? На мой взгляд действует прицнип: новичёк, руки кривые? Не лесь в C/C++.Чем более низкоуровневый язык, тем больше он даёт свободы реализации алгоритма так, что бы он работал максимально быстро. К примеру на практически любом ассемблере есть множество инструкций, которые не имеют нормальных аналогов в C.
Короч если руки кривые, предоставь возможность компилятору/инторпритатору следить за тобой.
> Вот почему OpenBSD написали ядро на C и особых проблем не ощущают?Джо ты? Тебя так до сих пор и не поймали?
> Джо ты? Тебя так до сих пор и не поймали?Напишите востребованную ОС с непозорными параметрами на чем-то еще, фигле. Кто-то не дает?
> Напишите востребованную ОС с непозорными параметрами на чем-то еще, фигле. Кто-то не дает?Зачем? Мне и линуксы вполне хватает.
> Вот почему OpenBSD написали ядро на C и особых проблем не ощущают?http://openbsd.org/images/hackathons/c2k10.gif
> На мой взгляд действует прицнип: новичёк, руки кривые? Не лесь в
> C/C++.Это пройдёт.
> Чем более низкоуровневый язык, тем больше он даёт свободы реализации алгоритма так,
> что бы он работал максимально быстро. К примеру на практически любом
> ассемблере есть множество инструкций, которые не имеют нормальных аналогов в C.Скорость - не единственное требование к программам. К тому же, не все классы оптимизаций доступны компиляторам С/С++, дающим на выходе код с традиционным рантаймом. Например: http://morepypy.blogspot.com/2011/02/pypy-faster-than-c-on-c...
> Короч если руки кривые, предоставь возможность компилятору/инторпритатору следить за
> тобой.И много вы знаете совершенных людей с абсолютно прямыми руками, которые никогда не ошибаются?
> классы оптимизаций доступны компиляторам С/С++, дающим на выходе код с традиционным
> рантаймом.Да, да, да. JIT в теории может, блабла. На практике - а хрен там. Вот когда ядра, библиотеки и все остальное критичное к скорости будут писать на питонах, явах и прочих мегатормозилах - тогда и приходите.
> Скорость - не единственное требование к программам.Почему микроядро еще не везде где можно?
Почему ядра ОС, игры с графикой, рендеры, матсофт и т.п. не пишут на безопасных языках? (маргинальных примеров не надо)
>> Скорость - не единственное требование к программам.
> Почему микроядро еще не везде где можно?
> Почему ядра ОС, игры с графикой, рендеры, матсофт и т.п. не пишут
> на безопасных языках? (маргинальных примеров не надо)А кто из крупных игроков на рынке стоит за этими микроядрами, безопасными языками, кто тратит ресурсы на создание и развитие инфраструктуры? Никто. А ядра ОС на безопасных языках пишут.
> А кто из крупных игроков на рынке стоит за этими микроядрами,Крупные игроки приходят когда видят что получилась нужная штука, лучше других, т.е. пахнет профитом. У микроядер своих проблем хватает и потому они остались нишевой штукой, а практически жизнеспособные системы почему-то сплошь и рядом монолиты да гибриды.
> безопасными языками,
Ну да, майкрософт и оракль - незначительные конторки с их явами и дотнетами. Мелочевка.
> кто тратит ресурсы на создание и развитие инфраструктуры? Никто.
Ну так тратьте. Линух вон сперва вылез из грязи в князи, а потом крупные игроки пришли. А вы хотите чтобы за вас кто-то что-то делал. А оно этим кому-то надо - делать то что надо ВАМ а не ИМ? :)
> А ядра ОС на безопасных языках пишут.
Да, а еще 100500 лет про микроядра орали, да толку то?
> Крупные игроки приходят когда видят что получилась нужная штука, лучше других, т.е.
> пахнет профитом. У микроядер своих проблем хватает и потому они остались
> нишевой штукой, а практически жизнеспособные системы почему-то сплошь и рядом монолиты
> да гибриды.Ага, это даже доказательства не требует. Оно же очевидно.
>> безопасными языками,
> Ну да, майкрософт и оракль - незначительные конторки с их явами и
> дотнетами. Мелочевка.Ну да, тред можно не читать, главное - к знакомы словами прицепиться и ляпнуть что-нибудь.
>> кто тратит ресурсы на создание и развитие инфраструктуры? Никто.
> Ну так тратьте. Линух вон сперва вылез из грязи в князи, аНу так трачу, представьте себе.
> потом крупные игроки пришли. А вы хотите чтобы за вас кто-то
Да, хочу.
> что-то делал. А оно этим кому-то надо - делать то что
> надо ВАМ а не ИМ? :)Больше капса, больше смайликов, вы не стесняйтесь. Главное ведь - забыть, что я отвечал на чужой вопрос, а не в жилетку плакался.
>> А ядра ОС на безопасных языках пишут.
> Да, а еще 100500 лет про микроядра орали, да толку то?Дофига толку. Самолёты на них работают, ракеты, космические корабли, судоходство и прочая промышленность, телекомы. Но это всё х#ита, конечно же. На ведь писюках нет? Нет. Ну и слив защитан мне, да.
P.S.
И кагбе можно даже не замечать, что за микроядра я не агитировал. Не это ведь в троллинге главное, ага.
> Ага, это даже доказательства не требует. Оно же очевидно.Хорошо, ну так крупные игроки добровольно (!!!) выбрали то что им пришлось по вкусу. А вы, собссно, кто чтобы с кого-то что-то требовать с нахрапом? Если вы полагаете что сможете лучше - докажите делом, тогда, может быть, и остальные подтянутся. Если, конечно, их понятия о "лучше" совпадут с вашими (что совсем не факт, но шансы есть). А если вы будете указывать другим как и что им следует делать - они как максимум не очень вежливо оббъяснят вам куда вам следует пройти.
> Ну да, тред можно не читать,
Да вы тут гранд-мастеры троллинга :) надо ж столько флуда вывалить из-за одной тупой уязвимости в драйвере, которая эксплуатируется путем вырезания гланд через жопу автогеном, пардон. Но ведь реальная опасность дыры ("наиболее элитные перцы с наклонностями шпионов может и поимеют десяток-другой локалхостов") - это ж не важно, да? Главное поистекать говном какой плохой си, какие пи...сы на нем пишут столь парашные операционки и прочая. Я вижу ровно 1 проблему: вы забыли предложить миру вашу операционку, лучше. Без сей и пи...сов, зато с шахматами и поэтессами. Поэтому все как лохи и лузеры пользуются тем что есть и работает. Достаточно неплохо работает. Не идеально, но свои задачи выполняет. А идеального софта почему-то вообще не бывает :)
> главное - к знакомы словами прицепиться и ляпнуть что-нибудь.
А эти слова случайно были не "си", "Linux" и "уязвимость"? Ну или какого тут поднялся такой многостраничный троллинг? :)
> Ну так трачу, представьте себе.
Я рад за вас, все дела. Вам надо - вы и упираетесь, все честно. А в лично моем понимании, надежная система должна быть прежде всего простой как топор. Товарисч D. J. Berstein вон делом доказал что на си можно написать надежную программу. Кстати его понятия о надежности вообще не привязаны к языку - он вообще рассмотрел надежность программ, причины багов (в частности, проблем секурити) и как можно минимизировать оные. Почему-то ему си при этом нифига не помешал. В этом плане современное железо с даташитами на сотни страниц а то и больше - оставляет желать лучшего, вообще-то. В нем тоже багов - есть.
>> потом крупные игроки пришли. А вы хотите чтобы за вас кто-то
> Да, хочу.Хотеть не запретишь. Хотите себе. Имхо долго и не факт что успешно будете хотеть.
> я отвечал на чужой вопрос, а не в жилетку плакался.
А по стилю больше похоже на плач несмеяны. Добро пожаловать в реальный мир, мир акул бизнеса, костылей и подпорок. Простите пожалуйста что ваши кульные теоретические концепты которые где-то там в теории могли бы хорошо делать что-то, тут никому нафиг не нужны, никто за это не платит и прочая. Как максимум тут вы можете рассчитывать на ваш энтузазизм, голову и пару рук. Если сильно повезет - может сумеете сколотить команду единомышленников, а один из миллиона через ...цать лет может даже и найдет инвестора который купится на красивые спичи. Но это не гарантировано, а кроме того, акул-инвесторов не интересуют все эти ваши концепции, их интересуют конкретные результаты, которые профит приносят. А как оно там внутри сделано - им вообще насрать, вы прикиньте? :). И горе вам если вы сорвете сроки, не сможете сделать то что обещали и прочая - вазелина понадобится много.
> Дофига толку. Самолёты на них работают,
А конкретные модели самолетов - осилите? А то я читал как у какого-то из боингов сделано - там ни про какие микроядра почему-то ни звука. Зато звуки про резервирование, юзание 2 разных архитектур процессоров, реализацию 1 и того же алгоритма 2-я разными командами програмеров, на 2 разных языках + сравнение результата вычислений обоих компьютеров, етц, етц. Ну в общем чтобы не могла возникнуть ситуация когда оба компьютера словят синхронно один и тот же баг и он останется не замечен, возможно с достаточно неприятными последствиями. Вот это я понимаю - чуваки настроены на то чтобы баги не пролезли + автоматическое обнаружение оных. Я также в курсе систем которые голосуют на уровне железа по принципу "2 из 3" например, так что бажный модуль может быть вычислен.
> ракеты, космические корабли,
Почему-то в них обычно стараются применять довольно примитивные процессоры. Наверное потому что радиация и все такое, а чем сложнее проц - тем он нежнее к таким вещам и более склонен к сбоям, в нем более вероятны ошибки и прочая (никогда не пробовала почитать Errata на современные процы? Там жесткач полнейший, только его видят сильно некоторые :D). А на простом проце - обычно крутится нечто сильно кастомное, под задачу. У простого проца пардон даже системы деления привилегий может не быть. Ну и накукуй там микроядра? Там обычно простая как топор фирмварина которая выверена до битика и делает свою задачу.
> судоходство и прочая промышленность, телекомы.
Ой, почему-то в реально критичных к отказу местах стоят простые чипы, быстро реагирующие на события, а желательно и вообще аппаратные защиты, т.к. софт и 100% надежность - очень трудносовместимые понятия. Простые - потому что чем сложнее чип, тем он глючнее, менее предсказуем, в нем больше багов (да, в чипах тоже бывают баги, google://Errata если что). У простого чипа - и фирмварина простая как топор. Собссно микроядро - всего лишь выносит сложность из ядра в другие куски системы, а в целом сложность системы особо не падает. Как максимум можно собрать простую систему которая ничерта не умеет. Только что с ней потом делать на серверах и прочая? Ну, я знаю ровно 1 применение на серверах и десктопах: назвать это гипервизором и изолировать друг от друга более сложные ОС. Но сложность систем никуда не девается и баги остаются, ессно, просто они изолированы и локализованы :)
> Но это всё х#ита, конечно же. На ведь писюках нет?
А знаете, если вы въе в стену на вашем авто и надо срочно вам подушку безопасности надуть, чтоб вы не выпорхнули в стекло и не размазались по стене - почему-то надувать ее, спасая вашу жо, будет в общем случае примитивный проц-"таракан" с датчиком и с не менее примитивной фирмвариной, чуть ли не единственной целью существования которого является именно это действо. И фирмварина примитивна и вылизана до битика, потому что если юзер вылетит в лобовое стекло - как-то нехорошо получится, да? А отсуствие многозадачности намекает на то что не надо ни защищаться от остальных задач, ни делить с ними время. Сложность системы падает в десятки раз. Вот тогда уже начинает идти разговор о какой-то там надежности решений, частью которых является софт. А пишут этот софт почему-то на асме и сях. Таких небезопасных, пля...
> Нет. Ну и слив защитан мне, да.
Слив вам засчитан за то что существует например уйма мелких процов в критичных к отказу местах ... запрограмленых на этих самых жутко небезопасных сях и асме. При том баги в фирмваре оных - скорее исключение чем правило. Потому что цена ошибки - соответствующая, и делается все возможное чтобы ошибок просто не было. Потому что внезапное надувание подушки без причины - как минимум очень неприятный сюрприз с риском для здоровья, а профукивание момента когда ее надо надуть - и вовсе может означать что юзер просто сыграет в ящик.
> P.S.
> И кагбе можно даже не замечать, что за микроядра я не агитировал.Угу, вы в основном просто набрасывали на вентилятор что линуксы - говно, си - отстой, только все это очень напоминает анекдот про цирк и "все клоуны - пи..сы!" :)
> Не это ведь в троллинге главное, ага.
Да уж! Так, глядя сколько тут натроллили из-за уязвимости которую можно поюзать только с спецжелезкой при физическом доступе к компу. Не, мне правда интересно, хотя-бы сотню компов на планете за следующие пару месяцев так сломают? :)
Ооо, какая знатная простыня! И как же я тебя пропустил, дорогая... Сейчас накатаю ответную.>> Ага, это даже доказательства не требует. Оно же очевидно.
> Хорошо, ну так крупные игроки добровольно (!!!) выбрали то что им
> пришлось по вкусу. А вы, собссно, кто чтобы с кого-то что-то
> требовать с нахрапом? Если вы полагаете что сможете лучше - докажитеА я с кого-то что-то требую? :) Нет. Но я догадываюсь, откуда растут ноги у таких упрёков: когда напоминаешь людям о недостатках их выбора/результатов работы/предмете обожания, они ищут хоть какой-то повод дать ответ по системе "сперва добейся" и "с чего вы взяли, что вам кто-то что-то обязан?". ;)
Алсо, не хотите обосновывать, так и говорите. ;)
> делом, тогда, может быть, и остальные подтянутся. Если, конечно, их понятия
> о "лучше" совпадут с вашими (что совсем не факт, но шансы"Сперва добейся, потом критикуй!" (ц) ;)
> есть). А если вы будете указывать другим как и что им
> следует делать - они как максимум не очень вежливо оббъяснят вам
> куда вам следует пройти.О, да! К "другим" даже с готовыми патчами обращаться - дело неблагодарное в большинстве случаев. Ибо политика + нежелание брать на себя труд по изучению и сопровождению кода "ради какой-то там безопасности". ;)
> Да вы тут гранд-мастеры троллинга :) надо ж столько флуда вывалить из-за
Дык! ;)
> одной тупой уязвимости в драйвере, которая эксплуатируется путем вырезания гланд через
> жопу автогеном, пардон. Но ведь реальная опасность дыры ("наиболее элитные перцы
> с наклонностями шпионов может и поимеют десяток-другой локалхостов") - это ж
> не важно, да? Главное поистекать говном какой плохой си, какие пи...сыКонечно, не важно. Троллинг начался с поста iZEN про C/C++, а новость - кого она волнует вообще? :D
> на нем пишут столь парашные операционки и прочая. Я вижу ровно
> 1 проблему: вы забыли предложить миру вашу операционку, лучше. Без сейЯ над этим работаю. ;)
> и пи...сов, зато с шахматами и поэтессами. Поэтому все как лохи
> и лузеры пользуются тем что есть и работает. Достаточно неплохо работает.Собственно, операционки лучше уже предложил и Вирт сотоварищи, и папы юникса, но воз и ныне там. Ибо The Old Stuff Is Just Good Enough.
> Не идеально, но свои задачи выполняет. А идеального софта почему-то вообще
> не бывает :)Потому что гладиолус же.
>> главное - к знакомы словами прицепиться и ляпнуть что-нибудь.
> А эти слова случайно были не "си", "Linux" и "уязвимость"? Ну или
> какого тут поднялся такой многостраничный троллинг? :)Вот я и говорю: слова знакомые. ;)
>> Ну так трачу, представьте себе.
> Я рад за вас, все дела. Вам надо - вы и упираетесь,
> все честно. А в лично моем понимании, надежная система должна быть
> прежде всего простой как топор. Товарисч D. J. Berstein вон делом
> доказал что на си можно написать надежную программу. Кстати его понятияДа что ви говорите? "Надёжные программы" товарища Бернштейна даже TLS/SSL благоразумно не реализуют самостоятельно, отдавая на откуп внешним библиотекам. И правильно. Ибо когда весь из себя изолированный процесс ломают через дыру в OpenSSL и крадут приватный ключ, вся TLS плавно накрывается медным тазом, позволяя взломщикам тихо-мирно вклиниться в канал где-нибудь между сервером и клиентом, утянуть реквизиты через MitM и получить доступ к ящикам жертв без более глубокой компрометации системы. Товарищу Сирайнену тот же упрёк, в т.ч. по части недосказанности.
Вспомним также, что модель безопасности программ товарисча Бернштейна построена на разделении привилегий, которое "гарантированы" чем? Ничем, кроме дырявых монолитных вёдер современных ОС - тех самых, которые "достаточно неплохо работают". Компрометация любого из непривилегированных процессов (товарищ Гунинский вам напомнит об одной из таких возможностей, имевшихся ранее) открывает возможность к относительно незатратной компрометации всей системы. Но в изъянах ядра ОС товарисч Бернштейн, конечно же, не виноват. Он всего лишь сделал несколько наивных допущений при проектировании своих систем, о которых совершенно случайно забыл предупредить ещё более наивную публику. ;)
Хотите ещё об этом поговорить? ;)
> о надежности вообще не привязаны к языку - он вообще рассмотрел
> надежность программ, причины багов (в частности, проблем секурити) и как можно
> минимизировать оные. Почему-то ему си при этом нифига не помешал. ВАга, совсем не помешал. Кстати, на ассемблере и тем более на фортране можно писать такие системы, и ни один из языков - подумать только! - ни разу тому не помешает. ;) О КПД вопрос отдельный. Кстати, вы лично задумывались над ответом на него? ;)
> этом плане современное железо с даташитами на сотни страниц а то
> и больше - оставляет желать лучшего, вообще-то. В нем тоже багов
> - есть.Причём, баги в основном в части управления памятью и привилегиями. Но мы не будем показывать пальцем на человека, надёжность архитектурных решений которого, скажем так, не вполне зашкаливает в свете потенциального наличия таких багов (хотя это был Бернштейн). ;)
>>> потом крупные игроки пришли. А вы хотите чтобы за вас кто-то
>> Да, хочу.
> Хотеть не запретишь. Хотите себе. Имхо долго и не факт что успешно
> будете хотеть.Вредно не хотеть, я бы сказал.
>> я отвечал на чужой вопрос, а не в жилетку плакался.
> А по стилю больше похоже на плач несмеяны. Добро пожаловать в реальный
> мир, мир акул бизнеса, костылей и подпорок. Простите пожалуйста что вашиОй, я-то думал, в сказку попал! :D
> кульные теоретические концепты которые где-то там в теории могли бы хорошо
http://www.seas.gwu.edu/~mfeldman/ada-project-summary.html - где-то там. В теории, ага.
- делать что-то, тут никому нафиг не нужны, никто за это не
+ делать что-то, тут хомячкам нафиг не нужны, и они за это неFixed. ;)
> энтузазизм, голову и пару рук. Если сильно повезет - может сумеете
> сколотить команду единомышленников, а один из миллиона через ...цать лет может
> даже и найдет инвестора который купится на красивые спичи. Но этоВсё это происходит, вы просто не в курсе.
> не гарантировано, а кроме того, акул-инвесторов не интересуют все эти ваши
> концепции, их интересуют конкретные результаты, которые профит приносят. А как оноВенчурного инвестирования не существует, я вас правильно понял? :)
> там внутри сделано - им вообще насрать, вы прикиньте? :). И
Насрать хомячкам. Инвесторов, как вы сказали, интересуют результаты. И бизнес-планы по их достижению тоже, как ни странно.
> горе вам если вы сорвете сроки, не сможете сделать то что
> обещали и прочая - вазелина понадобится много.Вы путаете кредитование и инвестирование. Но вообще, посыл понятен и не нов. ;)
>> Дофига толку. Самолёты на них работают,
> А конкретные модели самолетов - осилите? А то я читал как у
> какого-то из боингов сделано - там ни про какие микроядра почему-то
> ни звука. Зато звуки про резервирование, юзание 2 разных архитектур процессоров,http://archive.adaic.com/projects/atwork/boeing.html - там на Аде всё. ;)
>> ракеты, космические корабли,
> Почему-то в них обычно стараются применять довольно примитивные процессоры. Наверное потомуРасскажите это создателям марсохода Spirit, большая часть софта которого на джаве написана. ;) Вот где она тормозит-то зверски, должно быть! :)
> что радиация и все такое, а чем сложнее проц - тем
> он нежнее к таким вещам и более склонен к сбоям, в
> нем более вероятны ошибки и прочая (никогда не пробовала почитать Errata
> на современные процы? Там жесткач полнейший, только его видят сильно некоторые
> :D). А на простом проце - обычно крутится нечто сильно кастомное,
> под задачу. У простого проца пардон даже системы деления привилегий может
> не быть. Ну и накукуй там микроядра? Там обычно простая как
> топор фирмварина которая выверена до битика и делает свою задачу.http://kronos.ru/about/koltashev - даже в СССР 80-ых годов софт для космоса писали на модуле. :Р Ну и расскажите теперь, как выверенные битики бороздят просторы бортовой электроники. ;)
>> судоходство и прочая промышленность, телекомы.
> Ой, почему-то в реально критичных к отказу местах стоят простые чипы, быстро
> реагирующие на события, а желательно и вообще аппаратные защиты, т.к. софтВ реально критичных к отказу и _сложных_ системах стоят вполне себе процессоры общего назначения на пару с этими вашими ПЛИС, и работает это на каком-нибудь эрланге. Гуглите Ericsson AXD-301 для примера. Та же циска давно ставит ОС на базе QNX6 (микроядро, которое медленное и никому не нужное) на свои старшие модели.
Короче, слив защитан. :Р
> и 100% надежность - очень трудносовместимые понятия. Простые - потому что
А вы не путайте надёжность и отказоустойчивость, и всё встанет на свои места.
> чем сложнее чип, тем он глючнее, менее предсказуем, в нем больше
> багов (да, в чипах тоже бывают баги, google://Errata если что). УНапример, некоторые надёжные чипы описывают на Haskell'е, с формальным доказательством соответствия спецификации и последующей трансляцией в императивные HDL. Но вы, кажется, рассказывали о процессорах для хомячков и ынтерпрайза... Я вас слушаю. :)
> простого чипа - и фирмварина простая как топор. Собссно микроядро -
> всего лишь выносит сложность из ядра в другие куски системы, а
> в целом сложность системы особо не падает. Как максимум можно собратьЛожь и провокация. ;) Возрастает отказоустойчивость - раз. Радикально уменьшается количество блокировок и разделяемых данных, и, как следствие, сложность - два.
> простую систему которая ничерта не умеет. Только что с ней потом
> делать на серверах и прочая? Ну, я знаю ровно 1 применениеВы загнали меня в тупик!!!1 Что же делать???7777
> на серверах и десктопах: назвать это гипервизором и изолировать друг от
> друга более сложные ОС. Но сложность систем никуда не девается иБлокировки и разделяемые данные - они никуда не деваются? Или деваются они, но не сложность? Я вас правильно понял? ;)
> баги остаются, ессно, просто они изолированы и локализованы :)
Баги остаются там, где остаётся Си. Та же Ада позволяет радикально сократить их количество практически даром. И "просто" изолированы и локализованы, ага.
>> Но это всё х#ита, конечно же. На ведь писюках нет?
> А знаете, если вы въе в стену на вашем авто и надо
> срочно вам подушку безопасности надуть, чтоб вы не выпорхнули в стекло
> и не размазались по стене - почему-то надувать ее, спасая вашу
> жо, будет в общем случае примитивный проц-"таракан" с датчиком и сНу так это потому, что надувалке многоядерный суперскаляр вообще никуда не фпилсо.
> не менее примитивной фирмвариной, чуть ли не единственной целью существования которого
> является именно это действо. И фирмварина примитивна и вылизана до битика,Да-да, вылизанные битики. ;)
> потому что если юзер вылетит в лобовое стекло - как-то нехорошо
> получится, да? А отсуствие многозадачности намекает на то что не надо
> ни защищаться от остальных задач, ни делить с ними время. СложностьА какие там остальные задачи? Музыку играет и в похоронное бюро звонит? :D
> системы падает в десятки раз. Вот тогда уже начинает идти разговор
> о какой-то там надежности решений, частью которых является софт. А пишут
> этот софт почему-то на асме и сях. Таких небезопасных, пля...Да-да, и в боингах, и в спутниках - один сплошной Си. ;)
>> Нет. Ну и слив защитан мне, да.
> Слив вам засчитан за то что существует например уйма мелких процов в
> критичных к отказу местах ... запрограмленых на этих самых жутко небезопасных
> сях и асме. При том баги в фирмваре оных - скорееТут кагбе выяснилось, что слив засчитан вам за Боинг и космос как минимум. ;)
> исключение чем правило. Потому что цена ошибки - соответствующая, и делается
> все возможное чтобы ошибок просто не было. Потому что внезапное надувание
> подушки без причины - как минимум очень неприятный сюрприз с риском
> для здоровья, а профукивание момента когда ее надо надуть - и
> вовсе может означать что юзер просто сыграет в ящик.Вы так превозносите надёжность и значимость элементарных программулек на Си. Идите в отдел пропаганды едра, им нужны таланты. :) Алсо, там ПЛИСы и ASICи, а ваш Си и рядом не лежал. :Р
> Угу, вы в основном просто набрасывали на вентилятор что линуксы - говно,
> си - отстой, только все это очень напоминает анекдот про цирк
> и "все клоуны - пи..сы!" :)Вы тоже нонанабрасывали. Только я обосновал, а вы - нет. :D
>> Не это ведь в троллинге главное, ага.
> Да уж! Так, глядя сколько тут натроллили из-за уязвимости которую можно поюзать
> только с спецжелезкой при физическом доступе к компу. Не, мне правда
> интересно, хотя-бы сотню компов на планете за следующие пару месяцев так
> сломают? :)Да-да, именно из-за этой уязвимости. Других нет. ;)
> EPIC FAIL C/C++.Имейте совесть! В вашей яве дыры безопасности чинят ДЕСЯТКАМИ в каждом релизе. Сначала перепишите вашу яву на ней самой а потом будете набрасывать. А то пилить сук на котором сидишь - это типичная изеновщина!
>> EPIC FAIL C/C++.
> Имейте совесть! В вашей яве дыры безопасности чинят ДЕСЯТКАМИ в каждом релизе.Пруф или не было!
> Сначала перепишите вашу яву на ней самой а потом будете набрасывать.
The Maxine Virtual Machine Project: http://labs.oracle.com/projects/maxine/
> А то пилить сук на котором сидишь - это типичная изеновщина!
Чегоооо?
>>> EPIC FAIL C/C++.
>> А то пилить сук на котором сидишь - это типичная изеновщина!
> Чегоооо?Он конечно же имел в виду, что ты ещё не дописал корректнес-прувер Си[++]-кода на своём Джавве, не доказал _его корректность и не прочекал свои обозаемые бизди коре^Wбеиз систем и джавве веэм.
Ваш К.О.
Ждём от тебя ОС на паскакале, а также компилятор умеющий все те же платформы и оптимизации что и хотя бы gcc.
Согласен. А Java не подходит для написания ядра операционных систем.
Забавно но не более. Ядро - точно такой же обычный код как и любой другой, который пишут самые обычные люди. Имеющие право на ошибку. Нашли-исправили - ну и молодцы.
просто ошибок скорее всего много, усб драйвера писались не очень квалифицированными кадрами на отмашь
А где не так?
> связанный с использованием для копирования содержимого строки небезопасной функции strcpy(), вместо учитывающего длину строки варианта strlcpy().Мдееееееее
Предупрежден - значит вооружен.
А почему бы ядру предварительно не "подравнять" строку идентификации устройства, а потом отдать драйверью на "самоидентификацию". Я так понимаю тот же udev вполне могбы это делать
> Я так понимаю тот же udev вполне могбы это делатьИ еще немножечко шить.
Если вы хотите пользоваться системой, которая лучше программ и пользователя знает, что им нужно - могу подсказать один адресок... а то и не один...
Ого, таки к 2011 году они нашли способ как сломать линуху через "флешку" (типа утрирую) всего то нужно уметь программить контроллеры с поддержкой юсб, знать особенности некоторых драйверов встроенных в ядро или модулем к нему, понимать принцип инициализации железа в линукс. Очень легкий способ, прямо-таки виндовый авторан (а это уже сарказм).Опасно только для тех к чьему компу имеют доступ левые люди.
> Ого, таки к 2011 году они нашли способ как сломать линуху через
> "флешку" (типа утрирую) всего то нужно уметь программить контроллеры с поддержкой
> юсб, знать особенности некоторых драйверов встроенных в ядро или модулем к
> нему, понимать принцип инициализации железа в линукс. Очень легкий способ, прямо-таки
> виндовый авторан (а это уже сарказм).
> Опасно только для тех к чьему компу имеют доступ левые люди.Ну да, в Иране тоже думали, что используя флешку и отключив авторан - все будет ок. Если у тебя нет паранои - это не означает что за тобой не наблюдают... А уязвимость уровня ядра - это всегда серьезно. Что еще раз подтверждает верный выбор архитектуры QNX для своей ОС.
> А уязвимость уровня ядра - это всегда серьезно. Что еще раз подтверждает верный выбор архитектуры QNX для своей ОС.Вообще то это как бы ортогонально. Совершенно похрену, что именно пробивать: ядро или io-usb или как там его. Собственно, usb сервис в QNX4/6 пробить даже легче. В том плане, что, будучи обычным процессом, работая с ним нет необходимости изголяться с ядерными руткитами и пр. специфичными заморочками. Вполне достаточно штатных готовых решений коих в сети вагон с маленькой тележкой.
так это просто говорит о том, что линукс стал популярнее, не более того. если бы надо было - нашли бы и 10 лет назад
> Ого, таки к 2011 году они нашли способ как сломать линуху через
> "флешку" (типа утрирую) всего то нужно уметь программить контроллеры с поддержкой
> юсб, знать особенности некоторых драйверов встроенных в ядро или модулем к
> нему, понимать принцип инициализации железа в линукс. Очень легкий способ, прямо-таки
> виндовый авторан (а это уже сарказм).Идите на Full-Disclosure и расскажите всем, как сложно, оказывается, адаптировать по чужим инструкциям чужие эксплойты для строковых переполнений в ванильном ядре. Все обрадуются и вздохнут с облегчением.
> Опасно только для тех к чьему компу имеют доступ левые люди.
Для хомячков неопасно, проблема надуманна, вопрос закрыт, ура.
интересно сработает уязвимость к виртуалке с проброшенным юсб
Скорее, сработает еще в гипервизоре - ибо проброс допустим в том же ESXi осуществляется опосредованно, через Linux DOM0
> Ого, таки к 2011 году они нашли способ как сломать линуху через
> "флешку" (типа утрирую) всего то нужно уметь программить контроллеры с поддержкой
> юсб, знать особенности некоторых драйверов встроенных в ядро или модулем к
> нему, понимать принцип инициализации железа в линукс.Не, ну а что, плохо чтоли? Пока выпускают патч, куча двуногих отхватит экспериенса оптом в цифровой технике сразу в куче направлений :)
1) Как НЕ НАДО писать программы. Конкретный пример ошибки и к чему она ведет - почти как у немцев в ролике про технику безопасности с расчлененкой :)
2) ЮСБ и что внутри
3) Микроконтроллеры и их дружба с юсб.
4) Как оно с линухом взаимодействует.После получения таких знаний вы сможете, пардон, пойти и сделать свой Kinect или что там еще, с шахматами и поэтессами.
> Опасно только для тех к чьему компу имеют доступ левые люди.Ога, идешь так по ДЦ, хоп, стойка не закрытая - тык-вытык флеху и дальше идешь, а там уже доступ к тебе на мыло скидывается...
>> Опасно только для тех к чьему компу имеют доступ левые люди.
> Ога, идешь так по ДЦ, хоп, стойка не закрытая - тык-вытык флеху
> и дальше идешь, а там уже доступ к тебе на мыло
> скидывается...А видеокамер там типа нету?
> Ога, идешь так по ДЦ, хоп, стойка не закрытая - тык-вытык флехуНормальный такой ДЦ, где посторонние могут безнаказанно тыкать ваш сервер.
Реальность приблизилась к картине из боевика. :) Типа, в бункер проникает группа лиц высочайшей квалификации и 5 сек взламывает корпоративный кластер, втыкая в разъем такую штучку, похожую на флешку. Без перезагрузок и остановки сервера сливают нужные данные и благополучно (или нет) покидают место преступления. :)
> Реальность приблизилась к картине из боевика. :) Типа, в бункер проникает группа лиц высочайшей квалификации и 5 сек взламывает корпоративный кластер, втыкая в разъем такую штучку, похожую на флешку. Без перезагрузок и остановки сервера сливают нужные данные и благополучно (или нет) покидают место преступления. :)Вообще то, это сможет сделать даже уборщица. Будучи предварительно снабжена соответствующей 'флешкой'. Прошел мимо воткнул-выткнул зараза села пошел дальше. Какой уж там боевик..
Не, это конечно да.. Но с перестрелкой и спецэффектами веселее как-то. Не везде ведь уборщиц пускают в серверные. Да и шкафы закрыты.
> Не, это конечно да.. Но с перестрелкой и спецэффектами веселее как-то. Не везде ведь уборщиц пускают в серверные. Да и шкафы закрыты.Не завидую админам, в серверные которых никогда не пускают уборщиц...
в нашей серверной уборщиц не было лет 5. и почему Вы нам не завидуете?
> в нашей серверной уборщиц не было лет 5. и почему Вы нам не завидуете?Грязь же, нет? Разве что эта 'серверная' все пять лет была закрыта и работала абсолютно автономно и туда никто не заходил. В противном случае, грязь и пыль все равно заносится.
А если посмотреть на вещи реалистичнее, то среднестатистические адмыны зачастую любят ещё и посидеть в этом адском месте, покурочить что-нить. Кваку погонять. Сутками. Ессно с кофем пивом чипсами печеньками и пр. Со всеми вытекающими (иногда на пол).
>> в нашей серверной уборщиц не было лет 5. и почему Вы нам не завидуете?
> Грязь же, нет?Раз в три месяца подмести и раз в пол-года помыть полы не так уж трудно. Если, конечно, туда не табунами ходят. Сначала уборщицу не пускали потому что в серверной на полу осталось много кабелей после переезда, сейчас валяющихся кабелей нет, всё закрыто в шкафах, но всеравно не пускаем, т. к. бабке трудно объяснить, что в воду нужно добавлять антистатик и менять в ведре воду 3 раза, а не размазывать грязной тряпкой ровным слоем пыль по всей площади.
> Раз в три месяца подмести и раз в пол-года помыть полы не так уж трудно. Если, конечно, туда не табунами ходят. Сначала уборщицу не пускали потому что в серверной на полу осталось много кабелей после переезда, сейчас валяющихся кабелей нет, всё закрыто в шкафах, но всеравно не пускаем, т. к. бабке трудно объяснить, что в воду нужно добавлять антистатик и менять в ведре воду 3 раза, а не размазывать грязной тряпкой ровным слоем пыль по всей площади.Ну так нефик на чистоте экономить! Нужно брать бабушек с профильным ВО в звании не ниже капитана с соотв. допуском. И все будет ок.
> Ну так нефик на чистоте экономить! Нужно брать бабушек с профильным
> ВО в звании не ниже капитана с соотв. допуском. И все будет ок.Тогда уже лучше самому сообщить капитану рутовый пароль и пододвинуть удобное кресло.
> Нужно брать бабушек с профильным ВОНужно. Но по поводу "брать" не ко мне. Я лишь винтик в огромной бюрократической машине. А на предлагаемую зарплату бабушки с профильным В/О идти что-то не хотят. Да и в этом году хотят направление офис-клининга отдать в аутсорсинг, вот тогда вообще дело "труба" будет (ИМХО). (Вспоминая _КАК_ рабочие подрядной организации устанавливали кондиционер, я с ужасом представляю что будут творить уборщицы...)
> А если посмотреть на вещи реалистичнее, то среднестатистические адмыны зачастую любят ещё
> и посидеть в этом адском месте, покурочить что-нить. Кваку погонять. Сутками.
> Ессно с кофем пивом чипсами печеньками и пр. Со всеми вытекающими
> (иногда на пол).Играть в серверной? Брр, какой ужас, холодно, шумно, неудобно. Неужели не приятнее в уютном кабинете в любимом продавленном кресле с выставленным в "прохладу" кондиционером сидеть?
>> в нашей серверной уборщиц не было лет 5. и почему Вы нам не завидуете?
> Грязь же, нет? Разве что эта 'серверная' все пять лет была закрыта
> и работала абсолютно автономно и туда никто не заходил. В противном
> случае, грязь и пыль все равно заносится.
> А если посмотреть на вещи реалистичнее, то среднестатистические адмыны зачастую любят ещё
> и посидеть в этом адском месте, покурочить что-нить. Кваку погонять. Сутками.
> Ессно с кофем пивом чипсами печеньками и пр. Со всеми вытекающими
> (иногда на пол).ну вот нет грязи. в уличной обуви там никто не ходит, окон нет. не буду говорить, что на полу "можно есть", но и залежей пыли за шкафами или песка на полу не наблюдается.
а уж про "посидеть"... - в серверной прохладно и очень шумно - что нифига не увеличивает желание поработать в оной :)
Вполне реально, почему нет. Пыли-грязи нет, потому как очистка воздуха и кондюшник. Серверная закрыта плотно, войти можно в сменной обуви и халате. Админы заходят чтоб диск в рейде поменять. Для экспериментов у них свое помещение есть. Ну а я не стану завидовать админам, которые кофе с печеньками на выдвинутом юните пьют. Описываю случай правильный и идеальный. В жизни действительно часто не так, но есть. Често, сам видел. Входил по пропуску. Парень со службы охраны так и мотался за нами, за дверями стоял. Хотя вроде ничего у них особенного такого и не было, инфы никакой. Узел коммутации на область.
Ога, корпоративный кластер, на корпоративных кластерах этот модуль так необходим.
>/lib/modules/2.6.*/kernel/sound/usb/caiaq/snd-usb-caiaq.ko
> Ога, корпоративный кластер, на корпоративных кластерах этот модуль так необходим.Ну если на то пошло, то на корпоративном кластере вообще очень необходимы ядра 2.6.37+ а особенно сегодня...
>> Ога, корпоративный кластер, на корпоративных кластерах этот модуль так необходим.
> Ну если на то пошло, то на корпоративном кластере вообще очень необходимы
> ядра 2.6.37+ а особенно сегодня...Других переполнений в других драйверах нет, да. А все кластеры работают на пересобранных ядрах без лишних драйверов и с отключённой поддержкой автозагрузки модулей, ага.
Вы сперва доберитесь до USB на лезвии, угу.
Короче это феерическая уязвимость в вакуме, все бы такие, массово эпидемию цервей и вирусов не вызовет, позволит в общем-то сломать хакеру один конкретный комп, то есть опасна в плане конкуренты подкупят уборщика что бы тот вставил спец устройство в сервер и слил секретную инфу, вопрос чего делает на сервере юсб порт открыт. Короче для серьезных систем серьезные уязвимости, так даже жить как-то интереснее.
Что делать, если я не использую этот драйвер caiaq? Что делать, как помочь потенциальному злоумышленнику?
> Что делать, если я не использую этот драйвер caiaq? Что делать, как помочь потенциальному злоумышленнику?А его не нужно 'использовать'. Вполне достаточно, чтобы он присутствовал в системе. При появлении в порту соотв. устройства его поднимут автоматически.
"не использую" == "отсутствует в системе"
Расскажи о методе терморектального криптоанализа
In order to successfully exploit the vulnerability described in this advisory, an attacker would need to have physical access to the affected system in order to be able to plug in a malicious USB device.Дальше не читал. Подобных "уязвимостей" вагон и маленькая тележка, особенно у шины FireWire.
Уязвимость класса "а я сервак забутал и вместо инита шелл вписал" :-D Только сложнее делается. Железку надо паять, программизмом занимаццо...
> In order to successfully exploit the vulnerability described in this advisory, an
> attacker would need to have physical access to the affected system
> in order to be able to plug in a malicious USB
> device.
> Дальше не читал. Подобных "уязвимостей" вагон и маленькая тележка, особенно у шины
> FireWire.Ну так даже дядя -- не мой! -- Билл сказал, что "если у злоумышленника есть физический доступ к вашему компьютеру, то это уже не ваш компьютер". А уж дядя Билл умеет впарить трояна.
> In order to successfully exploit the vulnerability described in this advisory, an
> attacker would need to have physical access to the affected system
> in order to be able to plug in a malicious USB
> device.
> Дальше не читал. Подобных "уязвимостей" вагон и маленькая тележка, особенно у шины
> FireWire.Hint: ты можешь сам подключить подключить такое устройство. Вредоносное ПО для смартфонов -- это реальность.
Уязвимость — она, конечно, и в Африке уязвимость, но что-то мне кажется, что autorun.inf на обычной флешке гораздо более опасный, чем уязвимость в модуле ядра для которой нужноа) иметь вышеуказанный модуль в системе (да, tinycore вряд ли его имеет)
б) иметь разрешение владельца компьютера всунуть в USB какую-то хреновину (не флешку!)
в) иметь эту самую хреновину и запрограммировать ее нужным образом
После решения (в) обернуть устройство в корпус флешки не составит труда (б).
> Уязвимость — она, конечно, и в Африке уязвимость, но что-то мне кажется,
> что autorun.inf на обычной флешке гораздо более опасный, чем уязвимость в
> модуле ядра для которой нужно
> а) иметь вышеуказанный модуль в системе (да, tinycore вряд ли его имеет)И какой процент линуксов идёт с такими ядрами? Никакой.
> б) иметь разрешение владельца компьютера всунуть в USB какую-то хреновину (не флешку!)
Это запросто. Оставить "флэшку" в курилке и прочая инженерия уже давно откровением не является.
> в) иметь эту самую хреновину и запрограммировать ее нужным образом
Сложно, но возможно. Особенно по чужим инструкциям, с эксплойтом на базе одного из фреймворков.
> И какой процент линуксов идёт с такими ядрами?К примеру, в Owl вообще нет модулей ядра для звука, они там ни к чему.
>> И какой процент линуксов идёт с такими ядрами?
> К примеру, в Owl вообще нет модулей ядра для звука, они там
> ни к чему.Я знаю. И какой процент у Owl? Никакой, хоть и незаслуженно.
> Это запросто. Оставить "флэшку" в курилке и прочая инженерия уже давно откровением
> не является.Ой, анонимусы вон натянули конторку "безопасностью" методом инженерии без всяких флешек. Они спросили пасс на ссш и попросили выключить фаер. И главное им сказали пасс и вырубили фаер. И затрат сил в 100 раз меньше, и против идиотов - любая ОС бессильна. В итоге куча почты этой кульной конторки теперь вывалена в торентах и читается всеми желающими, конторка ощущает на себе как выглядит EPIC FAIL перерастающий в полярного лиса, ну а анонимусы явно отхватили EPIC WIN... настолько EPIC что вы даже с 10 флехами пожалуй такого не отхватите :)
>в) иметь эту самую хреновину и запрограммировать ее нужным образомконтроллер стоит около 3-5$, в корпус флешки умещается на раз, конечное устройство будет стоит не дороже 10$
поповоду программирования: для этих девайсов вагон и маленькая тележка примеров, в том числе усб. ну да, нужна некоторая изобретательность (как и всегда) чтобы всунуть вредноносный код, но это такое
>Драйвер caiaq, разработанный в рамках проекта ALSA для звуковых плат компании Native Instruments, входит в базовую поставку Linux-ядра и загружается автоматически в большинстве Linux-дистрибутивов, включая серверные системы.Зачем на серверной системе нужна звуковая плата (и вообще поддержка звуковых устройств)?
Чтобы предотвратить загрузку драйвера:$ echo 0 > /sys/bus/usb/devices/usbX/authorized_default
Documentation/usb/authorization.txt
> Чтобы предотвратить загрузку драйвера:
> $ echo 0 > /sys/bus/usb/devices/usbX/authorized_default
> Documentation/usb/authorization.txtСколько понаписали и только один человек догадался написать простое решение. Как вариант можно вообще составить список основных модулей ядра, а потом
sysctl -w kernel.modules_disabled=1p.s.
У меня почему-то нет Documentation/usb/authorization.txt
> Сколько понаписали и только один человек догадался написать простое решение. Как вариант
> можно вообще составить список основных модулей ядра, а потом
> sysctl -w kernel.modules_disabled=1В authorized в некотором смысле более жёсткое разграничение - можно запретить порт для конкретного подключения, даже если драйвер уже загружен. Т.е. если известно, что драйвер бажный, но у вас есть доверенная железка, то можно вручную её разрешить. Но когда втыкается недоверенная железяка с тем же ассоциированным драйвером, если в sysfs ничего не писать, то компрометации не будет. В отличие от modules_disabled, где все устройства с тем же ID равны.
> p.s.
> У меня почему-то нет Documentation/usb/authorization.txtЕсли у кого-то ещё нет :)
http://www.mjmwired.net/kernel/Documentation/usb/authorizati...
Ответ оценил. Интересную штуку написал Инакий Перец-Гонзалес из Интел. :-)> В authorized в некотором смысле более жёсткое разграничение
Скорее более гибкое и скриптовать больше. Но круто однозначно. Если уж размышлять дальше, то может быть так, что ошибка будет в каком-нибудь "соседнем" модуле. Например, в драйвере ФС или еще каком-нибудь обработчике блочного устройства. В примере по ссылке эксплуатация уязвимости возможно в момент монтирования устройства для проверки. В первичном выступление парня из IBM что-то есть на тему, но подробно не помню, а пересматривать лень.
> Если уж размышлять
> дальше, то может быть так, что ошибка будет в каком-нибудь
> "соседнем" модуле. Например, в драйвере ФС или еще каком-нибудь обработчике блочного
> устройства.Уже размышляли и не раз. Последний раз тут:
http://www.openwall.com/lists/oss-security/2011/02/23/5Проблема в том, что в стандартную модель безопасности не вписывается физический доступ к машине. Практически все компоненты системы, работающие с устройствами, не ожидают некорректного ввода и практически не проверены на переполнения и пр. Файловые системы, уровень блочного устройства, партишны, драйвера устройств - целей у атакующего довольно много.
Единственная ИМХО существующая защита - это автоматическое монтирование флешки с nosuid,nodev, но этого, очевидно, недостаточно.
Я верю, что не америку открыл, просто хотел сказать, что пишу одну теорию. Модель безопасности не учитывает физический доступ, вот как? (линк гляну позже) За родину обидно, будут теперь всякие подпорки делать. nosuid, nodev - имхо, совсем бесполезно.
А еще эта новость про ошибку на уровне драйвера, а в видео от IBM все-таки в юзерспейсе убивали скринсейвер (тут я жду, когда полностью весь в дистрибутиве будет собираться с -fPIC и соотв. использовать ASLR).
А новость писал чем-то обрадованный пользователь OpenBSD, исходя из имени правильной функции strlcpy()?
> А новость писал чем-то обрадованный пользователь OpenBSD, исходя из имени правильной функции strlcpy()?http://git.kernel.org/?p=linux%2Fkernel%2Fgit%...
--- a/sound/usb/caiaq/audio.c
+++ b/sound/usb/caiaq/audio.c
@@ -785,7 +785,7 @@ int snd_usb_caiaq_audio_init(struct snd_usb_caiaqdev *dev)
}
dev->pcm->private_data = dev;
- strcpy(dev->pcm->name, dev->product_name);
+ strlcpy(dev->pcm->name, dev->product_name, sizeof(dev->pcm->name));
memset(dev->sub_playback, 0, sizeof(dev->sub_playback));
memset(dev->sub_capture, 0, sizeof(dev->sub_capture));Причем тут OpenBSD? Она и в Linux ядре есть (linux/string.h)
Другой вопрос, что http://en.wikipedia.org/wiki/Strlcpy
GNU C Library maintainer Ulrich Drepper is among the critics of the strlcpy and strlcat functions;[2] consequently these functions have not been added to glibc. Drepper argues that strlcpy and strlcat make truncation errors easier for a programmer to ignore and thus can introduce more bugs than they remove.[2] His concern with possible truncation, when using any string function involving static allocation, is shared by others.[3]
И с этим тоже нельзя не согласиться. Обрезание данных и их корректная валидация - это две большие разницы. И тупое использование strlcpy может повлечь за собой наведенные ошибки уже совсем другого рода.
С критикой, конечно, нельзя не согласиться. А вот с тем, что на основании этой критики функцию не включают в стандартную библиотеку, согласиться уже никак нельзя. По, как минимум, двум причинам:1) совместимость: strcat/strcpy, очевидно, куда опаснее, и тем не менее они всё же поддерживаются
2) не включать на основании "тупое использование повредит" - это не Unix-way подход, а виндовый. Для того, кто знает, что делает, возможность должна присутствовать. В конце концов, в ядре и glib она есть, а в glibc нету, с какой стати Дреппер считает себя умнее?..
> 1) совместимость: strcat/strcpy, очевидно, куда опаснее, и тем не менее они всё же поддерживаютсяЭто - ANSI C. Плох он или хорош - это тем не менее стандарт. Так что - приходится.
> 2) не включать на основании "тупое использование повредит" - это не Unix-way подход, а виндовый. Для того, кто знает, что делает, возможность должна присутствовать. В конце концов, в ядре и glib она есть, а в glibc нету, с какой стати Дреппер считает себя умнее?..
А почему собственно дядя Дреппер - глупее? Почему strlcpy есть в ядре - понятно. Уже готовые 3d party драйвера. Тут хочешь не хочешь, но включишь. Не до жиру. Почему в glib есть - тоже понятно. Туда какой только гадости не пихают - все, до чего руки дотянутся. Что тут удивляться.. А вот зачем пихать нестандартную и вызывающую вполне обоснованные нарекания strlcpy в стандартную, замечу, libc - это конечно большой вопрос. В конце-концов, если так хочется strlcpy - берите glibc и вперед, с песнею. Иначе уже завтра (злая) половина гнутых поделий будет обвешана такими мелкими 'стандартными' (в одной системе) хаками, как елка игрушками. Вот включат strlibc в ANSI C/POSIX - пожалуйста.
> вызывающую вполне обоснованные нарекания strlcpy в стандартную, замечу, libc - это
> конечно большой вопрос. В конце-концов, если так хочется strlcpy - берите
> glibc и вперед, с песнею. Иначе уже завтра (злая) половина гнутыхGlibc - единственная мейнстримная libc, в которой нет strl-функций.
> Glibc - единственная мейнстримная libc,
Fixed
>> 1) совместимость: strcat/strcpy, очевидно, куда опаснее, и тем не менее они всё же поддерживаются
> Это - ANSI C. Плох он или хорош - это тем не
> менее стандарт. Так что - приходится.А подумать? В стандарте оно до сих пор именно по причине совместимости.
>> 2) не включать на основании "тупое использование повредит" - это не Unix-way подход, а виндовый. Для того, кто знает, что делает, возможность должна присутствовать. В конце концов, в ядре и glib она есть, а в glibc нету, с какой стати Дреппер считает себя умнее?..
> А почему собственно дядя Дреппер - глупее? Почему strlcpy есть в ядре
> - понятно. Уже готовые 3d party драйвера. Тут хочешь не хочешь,
> но включишь. Не до жиру. Почему в glib есть - тоже
> понятно. Туда какой только гадости не пихают - все, до чего
> руки дотянутся. Что тут удивляться.. А вот зачем пихать нестандартную и
> вызывающую вполне обоснованные нарекания strlcpy в стандартную, замечу, libc - этоДядя Дреппер _считает_ себя умнее и вправе указывать другим. У него и других идиосинкразий хватает, впрочем, об этом лучше netch расскажет. Кроме glib, еще есть кеды, самба и rsync - они тоже идиоты гадость пихают, да? Ну и "готовые 3d party" - это ровно та же причина, совместимость. Приложений-то, чай, побольше с этой функцией будет, чем драйверов.
На самом деле за позицией Дреппера совершенно явно торчат уши "оно придумано не нами, а в BSD" - иначе бы в обосновании была не идеологически-политическая хрень (а у *никсов, напомню, философия Tools, not policy), а гораздо более практичное "оно по-разному работает на BSD и солярке, чего нам выбрать-то?".
> Иначе уже завтра (злая) половина гнутых
> поделий будет обвешана такими мелкими 'стандартными' (в одной системе) хаками, как
> елка игрушками. Вот включат strlibc в ANSI C/POSIX - пожалуйста.Вы, может быть, сильно удивитесь, но они _уже_ обвешаны хаками от одной системы, причем как бы уже не половина, а большинство софта написаны непортабельно, т.е. на отличных от Linux системах собираются только с напильником.
> А подумать? В стандарте оно до сих пор именно по причине совместимости.При чем здесь - подумать? Стандарт на libc есть? Есть. В стандарте strcpy & K присутствуют? Присутствуют. Пардон, но если реализация libc претендует на совместимость со стандартом она просто обязана их иметь. Не задавая ненужных вопросов на тему хорошие они или нет. Пусть каждый сам для себя решает - использовать ту или иную ф-ть предоставляемую *стандартной* libc или же не использовать.
> Дядя Дреппер _считает_ себя умнее и вправе указывать другим. У него и других идиосинкразий хватает, впрочем, об этом лучше netch расскажет. Кроме glib, еще есть кеды, самба и rsync - они тоже идиоты гадость пихают, да? Ну и "готовые 3d party" - это ровно та же причина, совместимость. Приложений-то, чай, побольше с этой функцией будет, чем драйверов.
Дядя Дреппер как бы не ананимус с лора. В отличие от он все-таки мейнтейнит ту самую glibc. И было бы очень странным, если бы он в свою очередь не имел права веского а то и решающего голоса. Равно как и права иметь своё, собственное, мнение на то, как и что должно включаться в его проект а что - нет. Не нравится? Используйте что-то другое, делайте своё, etc - не проблема. Существует достаточно большое количество систем в том числе популярных, в которых нет 'проблемы' в лице дяди Дреппера. Впрочем, в каждой из них есть уже свой дядя ровно с такими же правами вето и своими собственными тараканами в голове.
Причем тут кеды, самба и рсинк я так и не понял. Если я не ошибаюсь, мы сейчас про strlcpy и glibc. Внутренности самбы сами по себе вызывают большие сомнения в адекватности разработчиков. Использовать strlcpy в кедах, имея на руках нормальный C++ в придачу с Qt - тоже.
> На самом деле за позицией Дреппера совершенно явно торчат уши "оно придумано не нами, а в BSD" - иначе бы в обосновании была не идеологически-политическая хрень (а у *никсов, напомню, философия Tools, not policy), а гораздо более практичное "оно по-разному работает на BSD и солярке, чего нам выбрать-то?".
Интриги заговоры разоблачения... Враги. Вокруг одни враги, это факт.
> Вы, может быть, сильно удивитесь, но они _уже_ обвешаны хаками от одной системы, причем как бы уже не половина, а большинство софта написаны непортабельно, т.е. на отличных от Linux системах собираются только с напильником.
То, что что-то обвешано хаками - это конечно же веский повод добавить ещё одну степень свободы. Чтобы уж до кучи.
klalafuda, вот не надо FUDа. В этом сообщении нет ни одного аргумента, одна херота. Ответить можно только на абзац о самбе: в приводившейся статье на википедии есть такое: "Many application packages and libraries include their own copies of these functions, including glib, rsync, Samba, KDE, and the Linux kernel itself."
> klalafuda, вот не надо FUDа. В этом сообщении нет ни одного аргумента, одна херота. Ответить можно только на абзац о самбе: в приводившейся статье на википедии есть такое: "Many application packages and libraries include their own copies of these functions, including glib, rsync, Samba, KDE, and the Linux kernel itself."Ну и что, что некоторые пакеты включают? А некоторые ещё и BSDшные анахронизмы за собой таскают вместо того, чтобы использовать современные ANSI C/POSIX аналоги. Видимо, им так удобнее. Да и хрен бы в общем то с ними. Но это явно не повод включать все это хозяйство в стандартную libc. Содержимое которой в первую очередь регламентируется не пожеланиями того или иного гения но вполне конкретным описанным стандартом. Хотите расширений в любых мыслимых измерениях? Какие проблеме - используйте glib & K или аналоги.
PS: С учетом того, что оппонент плавно перешел на матерную аргументацию своих мыслей, это ветку, я думаю, можно плавно закруглять.
> то с ними. Но это явно не повод включать все это
> хозяйство в стандартную libc. Содержимое которой в первую очередь регламентируется не
> пожеланиями того или иного гения но вполне конкретным описанным стандартом. Хотите
> расширений в любых мыслимых измерениях? Какие проблеме - используйтеЭто не аргумент, потому что расширения сверх стандарта в glibc присутствуют, и не так уж мало. Остальное - опять херня.
> PS: С учетом того, что оппонент плавно перешел на матерную аргументацию своих
> мыслей, это ветку, я думаю, можно плавно закруглять.Могу посоветовать посмотреть на Луговского.
> Могу посоветовать посмотреть на Луговского.1) не стоит (я был против допущения его в ALT и свои разрушения там он нанёс);
2) тем более не стоит, что http://m-ike.livejournal.com/118340.html
>> Могу посоветовать посмотреть на Луговского.
> 1) не стоит (я был против допущения его в ALT и свои
> разрушения там он нанёс);
> 2) тем более не стоит, что http://m-ike.livejournal.com/118340.htmlМихаил, я немного более в курсе ситуации с Луговским, чем большинство сторонних людей. Я с ним не раз переписывался лично. И про этот пост, разумеется, был в курсе, когда писал. Так вот, в контексте треда - не роляет совершенно.
А скажите мне не посвященному, какая проблема админу отключать и включать драйвер USB скриптом? Само собой включать по делу когда без этого никак? Домашним пользователям я думаю все это монопенисуально. Тем кому нужна защита аж прямо досмерти этого USB, втыкайте флешку в другой комп соединенный с первым по сети. Сейчас они стоят копейки Соответственно держите только один LAN порт открытым
> А скажите мне не посвященному, какая проблема админу отключать и включать драйвер USB скриптом? Само собой включать по делу когда без этого никак? Домашним пользователям я думаю все это монопенисуально. Тем кому нужна защита аж прямо досмерти этого USB, втыкайте флешку в другой комп соединенный с первым по сети. Сейчас они стоят копейки Соответственно держите только один LAN порт открытымЭэээ... И что же должно стоять на этом, другом, компе? Что туда можно совершенно безопасно втыкать флешки?
> Ээээ... И что же должно стоять на этом, другом, компе? Что туда
> можно совершенно безопасно втыкать флешки?Я понимаю что вы мне намекаете что второй комп тоже будет взломан с пом. этой тулзы по USB, а я хотел сказать, что взломаный линукс, не делает проблем с передачей файла через LAN на "чистый компьютер".
Кроме того малый комп, я подчеркиваю, если все уже так очень сурово, может иметь линукс загружаемый с SD, карточки у которой стоит защелка на защиту от записи на саму эту SD. При перезагрузке вся хрень с малого компа умрет. Ну а если вирусятина делает невозможным работу малого компа, (хотя это редко когда было целью вирусописателей), то тот кто принес такую флешку, должен быть поимет. Чем не вариант?
Хы, прикол. Молодцы, развили всё-таки идею! Пользу людям сделали.
это же победа!
/me достал свою плату на at91sam7s128 и пошел писать усб
> это же победа!
> /me достал свою плату на at91sam7s128 и пошел писать усбИ правда - победа :)). Попрактиковаться в програминге sam7 - всяко не вредно. Хотя cortex'ы уже актуальнее :P. Вот такое вот отличие: виндузятники матерятся на авторан и выгребают вири. А *никсоиды програминг юсб в микроконтроллерах осваивают :)). Так держать!
>от такое вот отличие: виндузятники
> матерятся на авторан и выгребают вири.M$ официально запатчил авторан.
> M$ официально запатчил авторан.Ага, не прошло и 20 лет как до них все-таки дошло, что у юзеров от этого оказывается вирусы бывают! А сколько там лет до этого вирусня автоматом попадала с mp3 плееров, фотоаппаратов и прочих флешек и винчей юзерам на компы? Заметьте, со стандартной флехи/фотоаппарата/плеера/прочего являющегося стандартным mass storage. Что "немного" серьезнее чем поимение системы путем создания кастомной железки. Ну вот и посмотрим, смогут ли пингвиноиды повторить такой антирекорд. Я готов поспорить что не смогут :)
Если есть физический доступ к серваку, то и без всяких USB-приблуд можно получить root-доступ.
> Если есть физический доступ к серваку, то и без всяких USB-приблуд можно
> получить root-доступ.Без клавиатуры и монитора ??? И вероятность быть пойманным и замеченным при этом почти 100%. Попробуйте получить доступ к системе, пока сотрудник на 20 секунд отошел налить себе кофе или сделать ксерокопию.
PS. Сдается мне, что strcpy там не случайно и об этой уязвимости уже давно кто нужно знал. Информация для размышления: http://hbgary.anonleaks.ch/greg_hbgary_com/21960.html
> PS. Сдается мне, что strcpy там не случайно и об этой уязвимости
> уже давно кто нужно знал. Информация для размышления: http://hbgary.anonleaks.ch/greg_hbgary_com/21960.htmlТолько планы спалили, дырки починят :) не так уж и плохо вроде? :)
ЗЫ кстати судя по планам конторы HBGary - у них там сплошные Наполеоны работают. Эх, анонимусы такое гнездо Наолеонов разогнали :).Они бы и дальше отжигали с своими требованиями из разряда "мы не знаем как это сделать но надо чтобы было зашибись, желательно по нажатию 1 большой кнопки".
>>http://hbgary.anonleaks.ch/greg_hbgary_com/21960.htmlО! Сделали удобный просмотр! Я видать жираф и только что увидел.
конечно большое IMHO, но все это очень смахивает на нормальный такой бэк-дор
даа зачетная такая дырень, слепить usb хреновину и по пути к своей циске незаметно так воткнуть девайс в пару линупсовых сервачков самое оно.и что характерно User294 по обычаю в таких темах не отписывается, павлинтус тихо молчит в тряпочку, а Мишу Шигорина ваще не видать. Где вы поборники БЫСТРОГО линукса? по?й на дыры, главное же быстро!
А учитывая последние тенденции разработчегов скрывать причины патчей, скоро можно ожидать разоблачения великого мифа линуксов как безопасных систем.
> скоро можно ожидать разоблачения великого мифа линуксов как безопасных системвначале подождём пока ломающие драйвера появятся... а то что Линукс может работать даже на помойном аппаратном шлаке мы и без вас знаем
> и что характерно User294 по обычаю в таких темах не отписывается, павлинтус тихо молчит в тряпочку, а Мишу Шигорина ваще не видать. Где вы поборники БЫСТРОГО линукса? по?й на дыры, главное же быстро!Ващето сегодня, если конечно кто не заметил - 8е марта. Праздник типа на дворе. Что привязался к людям? Празднуют они. Как закончат - отпишутся. Хорошо если не с бодуна. Иначе пожалеешь, что вспомнил..
>> и что характерно User294 по обычаю в таких темах не отписывается, павлинтус тихо молчит в тряпочку, а Мишу Шигорина ваще не видать. Где вы поборники БЫСТРОГО линукса? по?й на дыры, главное же быстро!
> Ващето сегодня, если конечно кто не заметил - 8е марта. Праздник типа
> на дворе. Что привязался к людям? Празднуют они. Как закончат -
> отпишутся. Хорошо если не с бодуна. Иначе пожалеешь, что вспомнил..Да, поздравили с утра ещё %)
А вот часов с трех дня, наблюдаю за кипишем :) Главное из-за чего,
из-за strcpy(), который, помоему, второй в хит-параде косяков послеptr = NULL;
...
if ( ptr->data )---
Нате, пошуршите по ядру, откройте тучу strcpy()# find . -name *.[ch] -exec sed '/strcpy/!d; /\");/d' {} \;
strcpy(path2, path);
strcpy(path2, path);
strcpy(dst+len, args[i]);
strcpy(ifr.ifr_name, ifname);
strcpy((char*)ZERO_PGE, envval);
strcpy(name, tmp);
strcpy(boot_command_line, command_line);
strcpy(command_line, boot_command_line);
strcpy(cp2, cp1);
strcpy(tag->u.cmdline.cmdline, params->commandline);
strcpy((char *)ec->card_desc, incd.d.string);
strcpy(buf, s);
strcpy(pad->name, bpad->name);
strcpy(options, omap_mux_options);
strcpy(dst->muxnames[i], src->muxnames[i]);
strcpy(dst->balls[i], src->balls[i]);
strcpy(pdev_name2, pdev_name);
strcpy(init_utsname()->machine, cris_machine_name);
strcpy(command_line,CONFIG_KERNEL_COMMAND);
....Пля, ломай не хочу :)
Я день выступлений проституток, импортированный кларой цеткин, не праздную и другим не советую.А по заданному вопросу -- дырка и дырка, если у кого-то в типа trusted environment шатаются люди со своими девайсами и мимо камер их суют во включенные порты -- видимо, что-то недодумано. Потому как с 1394 (которого на серверах пока не встречал вроде, правда) доступ к памяти хоста вообще является неотъемлемой фичей by design и никаким обновлением драйвера это не заткнуть, только отключением подсистемы.
Тут новость об эксплуатации ошибки, а не фичи. А доступ к памяти в том же 1394 по умолчанию в линуксе всегда была отключён, в отличие от винды.
> Я день выступлений проституток, импортированный кларой цеткин, не праздную и другим не
> советую.ну да клара цеткин проститутка, один шигорин дартаньян, угу, nucliht мне открыл глаза на то кто ты есть на самом деле, впрочем я и не сомневался...
> А по заданному вопросу -- дырка и дырка, если у кого-то в
> типа trusted environment шатаются люди со своими девайсами и мимо камер
> их суют во включенные порты -- видимо, что-то недодумано. Потому
> как с 1394 (которого на серверах пока не встречал вроде, правда)
> доступ к памяти хоста вообще является неотъемлемой фичей by design и
> никаким обновлением драйвера это не заткнуть, только отключением подсистемы.не юли, честно признай это дырень в линуксе, да в том самом линуксе на который всех денно и нощно агитируешь, рассказываешь всем что девелопить под другие ОС это %лядство, а девелопить в альте, в высшем обществе это королевская привелегия. Линукс стоит в сервере и солярка, или венда, или чпукс, этот факт никак не зависит от людей работающих в датацентрах. Ато получается если дырень в линуксе то значит нужно датацентр закрыть на замок, три слоя охраны и главное камер к каждому серваку натыкать. Как это у вас звучит? Если у вас что-то не работает то вам это не нужно.
Линукс дыряв by design иначе бы не появлялись все эти SE-Linux (который большинство сразу вырубает), hardened версии и прочее. Торвальдс никогда не ставил безопасность во главу угла, его всегда устраивал уровень качества и безопасности линукса, поэтому аппелировать вы можете только к вашему кормчему, а не рассказывать тут сказки про людей в серверных.
> Линукс дыряв by design иначе бы не появлялись все эти SE-Linux (который
> большинство сразу вырубает), hardened версии и прочее. Торвальдс никогда не ставилКак ярый пользователь Hardened Gentoo, подтверждаю. :)
> безопасность во главу угла, его всегда устраивал уровень качества и безопасности
> линукса, поэтому аппелировать вы можете только к вашему кормчему, а не
> рассказывать тут сказки про людей в серверных.Всё так.
> nuclightПрежде чем публично бросать тень на Вадима, подумайте о том, что неадекватность Вашего персонального восприятия может выйти ему боком. А "открывать глаза" такому зоркому джо -- это, наверное, был тяжкий труд с учётом того, что я-то как раз пишу под своим именем и не скрываюсь.
> не юли, честно признай это дырень в линуксе, да в том самом линуксе
Это дырень в драйвере, который входит в комплект исходников ядра Linux и который может быть автоматически загружен, если был установлен на системе (плюс ещё ряд условий, часть которых можно подразумевать как обычно актуальные). У меня на серверах с 2.6.18/32 модуля snd_usb_caiaq.ko не наблюдается. Вы-то способны признать, что ляпнули от балды?
> Ато
Всё, по-русски писать не умеете -- следовательно, безграмотный; значит, и специалист бестолковый; отсюда нерелевантный спам в комментариях (да ещё и нецензурный); и что теперь -- расстреливать?
Там дырку заткнут, Вам пояснят про раздельное написание "а то" -- и жизнь продолжится, что характерно.
> получается если дырень в линуксе то значит нужно датацентр закрыть на замок,
> три слоя охраны и главное камер к каждому серваку натыкать. Как это у вас звучит?(задумавшись) Похоже, проблемы с пониманием того, что физическая безопасность -- один из главных пунктов оценки ДЦ, и того, что от ОС может зависеть разве что время на вскрытие при наличии физического доступа. Вы вообще в курсе, что такое датацентр?
> Линукс дыряв by design
Нет.
> иначе бы не появлялись все эти SE-Linux (который большинство сразу вырубает),
> hardened версии и прочее.Тоже нет. (вот только не рассказывайте, что ездите на работу на БТР, а там стоит отключенный от сети опёнок на альфе -- не-ве-рю)
> Торвальдс никогда не ставил безопасность во главу угла
Это да.
> поэтому аппелировать вы можете
Надеюсь, за прошедший месяц Вы всё-таки проспались.
> даа зачетная такая дырень,Сэр, поищите тут посты некоего paxuser, он доступно рассказывал у кого как с дырками. В частности он очень низкого мнения о freebsd, и на то у него были причины. А те у кого с секьюрити хорошо - почему-то малопригодны для практического использования.
> даа зачетная такая дырень,Ну, расскажите тогда в какой системе таких дыреней нет и быть не может. Ну, наверное в MINIX какомнить, да? Там нет usb - нет и дыр в нем. Вариант. Для тех кому usb не нужен. Ну так это... можно и из линуха модули юсб вынести и запретить загрузку модулей на ходу. Хаксор обломается ничуть не меньше:)
> слепить usb хреновину
Да, процесс слепки - очевиден чтописец. Надо всего-то спаять собственную девайсину, прошить в нее собственную фирмвару, спасибо если не скурив еще половину немеряного талмуда спеков юсб, и вот тогда... тогда вы сможете при физическом доступе заюзать дырку. Которую заткнули в феврале, да :). Есть такое подозрение что пока вы сподобитесь - приедет апдейт, и... :)
> и по пути к своей циске незаметно так воткнуть девайс в пару линупсовых
> сервачков самое оно.А есть уверенность что в остальных системах похожих ляпов нет? На самом деле проблема тут в том что современное железо - сложное. Вы вообще спеки USB видели? Это такой крутейший талмуд. Вы верите в возможность его реализации без багов? :)
> и что характерно User294 по обычаю в таких темах не отписывается,
Ну, отписался. А ты какую систему как образец секурности предлагаешь? OpenBSD? В которой нет поддержки уймы железа и с многопроцессорностью проблемы? Minix который вообще нифига не умеет? Или чего? Из реалистичных вариантов?
> павлинтус тихо молчит в тряпочку, а Мишу Шигорина ваще не видать. Где
> вы поборники БЫСТРОГО линукса? по?й на дыры, главное же быстро!Ну так дыры там запатчат быстрее чем вы успеете спаять и запрограмить железку для поимения, имхо. А потом как-бы уже и поздно :). Кстати, при физическом доступе к машине когда я могу кастомный девайс в юсб впихнуть - я могу и загрузиться с своей флехи, вероятно. После чего я получу полные права в совершенно любой системе :)
> А учитывая последние тенденции разработчегов скрывать причины патчей, скоро можно ожидать
> разоблачения великого мифа линуксов как безопасных систем.Ну тут некий товарисч paxuser или как там его правильно помнится крепко наподдал и FreeBSD в этом плане. А остальные как-то и не развиваются почти. Не, можно юзать minix какойнить. Если он конечно у вас вообще загрузиться сможет на реальном железе, а не где-то у академиков в виртуалочке. А юсб девайсы... нет фичи - нет проблем? Ну с таким подходом и линуховое ядро - типа секурно: выносите все лишние подсистемы, запрещаете загрузку модулей. Враг не пройдет :).
> Ну, расскажите тогда в какой системе таких дыреней нет и быть не
> может. Ну, наверное в MINIX какомнить, да? Там нет usb -
> нет и дыр в нем. Вариант. Для тех кому usb не
> нужен. Ну так это... можно и из линуха модули юсб вынести
> и запретить загрузку модулей на ходу. Хаксор обломается ничуть не меньше:)Слишком много если.
> Да, процесс слепки - очевиден чтописец. Надо всего-то спаять собственную девайсину, прошить
> в нее собственную фирмвару, спасибо если не скурив еще половину немеряного
> талмуда спеков юсб, и вот тогда... тогда вы сможете при физическом
> доступе заюзать дырку. Которую заткнули в феврале, да :). Есть такое
> подозрение что пока вы сподобитесь - приедет апдейт, и... :)все сказанное выше отменяет дырень? И таки да, ковырял я юсб девайсины и дрова под них писал, ничего там страшного нет, если есть платка на атмеге, то вообще все собирается за пару часов. у нас 4-х моторный квадролёт пацаны из китайского танка за выходные собрали, со всеми сборками ядер, прошивками.. ничо там сложного с usb нету.
> А есть уверенность что в остальных системах похожих ляпов нет? На самом
> деле проблема тут в том что современное железо - сложное. Вы
> вообще спеки USB видели? Это такой крутейший талмуд. Вы верите в
> возможность его реализации без багов? :)в OpenBSD ляпов секурного плана горааааздо меньше, что-то я не припоминаю, чтоб еженедельно проблемы безопасности находили в опёнке.
> Ну, отписался. А ты какую систему как образец секурности предлагаешь? OpenBSD? В
> которой нет поддержки уймы железа и с многопроцессорностью проблемы? Minix который
> вообще нифига не умеет? Или чего? Из реалистичных вариантов?ну та поддержка которая есть в openbsd меня устраивает, железо работает, рэйды поддерживаются, извините юсб-саундкарты я в сервера не втыкаю, ибо на хэ не надо. Да и вообще я не уверен что ты смог бы поставить и настроить опёнка, на одном из этапов наверняка бы сломался, оплевался и поставил гламурный линукс
> Ну так дыры там запатчат быстрее чем вы успеете спаять и запрограмить
> железку для поимения, имхо. А потом как-бы уже и поздно :).
> Кстати, при физическом доступе к машине когда я могу кастомный девайс
> в юсб впихнуть - я могу и загрузиться с своей флехи,
> вероятно. После чего я получу полные права в совершенно любой системе
> :)перезагрузка сервера сразу вызовет тревогу в нормальном датацентре, мониторинг сейчас даже самые ленивые луноходы ставят. Ну и кстате на пошифрованных разделах перезагрузка с usb не особо поможет. Да таковых мало, но если брать mission critical типа банков, то там во первых стоят hp-ux по 64 камня, а во вторых ты его и перегрузить не сможешь, ибо даже не знаешь как :)
> Ну тут некий товарисч paxuser или как там его правильно помнится крепко
> наподдал и FreeBSD в этом плане. А остальные как-то и неля-ля не надо, всегда когда приезжает апдейт все чотко написано вплоть до diff, кто-то чота там рассказывал... мне про линукс тоже всякую муйню рассказывают, это же не отменяет свою голову на плечах.
> развиваются почти. Не, можно юзать minix какойнить. Если он конечно у
> вас вообще загрузиться сможет на реальном железе, а не где-то у
> академиков в виртуалочке. А юсб девайсы... нет фичи - нет проблем?
> Ну с таким подходом и линуховое ядро - типа секурно: выносите
> все лишние подсистемы, запрещаете загрузку модулей. Враг не пройдет :).У FreeBSD как и у OpenBSD проблемы с драйверами это протухшая новость 2003 года. Еще раз, на тачке с которой я пишу стоит FreeBSD, все железо работает. 2х интерфейсные интеловые igb, видяха от nvidia, звучки аж две набортная, и кривотивная, всякие проводочки аля usb -> serial, всякие usb -> ethrnet погремушки, wi-fi пашет опятьже... все пашет из коробки, без траха с ядрами. Так что опять мимо... А вот линуксовое ядро в том то и дело "типа секурно". Все делают вид что линукс не пробиваем, но сравнивают почему-то всегда с вендой, да на уровне венды действитльно там сказка, хотябы вирусов нет, но сравнивая с OpenBSD, это просто слёзы..
> в OpenBSD ляпов секурного плана горааааздо меньше, что-то я не припоминаю, чтоб
> еженедельно проблемы безопасности находили в опёнке.User-friendly
Secure
FunctionalPick any two...
> Слишком много если.Ну, количество "если" потребное для успешного взлома линуха через этот баг не мешает некоторым троллить как я смотрю. А тут вдруг вас "если" засмущали. Странно :)
> все сказанное выше отменяет дырень?
Нет, не отменяет. Но ее реальная серьезность - почти на уровне плинтуса. Ну сломает пара десятков гиков свой локалхост. И? А товарисчи типа HBGarry - это наполеоны современные, судя по сочетанию почти нереальных задумок и планов с громкими эпикфейлами, когда "спецы по безопасности" сами сообщают пароль от ссш и открывают фаервол совершенно посторонним анонимусам :).Чисто технически им было бы сложно реализовать даже 1/3 от того что они там задумали, а уж с помощью анонимусов они могут вообще сушить весла, т.к. наполеоновские планы были спалены и видимо успешно провалятся :)
> И таки да, ковырял я юсб девайсины и дрова под них писал, ничего там страшного
> нет, если есть платка на атмеге, то вообще все собирается за пару часов.Не, ну понятно что было бы желание да скиллы... только пару часов мне кажется излишне оптимистчным вариантом, в любом случае это далеко не стандартная флеха которую пошел да купил, да и врядли дыра долго протянет, особенно после такого пиара :).
> у нас 4-х моторный квадролёт пацаны из китайского танка за выходные собрали,
Сурово, а логику стабилизации по акселерометрам, управление моторами и прочая - сами писали, или просто готовое влили? А то за выходные самим такую логику наваять - больно круто как-то. А влить готовое ума особо не требует. Да и квадролет - забавная конструкция. Как раз тем что никаких особых требований не выдвигает ни к чему. Конструкция механически довольно проста, и в общем то не капризна, а весь гемор по стабилизации аппарата и управлению - вынесен на набортный софт ну и его юзверя :).
> со всеми сборками ядер, прошивками.. ничо там сложного с usb нету.А они что, на основе линуха его делали? Или что за ядра они там собирали? oO
> в OpenBSD ляпов секурного плана горааааздо меньше,
Ну так и используется она гораздо меньше и может гораздо меньше. А если бы ее юзали как линух - наверное и баги бы находили в приличном количестве. Хотя и в меньшем количестве наверное, т.к. ряд софта у них достаточно минималистичен, что явно на пользу отсутствию багов в нем (например openntpd явно меньше по размеру чем ISCшный, у кого меньше багов - несложно догадаться, да).
> что-то я не припоминаю, чтоб еженедельно проблемы безопасности находили в опёнке.
Ага, зато я припоминаю что там плохо с многопроцессорностью и вообще развитием в последнее время. Понятное дело что укрепленный бункер на глубине несколько сотен метров - защищает даже от ядерного взрыва или падения метеорита, только постоянно в нем отсиживаться - на любителя.
>> вообще нифига не умеет? Или чего? Из реалистичных вариантов?
> ну та поддержка которая есть в openbsd меня устраивает, железо работает, рэйды
> поддерживаются,Угу, только насколько я помню, там многие подсистемы не ахтецки работают на многопроцессорном железе. Это когда многоядерные процы пхают чуть ли не в телефоны, не говоря уж о серверах.
> извините юсб-саундкарты я в сервера не втыкаю, ибо на хэ не надо.
В моем понимании - если уж волнует секурити, то позапрещать лишние модули/протоколы/юзать минимум программ и прочая - is a must :). Юсб вообще слишком дофига всего может, поэтому по хорошему в биосе порубать нафиг и пароль на вход в биос воткнуть, если не планируется юзать юсб-девайсы. Правда эта гребаная проприетара - достаточно халтурна и пароль на биос обычно весьма халтурненько сделан и легко сбрасывается. Ну в общем если хаксор может до вашего сервака физически дорваться - ничего хорошего ожидать не приходится особо.
> Да и вообще я не уверен что ты смог бы поставить и настроить опёнка,
> на одном из этапов наверняка бы сломался, оплевался и поставил гламурный линуксУ меня нет самоцели погеморроиться по максимуму чтобы доказать кому-то что-то. У меня есть некие задачи/хотелки, я хочу с ними разобраться, логично что я хочу достичь целей с минимальными затратами усилий (геморрой как самоцель - странный goal). "Гламурный" линукс неплохо с этим справляется. А понтоваться операционкой - одна из наиболее глупых затей которые я видел. Остается только вопрос: а нахрена мне порция геморроя на ровном месте? Например, если защищаться от сетевых атак - есть ли у вас уверенность что виртуалка с минимальной системой-пингвином в ней, с минимумом модулей и софта - более дырява? А от физического доступа защищаться... эээ от кувалдометра у недруга так просто не защитишься. А у банкоматов, автоматов оплаты и прочих бронированных систем, где от физического доступа более-менее защищаются я что-то не видел доступных всем юсб-разъемов, для начала. Ну и как их ломать через юсб? Также я плохо представляю себе вирус, который потребует от юзера не просто флеху, а спецдевайс, что зарубает идею самоходности такого ПО :). В итоге думается десяток гиков сломает локалхост :). А диверсант в датацентре или около компа - всяко свое поимеет, так или иначе. Читайте вон у дихалта как он специально подготовленной мышкой файлы с станка упер, дело было под виндой, но там в принципе прокатила бы и любая иная ос способная работать с флешками :)
>> Кстати, при физическом доступе к машине когда я могу кастомный девайс
>> в юсб впихнуть - я могу и загрузиться с своей флехи,
>> вероятно. После чего я получу полные права в совершенно любой системе :)
> перезагрузка сервера сразу вызовет тревогу в нормальном датацентре, мониторинг сейчас
> даже самые ленивые луноходы ставят.Ленивые все-таки не ставят :). Хотя действо безусловно более заметное, да :).Но даунтаймы или проблемы роутинга так или иначе иногда случаются у всех. Если на каждый глюк маршрутов продолжающийся 10 минут извергать кирпичи и звонить в датацентр - вы очень скоро поседеете и захотите на пенсию...
> Ну и кстате на пошифрованных разделах перезагрузка с usb не особо поможет.
> Да таковых мало, но если брать mission critical типа банков,Если брать например типичный банкомат - я что-то не вижу там юсб разъема вообще, для начала. Он, наверное, где-то есть, но думается мне что для доступа к нему надо совершать какие-то очень подозрительные действия и довольно долго, полисмены воспримут эти попытки крайне отрицательно :). А если банк позволяет гулять в своих процессинговых центрах кому попало с флешками или там как еще - блин, ну и кто им доктор?
> то там во первых стоят hp-ux по 64 камня, а во вторых ты его и перегрузить не
> сможешь, ибо даже не знаешь как :)Для начала, я сильно удивлюсь если смогу невозбранно разгуливать там с флехой и имея подозрительные намерения :). Такой банк просто напрашивается чтобы его расхакали нафиг :)
>> наподдал и FreeBSD в этом плане. А остальные как-то и не
> ля-ля не надо, всегда когда приезжает апдейт все чотко написано вплоть до diff,Да при чем тут диффы? В случае git у меня просто "по дефолту" вся истоирия коммитов есть, елки. А paxuser про другое совсем. Профайл оного: http://www.opennet.me/~paxuser а некоторые моменты относительно его точек зрения можно найти например примерно тут: http://www.opennet.me/openforum/vsluhforumID3/71986.html?n=p...
И у него есть крупный плюс: он явно интересуется предметом и может внятно аргументировать свою точку зрения. Фрибсд он раздал по самые небалуйся, при том достаточно убедительно и я не видел чтобы бсдуны умудрились внятно ему что-то возразить на его аргументацию. Он кстати и ряду линухов раздал вполне себе чувствительно, и не то чтобы без причин :). И да, если долбит паранойя - любимый этим товарисчем PaX выглядит довольно интересно :)
> кто-то чота там рассказывал... мне про линукс тоже всякую муйню
> рассказывают, это же не отменяет свою голову на плечах.А упомянутый товарисч явно обладает своей головой на плечах и интересуется секурити.
>> Ну с таким подходом и линуховое ядро - типа секурно: выносите
>> все лишние подсистемы, запрещаете загрузку модулей. Враг не пройдет :).
> У FreeBSD как и у OpenBSD проблемы с драйверами это протухшая новость 2003 года.Угу, конечно, особенно заметно на ноутбуках например :). На эмбеддовке они вообще почти не представлены. И даже юсб-звуковуха имеет право на жизнь. Не на сервере так в составе сетевого медиа-центра, мля.
> Еще раз, на тачке с которой я пишу стоит FreeBSD, все железо работает.
> 2х интерфейсные интеловые igb, видяха от nvidia,Ага. Запустите эту вашу фрю на новомодной тегре от нвидия. А что, видеокарта там от нвидии, а то что она на 1 чипе с армовским ядром - ну да. И что? А чем арм хуже остальных как проц? Команды выполняет, даже довольно резво для своего мизерного потребления - камень на гигагерц с гаком, работающий не то что без кулера а даже без радиатора толком - это нехило, а? :)
> звучки аж две набортная, и кривотивная,
У меня аж три :) еще и видеокарта с HDMI оказывается котируется как звуоковуха. Сижу я и думаю: вот нахрена б мне 3 звуковухи, а? :))
> всякие проводочки аля usb -> serial,
У меня наверняка найдется парочка подленьких экземпляров :)).И кстати как там libusb у вас поживает? А то там до сих пор написано что бета-версия, некоторые вызовы не реализованы, бла-бла. Зато под расово верной лицензией. Бздуны такие бздуны :)
> всякие usb -> ethrnet погремушки, wi-fi пашет опятьже... все пашет из коробки,
Даже .n вайфай? И на каких чипаках? Атерос? Броадком? Ралинк? Интель? Кого я еще забыл? :)
> без траха с ядрами. Так что опять мимо... А вот линуксовое ядро в том то
> и дело "типа секурно". Все делают вид что линукс не пробиваем,
> но сравнивают почему-то всегда с вендой,Специально для таких как вы paxuser неслабо прошелся по разным ядрам, вариантам укрепления оных и прочая. Почитайте, весьма познавательно :)
> но сравнивая с OpenBSD, это просто слёзы..
Ага, с опенбсд слезы будут по другому поводу, когда не заработает любимая железка, нет нормальной современной файловой системы, паршиво поддерживается многопроцессорное железо, etc. И если фря еще более-менее активировалась и взамен там баги гребут лопатой ("не ошибается тот кто ничего не делает") то опенок... ну в общем он весьма на любителя с такими темпами развития. Следующим шагом после установки опенка должен быть переезд в укрепленный подземный бункер. На всякий случай. А то что неудобно и ограничений много - ну извините, юзерам оного к геморрою все-равно не привыкать :)
спасибо юзер, день сегодня и так офигенный, солнышнко и все такое, и ты в очередной раз поднял настроение. :)) Респект и уважуха за своебразное чувство юмора. :)) Ссылки на пакса, почитаю как будет в следующий раз оказия с некоторым количеством свободного времени, чет как то не замечал его раньше.
Ну и вобщем фигли спорить, все равно каждый останется на своём мнении, да вертолет собрали на линуксе, я им с бутстрапом децл помог, есть опыт в ковырянии всякого разного типа шыта типа wl500g, перепиливал ихние прошивки, и таки да в то время сидел на бубунте, плевался но сидел, ибо также не ищу геморой на свою %опу, теперь работа преимущественно с фрёй, потому сижу на фре, но сервера мантейню и фрёвые и рхеловые и федоровые и форточные, со всех бабло капает, что характерно практически одинаково :) есть маза пересеть на соляру, должен подвалить новый проект..ЗЫ: не напрягайся :) писать уже нету больше сил, завтра ж на работу (с)
почитал я пакса твоего, на мое имхо просто больной причем на всю голову, либо работает в какойто сильно противозаконной сфере, мож 7й отдел реально за ним охотится и он очкуэ, что его поимеют через HeloWorld?Как извесно техники аля dep и aslr далеко не гарантия от взлома, усложняет да, но обходятся таки. Да и вообще если уж рассказывать правду, то рассказывать надо всю, а не выборочно. http://www.slideshare.net/sciosecurity/linux-kernel-exploita.... График особо показателен, и нае%%алово от торвальства 6 лет назад что типа вот теперь то linux officially bug free. Ога, буг фри, два раза. А так получается опять у Тео Nih синдром, у FreeBSD core team вообще руки не из того места, и только один Фюрер ибн Торльвадс весь в белом. Да и вообще если такие умные чо ж строем то не ходите? Где ваше супермега ядро на ерланге? или на эрланг можно только подр..W^X то есть слюни пускать?..
Количество дыр в линуксе измеряется сотнями, в то время как количество дыр в FreeBSD измеряется в лучшем случае десяками. Говорить о том что гипотетически яро FreeBSD более уязвимо чем Linux при всем том количестве обнаруживаемых дыр может только paxuser -> больной на всю голову. Походу без hardened ядра действительно некузяво.
С другой стороны все в этом мире относительно, я знаю два хоста на венде 2008 торчащие в инет без антивируса, сайты на iis крутятся, больше двух лет полёт нормальный. Знаю линукс торчащий в инет - LAMP обычный на бубунто-сервере только без фаера. И тоже пашет без взломов. Про остальные даже не говорю. И что? А ничего, если комп нафиг никому не нужнен, то даже винда может стоять 2 года и работать, линукс может торчать в инет без фаера, также нафиг никому не нужный. А вот если у тебя нехитрый "набор кардера" или "хитрый план терориста" тогда да, тебе есть чего опасаться даже с отключенным от инета компом, и hardened ядро со строительной пеной в jопе становитя очень быстро vulnerable. По мне так лучше спокойно ночью спать, чем в ужасе просыпаться от очередной zero-day уязвимости. Как-то так.
> почитал я пакса твоего, на мое имхо просто больной причем на всюА я здесь и всё вижу. ;)
> один Фюрер ибн Торльвадс весь в белом. Да и вообще если
По диагонали вы меня почитали-то, любезный.
>> почитал я пакса твоего, на мое имхо просто больной причем на всю
> По диагонали вы меня почитали-то, любезный.Я тоже тебя почитал. Ты больной на голову параноик. Лучше иди читай Криса Касперски в "Системном администраторе", он правильную мысль проводит: неуязвимых систем не бывает, и даже процессоры не защищены от ошибок выполнения.
> Я тоже тебя почитал. Ты больной на голову параноик. Лучше иди читайИ тоже по диагонали, с тем же результатом.
> Криса Касперски в "Системном администраторе", он правильную мысль проводит: неуязвимых
> систем не бывает, и даже процессоры не защищены от ошибок выполнения.Касперски не эксперт, мысль эта не его, и я её разделяю.
> Как извесно техники аля dep и aslr далеко не гарантия от взлома,
> усложняет да, но обходятся таки. Да и вообще если уж рассказывать
> правду, то рассказывать надо всю, а не выборочно. http://www.slideshare.net/sciosecurity/linux-kernel-exploita....Бтв, что-то я в вашем надрывном потоке сознания не досчитался некоторой доли этой "всей правды". Ну я процитирую, да.
> • Administrators
>
> – Distros are conservative, poke them!
> – Lots of hardening you can do on your own
> – grsecurity / PaX / KERNHEAP patchsets [26,14]
> – Most importantly, support/sponsor these guys for
> their hard workТут афтар просто вас не спросил про безопасность FreeBSD, "количество дыр" и паранойю.
> • Message is not: “Don't use Linux, it's insecure, lolz!”
Message is: “Don't use Linux, it's insecure, lolz, use FreeBSD!” Очевидно же. ;)
> • Security is not measured in absolutes
> – Risk management → uncertainty managementТакой х%нёй страдают только больные на голову параноики.
> Or, more concisely:
> “Now you know, and knowing is half the battle!” -- GI JOEФигню сказал, очевидно же.
> График особо показателен, и нае%%алово от торвальства 6 лет назад что
Да график вообще самый главный в презентации, чо уж там. :)
> лучше спокойно ночью спать, чем в ужасе просыпаться от очередной zero-day
> уязвимости. Как-то так.Меньше знаешь - лучше спишь, ога.
> Бтв, что-то я в вашем надрывном потоке сознания не досчитался некоторой доли
> этой "всей правды". Ну я процитирую, да.Ну и какой главный вывод? В том что фря сосёт, а линукс рулит?
>> • Administrators
>>
>> – Distros are conservative, poke them!
>> – Lots of hardening you can do on your own
>> – grsecurity / PaX / KERNHEAP patchsets [26,14]
>> – Most importantly, support/sponsor these guys for
>> their hard work
> Тут афтар просто вас не спросил про безопасность FreeBSD, "количество дыр" и
> паранойю.Таки да, в FreeBSD тоже есть дыры, но я утрверждал лиш то что их количество по сравнению с линуксом гораздо меньше. Еще раз _количество найденых дыр_, давайте уже признаем это. _Простую_ логику здесь видите? Нет?
Ок, вывод - патчить фрю мне приходится гораздо реже, в security@ _сразу_ приезжает описание с дырой, и что надо сделать. И еще момент в линуксах вам говорят тут вот у нас новое ядро вышло, срочно обновитесь, без раскрытия причин.
>> • Message is not: “Don't use Linux, it's insecure, lolz!”
> Message is: “Don't use Linux, it's insecure, lolz, use FreeBSD!” Очевидно же.
> ;)Очевидно другое - линукс дыряв как минимум не меньше чем FreeBSD и утверждать то что линукс типа православен и тамошний Фюрер, конечно Фюрер, но белый и пушистый да.
>> • Security is not measured in absolutes
>> – Risk management → uncertainty management
> Такой х%нёй страдают только больные на голову параноики.Ога... фигле..
>> Or, more concisely:
>> “Now you know, and knowing is half the battle!” -- GI JOE
> Фигню сказал, очевидно же.Да вообще вся презентация фигня полная, чего уж там.
>> График особо показателен, и нае%%алово от торвальства 6 лет назад что
> Да график вообще самый главный в презентации, чо уж там. :)Ну а по сути то что? Выводы хоть какие-то есть? Или...
>> лучше спокойно ночью спать, чем в ужасе просыпаться от очередной zero-day
>> уязвимости. Как-то так.
> Меньше знаешь - лучше спишь, ога.1. Мои системы достаточно защищены, защита применяется как пассивная так и активная, там где это надо, в локальном DC в комплексе используются технологии от Cisco, OpenBSD, FreeBSD и частично как это не увидительно - линукс, использую тот же CentOS.
2. Количество security officer там где это надо больше одного, ибо один даже больной на всю голову линуксоид с перехарденед ядром так или иначе человек.
3. Бизнес абсолютно чист и легален, бухгалтерия, используемый софт всё честно купленное и белое.Ну и последнее дома вот именно с той машины с которой я пишу, у меня FreeBSD да, очевидно IP адрес вы уже знаете, сплойт у вас тоже есть, ломайте, я жду.
> Ну и какой главный вывод? В том что фря сосёт, а линукс
> рулит?Да, такой главный вывод. Написано же прямым текстом: фря сосёт. Вот тут:
>>> – Lots of hardening you can do on your own
>>> – grsecurity / PaX / KERNHEAP patchsets [26,14]
> Таки да, в FreeBSD тоже есть дыры, но я утрверждал лиш то
> что их количество по сравнению с линуксом гораздо меньше. Еще раз
> _количество найденых дыр_, давайте уже признаем это. _Простую_ логику здесь видите?
> Нет?Афтар перечислил patchsets, с которыми значительно возрастает сложность эксплуатации любой из этих "найденных дыр", либо все последствия сводится к DoS в худшем случае. А во FreeBSD из всех средств защиты ядра - недавно добавленный запрет на маппинги по нулевому адресу. Поэтому к DoS там сводятся только обращения по нулевому указателю. Эксплуатации остальных классов уязвимостей ничто не мешает. И это при том, что юзерленд практически не защищён.
> Ок, вывод - патчить фрю мне приходится гораздо реже, в security@ _сразу_
> приезжает описание с дырой, и что надо сделать. И еще моментЭто хорошо. Только вы не понимаете, что ваши патчи защищают от взлома через публично известные дырки, реактивно. А те patchsets - от целых классов, проактивно.
> в линуксах вам говорят тут вот у нас новое ядро вышло,
> срочно обновитесь, без раскрытия причин.Я уже высказывал своё недовольство по этому поводу. Уже писал, что из-за Торвальдса в линуксе бардак с безопасностью. И что код во FreeBSD более качественный и стабильный. А вы продолжайте читать по диагонали.
> Очевидно другое - линукс дыряв как минимум не меньше чем FreeBSD и
Очевидно, действительно, другое.
> утверждать то что линукс типа православен и тамошний Фюрер, конечно Фюрер,
> но белый и пушистый да.На самом деле седой и волосатый. Хотя если по диагонали посмотреть...
> Ну а по сути то что? Выводы хоть какие-то есть? Или...
Есть. Вы просто не умеете их внимательно читать.
> 1. Мои системы достаточно защищены, защита применяется как пассивная так и активная,
> там где это надо, в локальном DC в комплексе используются технологии
> от Cisco, OpenBSD, FreeBSD и частично как это не увидительно -
> линукс, использую тот же CentOS.
> 2. Количество security officer там где это надо больше одного, ибо одинВы что-то конкретное рассказать можете, пример какой-нибудь, технологии, методы? Чем офицеры заняты?
> Ну и последнее дома вот именно с той машины с которой я
> пишу, у меня FreeBSD да, очевидно IP адрес вы уже знаете,
> сплойт у вас тоже есть, ломайте, я жду.Судя по тону и весу аргументации, я с этим завязал ещё до того, как вы в 5-ый класс пошли.
> Да, такой главный вывод. Написано же прямым текстом: фря сосёт. Вот тут:
>>>> – Lots of hardening you can do on your own
>>>> – grsecurity / PaX / KERNHEAP patchsets [26,14]Я уже читал что MAC вы считаете лишь помощником руткитерам, а подсистему Audit вообще лишенной смысла. Ваше право, считайте. Я же считаю что в Линуксах просто необходимы вышеприведенные техники защиты. В первую очередь потому, что проще оказалось изобрести имено эти системы нежели в общем следить за качеством кода. Эдакий выстрел из пушки по воробьям. С другой стороны я так понимаю вы готовы поставить на то, что с исользованием данных техник ваш линукс перестал быть уязвимым априори? grsecurity / PaX / KERNHEAP patchsets все это bug free?
> Афтар перечислил patchsets, с которыми значительно возрастает сложность эксплуатации
> любой из этих "найденных дыр", либо все последствия сводится к DoS
> в худшем случае. А во FreeBSD из всех средств защиты ядра
> - недавно добавленный запрет на маппинги по нулевому адресу. Поэтому к
> DoS там сводятся только обращения по нулевому указателю. Эксплуатации остальных классов
> уязвимостей ничто не мешает. И это при том, что юзерленд практически
> не защищён.Патчесеты стоит заметить не в mainline. Во FreBSD есть поддержка DEP, MAC, AUDIT, есть _securelevel >=2 в конце концов, и в целом более качественный код. Заметь у меня нет задачи заставить вас использовать FreeBSD, Боже упаси. Мне вообще до лампочки что у вас используется. Мое мнение такое фря развивается на жалкие 300 тысяч в год, при этом уровень безопасности системы достаточно высок, количество vulns относительно небольшое. Наличие MAC и AUDIT позволяют поднять уровень безопасности.
>> Ок, вывод - патчить фрю мне приходится гораздо реже, в security@ _сразу_
>> приезжает описание с дырой, и что надо сделать. И еще момент
> Это хорошо. Только вы не понимаете, что ваши патчи защищают от взлома
> через публично известные дырки, реактивно. А те patchsets - от целых
> классов, проактивно.Соглашусь, но и эти патчсеты можно обойти. Да со всеми фишками аля PaX, grsec., patchsets, линукс безусловно надежнее. Но не кажется ли вам что нужно лечить болезнь, а не ее симптомы. Учитывая что в линукс вкладываются чуть ли не миллиарды денег, Торвальдс отрицает наличие проблемы с безопасностью как таковой.
> Я уже высказывал своё недовольство по этому поводу. Уже писал, что из-за
> Торвальдса в линуксе бардак с безопасностью. И что код во FreeBSD
> более качественный и стабильный. А вы продолжайте читать по диагонали.Да читал я все, однако заметил огромную предвзятость, поэтому и ответил в том же ключе.
>> утверждать то что линукс типа православен и тамошний Фюрер, конечно Фюрер,
>> но белый и пушистый да.
> На самом деле седой и волосатый. Хотя если по диагонали посмотреть...Слова Фюрера о том что его полностью устраивает текущее качество кода и полное отрицание проблем с безопасностью наводит знаете на мысли. Если человек _верит_ в то, что плод его творчества не требует работы над качеством и безопасностью при этом продолжает обрабатывать патчи на скорости граничащей со здравым смыслом, у меня это как минимум вызовет вопросы. Безопасным такой подход назвать никак нельзя.
>> Ну а по сути то что? Выводы хоть какие-то есть? Или...
> Есть. Вы просто не умеете их внимательно читать.Да уже просто стебусь на самом деле.
>> 1. Мои системы достаточно защищены, защита применяется как пассивная так и активная,
>> там где это надо, в локальном DC в комплексе используются технологии
>> от Cisco, OpenBSD, FreeBSD и частично как это не увидительно -
>> линукс, использую тот же CentOS.
>> 2. Количество security officer там где это надо больше одного, ибо один
> Вы что-то конкретное рассказать можете, пример какой-нибудь, технологии, методы? Чем офицеры
> заняты?Да вобщем-то ничего особенного, утомительно все перечислять. Эти люди _верят_ в то, что основная угроза безопасности исходит не снаружи, а изнутри сети. В паблике крутится 3 сайта, все три сайта, вместе с движком изначально были переданы на аудит безопасности сторонней конторе, контора подтвердила высокий статус безопасности. Sec. officers занимаются в частности тем, что обрабатывают все нештатные попытки эскалации привилегий. Просматривают все файлы которые юзера копируют на флешки или с нее. Делать это можно только на _одной_ выделенной машине. Включение инета юзеру автоматически отключает его от локалки, и включает полный мониторинг всех его действий, видео и скрипты хранятся потом отдельно, сам инет выдается только по распоряжению руководства и через пачку фильтров. Про активный мониторинг траффика, Cisco IDS/IPS, договора с апстримами о предотвращении DOS атак я уже и не говорю. Вобщем все это на них включая логи, СКУД, видеокамеры, три кольца охраны, кучу формализаций и регламетов которые они выдают на гора и тд. Основная идея комплексная безопасность, начиная от аккуратного выбора софта, заканчивая человеческим фактором. Да даже собеседования при приеме на работу у нас проводит бывший офицер ГБ, суровый дядька, тоже входит в security department.
> Судя по тону и весу аргументации, я с этим завязал ещё до
> того, как вы в 5-ый класс пошли.Ну если для вас Тео неуч, Крис Касперски лох, то моя критика это уровень 5го класса, не больше. Не знаю как ваш, а мой пятый класс был в далёком совке, во времена ЕС ЭВМ и трамвая по 3 копейки.
Дальнейшую дисскуссию считаю лишенной смысла, ибо мне вам что-то доказывать абсолютно не впёрлось. Если вы всетаки напишите POSIX совместимое чудо-ядро на эрланге я пожалуй первым это попробую, удручает только то что небезопасный Си использовали при написании безопасного эрланга. Тоже как-то не стыкуется с вашей же теорией тотальной безопасности.
> Я уже читал что MAC вы считаете лишь помощником руткитерам, а подсистему"Лишь" - вы от себя добавили. Пока ядро не защищено, с моей точки зрения польза от MAC не оправдывает риски в сколько-нибудь серьёзных случаях.
> Audit вообще лишенной смысла. Ваше право, считайте. Я же считаю что
Вы доводите моё мнение до абсурда.
> в Линуксах просто необходимы вышеприведенные техники защиты. В первую очередь потому,
Они нужны везде, где нужна защита. Когда оценочная стоимость охраняемых данных на чёрном рынке превышает $100k, например.
> что проще оказалось изобрести имено эти системы нежели в общем следить
> за качеством кода. Эдакий выстрел из пушки по воробьям. С другойОдной заботой о качестве кода больших монолитных ядер существенных результатов не достигнуть. Тут нужен многоуровневый подход, сторонником которого вы якобы являетесь. Избирательно.
> стороны я так понимаю вы готовы поставить на то, что с
Нет, не понимаете и не хотите понять.
> исользованием данных техник ваш линукс перестал быть уязвимым априори? grsecurity /
> PaX / KERNHEAP patchsets все это bug free?Вы не вдумываетесь даже в смысл моих ответов прямым текстом вам лично. Мните себя реалистом? Не льстите себе. Ваши реплики - это срез чёрно-белых взглядов максималиста, который не оставляет окружающим права на относительные суждения.
> Патчесеты стоит заметить не в mainline.
Заметить действительно стоит. Плохо, что не в mainline.
> Во FreBSD есть поддержка DEP, MAC,
"Поддержка DEP" там есть в вырожденном виде только на куче в юзерспейсе. Считайте, что нет. Особенно в свете jemalloc, двинутого сугубо и весьма на производительности.
> AUDIT, есть _securelevel >=2 в конце концов, и в целом более
Вы главное из виду упускаете: ни один из этих механизмов ядро от скомпрометированных пользовательских процессов не защитит. Впрочем, я всё это уже разжёвывал и повторять не собираюсь.
> качественный код. Заметь у меня нет задачи заставить вас использовать FreeBSD,
У меня сложилось впечатление, что ваша задача - зашориться от критики и оправдать любимую ОС правдами и неправдами, в том числе перевирая в вырывая мои слова из контекста.
> Боже упаси. Мне вообще до лампочки что у вас используется. Мое
Вы говорите так, будто эти слова для меня должны стать откровением.
> мнение такое фря развивается на жалкие 300 тысяч в год, при
> этом уровень безопасности системы достаточно высокУровень безопасности может быть "достаточно" высок лишь в конкретных случаях.
> количество vulns относительно небольшое.
Вы понимаете, что вы ничего не знаете о количестве, серьёзности и сложности поиска НЕ найденных уязвимостей? Вопрос риторический.
> Наличие MAC и AUDIT позволяют поднять уровень безопасности.
Они не предназначены для защиты ядра.
> Соглашусь, но и эти патчсеты можно обойти. Да со всеми фишками аля
Можно. Но стоимость обхода во многих случаях превысит прибыль от взлома системы. Что для вас значит "можно обойти"?
> PaX, grsec., patchsets, линукс безусловно надежнее. Но не кажется ли вам
> что нужно лечить болезнь, а не ее симптомы. Учитывая что вБолезнь - это язык. Да, мне кажется, что её нужно лечить, но не так это просто и быстро. Упомянутые патчсеты позволяют снизить наносимый вред. А вот реактивные патчи на уязвимости - действительно, лечение симптомов в чистом виде.
> линукс вкладываются чуть ли не миллиарды денег, Торвальдс отрицает наличие проблемы
> с безопасностью как таковой.Как таковой - не отрицает. Не доводите до абсурда. Впрочем, Торвальдс в этом и сам преуспел.
> Да читал я все, однако заметил огромную предвзятость, поэтому и ответил в
> том же ключе.Предвзятость? Загляните в словарь. Моё мнение о FreeBSD основано на фактах. В том же ключе? Вы снова себе льстите.
> Слова Фюрера о том что его полностью устраивает текущее качество кода и
> полное отрицание проблем с безопасностью наводит знаете на мысли. Если человекКачество кода его не устраивает, проблемы с безопасностью он полностью не отрицает. Это очередное доведение до абсурда с вашей стороны.
> _верит_ в то, что плод его творчества не требует работы над
Давно уже не верит, если вообще верил когда-либо.
> качеством и безопасностью при этом продолжает обрабатывать патчи на скорости граничащей
> со здравым смыслом, у меня это как минимум вызовет вопросы. Безопасным
> такой подход назвать никак нельзя.Безопасным нельзя назвать даже реальный подход Торвальдса, не говоря уж о ваших фантазиях.
> Да вобщем-то ничего особенного, утомительно все перечислять. Эти люди _верят_ в то,
[поскипано описание бюрократического аппарата]
> дядька, тоже входит в security department.Ясно, спасибо.
> Ну если для вас Тео неуч, Крис Касперски лох, то моя критика
Неуча-Тео и лоха-Касперски вы только что придумали.
> это уровень 5го класса, не больше. Не знаю как ваш, а
А вот вес и форма подачи ваших аргументов вполне реальны.
> мой пятый класс был в далёком совке, во времена ЕС ЭВМ
> и трамвая по 3 копейки.Ну так и соответствуйте. Или вам комфортнее иначе?
> Дальнейшую дисскуссию считаю лишенной смысла, ибо мне вам что-то доказывать абсолютно не
Вот и поглядим.
> впёрлось. Если вы всетаки напишите POSIX совместимое чудо-ядро на эрланге я
ОС на эрланге - очередной плод вашей бурной инфантильной фантазии, разыгравшейся на почве диагонального чтения.
> пожалуй первым это попробую, удручает только то что небезопасный Си использовали
> при написании безопасного эрланга. Тоже как-то не стыкуется с вашей же
> теорией тотальной безопасности.Уж с вашей теорией тотальной безопасности точно не стыкуется. А у меня всё складно да ладно.
$ find /lib/modules/`uname -r`/ -name snd-usb-caiaq.ko -o -name iowarrior.ko
$Ну вот опять надо чего-то доставлять, собирать и паять для того чтобы поломать этот ваш линукс... Всё как не у людей!
> $ find /lib/modules/`uname -r`/ -name snd-usb-caiaq.ko -o -name iowarrior.ko
> $Модули ищутся через modprobe -an, через find это как-то по-слакваревски,
а настоящий Гентушник мегагерц бережёт!!! :)# modprobe -an snd-usb-caiaq iowarrior
WARNING: Module snd_usb_caiaq not found.
WARNING: Module iowarrior not found.
> Модули ищутся через modprobe -an, через find это как-то по-слакваревски,
> а настоящий Гентушник мегагерц бережёт!!! :)Спасибо, схоронил в памяти.
> Этот Daniel Mack, спеки ваще читает?!Мне вот интересно другое :). А *ты* осилил их целиком прочесть? И как тебе этот талмудец? :)
>> Этот Daniel Mack, спеки ваще читает?!
> Мне вот интересно другое :). А *ты* осилил их целиком прочесть? И
> как тебе этот талмудец? :)Ну я их давно изучал. Ща ковырнул, чтоб уж точно глянуть размер.
А самом деле там много не нужно, для работы вполне хватает USB 1.1,
ну а остальное это уже оптимизация.
> Ну я их давно изучал. Ща ковырнул, чтоб уж точно глянуть размер.И как, мозг не опух? :))). Для сравнения - иди вон драйвер UART какогонить заэйсплойть? ;) Там все просто слишком просто для того чтобы можно было эксплойтировать ремотно сам драйвер. Может, старина D.J. Berstein был не так уж и неправ, рассуждая о том как можно уменьшить число багов в софте? Самое веселое что его рассуждения никак не привязаны к ЯП и он умудрился написать несколько довольно секурных программ на обычном си :)
> А самом деле там много не нужно, для работы вполне хватает USB
> 1.1, ну а остальное это уже оптимизация.Не, ну понятно что если знаешь что долбить - достаточно в конкретное место доки глянуть. А если как скрипткидди - то и вообще думать не надо: взял в руки девайс - получил результат. Все, теперь ты кульхакер! Просто потому что умеешь втыкать девайс в разъем, во! :)
А так - попрограммить сие в микроконтроллере - неплохая зарядка для мозга. Придет понимание некоторых сущностей с которыми работает юсб и как сие выглядит со стороны девайса, а полученные скиллы пригодятся для массы иных, более полезных применений. К сожалению, на это способен очень небольшой процент двуногих. Остальные почему-то слишком тупые :)
Что вы глупости такие спрашиваете?
Если б он не то чтоб читал, а хотя бы посмотрел включив мозг, то глупостей про "а почему в ядре 80байт когда в доке 0xff" не писал бы (наверное)
> Если б он не то чтоб читал, а хотя бы посмотрел включив мозг,
> то глупостей про "а почему в ядре 80байт когда в доке 0xff" не писал бы (наверное)Ну давай дальше, вместе посмеёмся....
подсказка: char[80], char[0xff]
Не страшно, можно сконфигурировать и собрать ядро без этого драйвера. А вот что делают в такой ситуации пользователи проприетарных ОС, лучше не думать:)
Аааааааа линух уязвим с любым ядром! ААааааа - я нашел уязвимость - это винчестер!Вот ....!!!
Если перечислять все способы взлома при ФИЗИЧЕСКОМ доступе к серваку О_О а? Тут тогда страница не загрузится!
Или физдоступа к серваку нет или из ядра все не нужные модули долой или вааще все :)
Народ, можно ли такой схемкой http://conture.by/post/347 запустить движок от веника? Спасибо за ответ.
