форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Взлом Linux через подключение USB-устройства стал реальностью"	+/–
Сообщение от opennews (ok) on 08-Мрт-11, 11:54
В 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.dev/opennews/art.shtml?num=29834
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Взлом Linux через подключение USB-устройства стал реальность..."	–27 +/–
Сообщение от iZEN (ok) on 08-Мрт-11, 11:54
Ещё одно доказательство того, что строки неизвестной длины с завершающим нулём в качестве признака конца данных этого типа данных, никуда не годятся — паскалевский тип строки с указанием точной длины в заголовке безопасный и предсказуемый. EPIC FAIL C/C++.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Взлом Linux через подключение USB-устройства стал реальность..."	+11 +/–
	Сообщение от klalafuda on 08-Мрт-11, 11:58
	Ну а в PHP даже указателей нет. Так что паскалю с сями до него как пешком до Китаю..
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	63. "Взлом Linux через подключение USB-устройства стал реальность..."	+2 +/–
	Сообщение от follow_me on 08-Мрт-11, 14:56
	И в Java нет , и что с того ? Недавно оба засветились с переполнениями базовых типов. Нет совершенных систем, ошибки можно найти везде. А по поводу топика - не более чем локальная уязвимость с повышением привилегий, только тяжелее в реализации по сравнению с прочими уязвимостями такого рода
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	130. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от FastDuck on 08-Мрт-11, 19:45
	> И в Java нет , и что с того ? Недавно оба засветились с переполнениями базовых типов. Нет совершенных систем, ошибки можно найти везде. Вы про баг с плавающей запятой? Переполнения нашли в реализации интерпретатора PHP, а не в  пользовательских приложениях как в этом случае. К тому же, код интерпретатора PHP написан C. Вообще, в случае Java/PHP и им подобных достаточно исправить переполнение в сам компиляторе/интерпретаторе, в случае C вся ответственность ложиться на плечи разработчиков приложений. Панацеи пока нет, а хотелось бы - лично я вижу решение в мощном безопасном рантайме (минимиизирует ошибки на низком уровне) и мощной системе типов (минимизирует ошибки на всех уровнях).
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	175. "Взлом Linux через подключение USB-устройства стал реальность..."	+5 +/–
	Сообщение от MiG on 08-Мрт-11, 22:07
	C/C++ изначально создавались как языки сочетающие в себе высокий уровень программирования и низкоуровневую эффективность. Ответственность за содеянное лежит на программисте.  Хочешь быстро ехать - отключай ABS, ESP, traction control и пр.. Новичок разобъётся, профессионал даст нужный результат. В конце концов если молотком ударил по пальцу, то виноват не инструмент. ;-)
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	201. "Взлом Linux через подключение USB-устройства стал реальность..."	–2 +/–
	Сообщение от anonymous vulgaris on 09-Мрт-11, 01:21
	> C/C++ изначально создавались как языки сочетающие в себе высокий уровень программирования   и низкоуровневую эффективность. Я понимаю что историю сейчас знать ни к чему, но вообще то C лепился кое-как чтоб было хоть чуть получше ассемблера. Ну и чтоб можно было работать на компе с 8 кБ ОЗУ (отсюда и так называемый лаконичный синтаксис). Ну а C++ лепился кое-как чтоб было чуть получше С.
	Ответить | Правка | ^ к родителю #175 | Наверх | Cообщить модератору

	64. "Взлом Linux через подключение USB-устройства стал реальность..."	–1 +/–
	Сообщение от Аноним123321 (ok) on 08-Мрт-11, 15:01
	> Ну а в PHP даже указателей нет. но при этом в PHP забыли сделать слабые ссылоки (weak ref)... о боже -- этоже ЛОЛ:-D таким образом PHP обречён на _цыклические_ ссылочные _сильные_ связи :-) :-) :-) [что совершенно не важно если приложение не должно жить более чем пару десятков милисекунд. поэтому всем php-web-программистом пофиг на отсутствие weak refs :-), а вот написать долгоиграющщую не-web-программу уже не получится :-)]
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	121. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от rshadow on 08-Мрт-11, 18:41
	Языки из разных категорий. Сравнивать их может только новичек в программировании =)
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	237. "Взлом Linux через подключение USB-устройства стал реальность..."	–1 +/–
	Сообщение от Аноним (??) on 09-Мрт-11, 12:20
	Кто такие новичеки?
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	193. "Взлом Linux через подключение USB-устройства стал реальность..."	+2 +/–
	Сообщение от Аноним (??) on 08-Мрт-11, 23:30
	>Ну а в PHP даже указателей нет. Так что паскалю с сями до него как пешком до Китаю.. Оберон - наше всё!
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	287. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от cobold (ok) on 10-Мрт-11, 13:28
	> Ну а в PHP даже указателей нет. Так что паскалю с сями до него как пешком до Китаю.. Это Вам наверное в PHP порушенные поинтеры не встречались, а мне как-то довелось с ними пободаться - когда по ходу встроенной функции по какой-то причине генерируется warning, изза этого переаллоцируется стек, а локальные переменные уже хранят указатели на прошлый stack frame. Вот результаты скрипта потом весело выглядят :) Да, в 5.3 это исправили.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	9. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от доброжелатель on 08-Мрт-11, 12:11
	Ок, для успешной индексации строк с over 2 млрд. символов всегда надо будет хранить лишних 4 байта, для любой строки, удачи !
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	11. "Взлом Linux через подключение USB-устройства стал реальность..."	–3 +/–
	Сообщение от Аноним (??) on 08-Мрт-11, 12:18
	> Ок, для успешной индексации строк с over 2 млрд. символов всегда надо > будет хранить лишних 4 байта, для любой строки, удачи ! да хоть 8 байт, хоть 32-а, это один фиг лучше, чем рут полученный через переполнение.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	13. "Взлом Linux через подключение USB-устройства стал реальность..."	+3 +/–
	Сообщение от Аноним (??) on 08-Мрт-11, 12:22
	Т.е. хранить 32 байта с длинной строки, когда сама строка занимает один байт это нормально?
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	18. "Взлом Linux через подключение USB-устройства стал реальность..."	+2 +/–
	Сообщение от iZEN (ok) on 08-Мрт-11, 12:40
	Поле длины строки необязательно должно быть фиксированной длины — есть алгоритмы кодирования длины произвольной последовательности. И лучше, чтобы оно всё-таки было в заголовке данных, а не в конце в виде завершающего нуля, чтобы ядро не занималось счётом байтов и динамическим перевыделением памяти под неизвестное число байтов, пока не будет считан последний байт строки, а заранее знало, сможет оно вместить всю строку в доступную память или нет.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	34. "Взлом Linux через подключение USB-устройства стал реальность..."	+3 +/–
	Сообщение от Аноним (??) on 08-Мрт-11, 13:15
	> есть алгоритмы кодирования длины произвольной последовательности. Это дополнительная сложность и время. Спорный оверхед, в общем. Может где-то и нужно, в большинстве применений - нет.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	192. "Взлом Linux через подключение USB-устройства стал реальность..."	+2 +/–
	Сообщение от Аноним (??) on 08-Мрт-11, 23:17
	>> есть алгоритмы кодирования длины произвольной последовательности. > Это дополнительная сложность и время. Спорный оверхед, в общем. Может где-то и > нужно, в большинстве применений - нет. а перераспределение памяти и поиск конца строки это не лишние ресурсы?
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	54. "Взлом Linux через подключение USB-устройства стал реальность..."	+5 +/–
	Сообщение от cmp (ok) on 08-Мрт-11, 14:26
	Проще разработать 1024битную архитектуру с sizeof(int) == 1024, запихать туда 2^1024 ОЗУ и не парится храня там ежесекундные снапшоты вселенной.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	209. "Взлом Linux через подключение USB-устройства стал реальность..."	–1 +/–
	Сообщение от User294 (ok) on 09-Мрт-11, 03:09
	> Поле длины строки необязательно должно быть фиксированной длины — есть алгоритмы > кодирования длины произвольной последовательности. ... только парсить долго :) а теперь представь что тебе придется рюхать миллион таких полей? А миллиард не хочешь? Не как тупо 1 регистровую операцию, как раньше, что быстро, а как целая уйма хитрых операций с регистрами и прочая, т.к. проц не умеет нативно работать с таким представлением.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	210. "Взлом Linux через подключение USB-устройства стал реальность..."	+2 +/–
	Сообщение от коксюзер on 09-Мрт-11, 03:30
	>> Поле длины строки необязательно должно быть фиксированной длины — есть алгоритмы >> кодирования длины произвольной последовательности. > ... только парсить долго :) а теперь представь что тебе придется рюхать Что парсить? Как рюхать? > миллион таких полей? А миллиард не хочешь? Не как тупо 1 Да чо уж там, берите сразу триллион - он в тыщу раз внушительнее миллиарда звучит. > регистровую операцию, как раньше, что быстро, а как целая уйма хитрых > операций с регистрами и прочая, т.к. проц не умеет нативно работать > с таким представлением. Так бы и написали: "Все это очень сложно и очень затратно. Правда-правда."
	Ответить | Правка | ^ к родителю #209 | Наверх | Cообщить модератору

	215. "Взлом Linux через подключение USB-устройства стал реальность..."	–1 +/–
	Сообщение от User294 (ok) on 09-Мрт-11, 05:27
	>> ... только парсить долго :) а теперь представь что тебе придется рюхать > Что парсить? Как рюхать? Я так понимаю что изен про кодирование интегеров с переменной длиной или типа того. Бывает такое, можно и правда закодировать интегер произвольного диапазона более компактно чем обычно. И такое кодирование часто попадается в транспортных протоколах двинутых на компактности любой ценой :). Расплатой за это обычно является некоторая геморность парсинга всего этого - на реконструкцию интегера из такой конструкции требуется несколько лишних операций. Одно дело погрузить в регистры проца число "как есть" и другое - пачка хитрых преобразований чтобы понять какой реально размер у variable-length integer и получить его в нормальном виде понятном процу. В итоге выигрывается в занимаемом числом месте (в байтах) - малые числа получаются короче. Но проигрывается в трудоемкости разбора этого представления.   >> миллион таких полей? А миллиард не хочешь? Не как тупо 1 > Да чо уж там, берите сразу триллион - он в тыщу раз > внушительнее миллиарда звучит. А тут все просто: вы не заметите 10 микросекунд вместо 1. Зато вы легко заметите 10 часов вместо 1 часа. Хотя в обоих случаях разница в все те же 10 раз, совершенно одинаковые ;) > Так бы и написали: "Все это очень сложно и очень затратно. Правда-правда." Ну одно дело тупо затолкать число в регистры (в лучшем случае аж 1 команда проца будет), а другое varibale-length кодирование сперва расколупать для этого :). Как бы будет некоторая разница в числе команд которые потребны для одного и того же действа - некое число доступно теперь процу для обработки в виде который был изначально задуман :)
	Ответить | Правка | ^ к родителю #210 | Наверх | Cообщить модератору

	220. "Взлом Linux через подключение USB-устройства стал реальность..."	+3 +/–
	Сообщение от коксюзер on 09-Мрт-11, 06:07
	> Я так понимаю что изен про кодирование интегеров с переменной длиной или > типа того. Бывает такое, можно и правда закодировать интегер произвольного диапазона > более компактно чем обычно. И такое кодирование часто попадается в транспортных > протоколах двинутых на компактности любой ценой :). Расплатой за это обычно Он вообще-то о строках, как я понял. В нормальных языках это происходит просто: вы параметризуете строковый тип максимальным размером строки, а компилятор выбирает, сколько байт под величину размера выделить. Не говоря о наличии возможности работать с нуль-терминированными строками и прочей ересью, если приспичило. > А тут все просто: вы не заметите 10 микросекунд вместо 1. Зато > вы легко заметите 10 часов вместо 1 часа. Хотя в обоих > случаях разница в все те же 10 раз, совершенно одинаковые ;) Это спекуляции о постороннем, но я таки замечу, что на современных суперскалярах всё не так очевидно, как в листинге ассемблера. Хотите узнать оверхед, надо профилировать, а не спекулировать.
	Ответить | Правка | ^ к родителю #215 | Наверх | Cообщить модератору

	246. "Взлом Linux через подключение USB-устройства стал реальность..."	–1 +/–
	Сообщение от User294 (ok) on 09-Мрт-11, 15:31
	> Он вообще-то о строках, как я понял. Я так понял что он предлагал хранить длину строки как variable length integer? > В нормальных языках это происходит просто: вы параметризуете строковый тип > максимальным размером строки, а компилятор выбирает, сколько байт под > величину размера выделить. А при нужде интероперабельно с остальными слить это на диск в файл или передать по сети в *предсказуемом* виде, который потом ремота/другая программа сможет распарсить без привязки к языку, платформе, етц - мы жесточайше факаем мозг, делаем не слишком тривиальные преобразования и что там еще, в общем как обычно. Известное дело, ага. Не, ну можно конечно себе поднасрать на ровном месте, затребовав сложную сериализацию-десериализацию, но это похоже на создание себе проблем сначала, а потом героическую борьбу с ними. Нахрена бы? :) > Не говоря о наличии возможности работать с нуль-терминированными строками > и прочей ересью, если приспичило. Ну, эта ересь как-то исторически прижилась, поэтому она есть. Если так придираться, UTF-8 с его переменным числом байтов на символ - тоже не подарок, только вот кодировать каждую букву как 32 или более битов ради того чтобы японцы/китайцы могли свои иерглифы пропихивать - жирновато будет, не? :) > Это спекуляции о постороннем, но я таки замечу, что на современных суперскалярах > всё не так очевидно, как в листинге ассемблера. Ессно, зависит от, но в общем случае чем больше инструкций, обращений к памяти и прочая - тем дольше они выполняются. И чем жирнее код - тем меньше шансов что он целиком попадет в кеш и резко выиграет в скорости. > Хотите узнать оверхед, надо профилировать, а не спекулировать. Ну да, всякие там жабисты любят дрюкаться с профайлером: их софт вечно тормозит, поэтому они зеленеют в профайлерах намного больше чем сишники/сиплюсплюсники, я это заметил, ыгы :))). И главное почему-то никто не пишет критичные к скорости программы на этих ваших крутых и правильных языках. Почему-то игры, сжатие, шифрование, кодеки, ну 3D и прочая навернутая математика которую надо в реалтайме успевать - все как одно на сях или плюсах. Хотя казалось бы JIT дает кучу теоретических преимущесв и что там еще. Обычно умудряются эти преимущества легко похерить кучей рантайм проверок, излишне задрюканными сущностями типа "интегер - это объект" и прочими наворотами.
	Ответить | Правка | ^ к родителю #220 | Наверх | Cообщить модератору

	261. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от iZEN (ok) on 09-Мрт-11, 17:31
	>> Он вообще-то о строках, как я понял. > Я так понял что он предлагал хранить длину строки как 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] элементов должен обеспечивать — это даёт нам гибкость в абстрагировании от конкретной реализации контейнера.
	Ответить | Правка | ^ к родителю #246 | Наверх | Cообщить модератору

	264. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от коксюзер on 09-Мрт-11, 17:52
	>> Он вообще-то о строках, как я понял. > Я так понял что он предлагал хранить длину строки как variable length > integer? >> В нормальных языках это происходит просто: вы параметризуете строковый тип >> максимальным размером строки, а компилятор выбирает, сколько байт под >> величину размера выделить. > А при нужде интероперабельно с остальными слить это на диск в файл Трололо, придумаем проблему и выделим ей абзац в нашей простыне. > или передать по сети в *предсказуемом* виде, который потом ремота/другая программа Ха, данные по сети всегда передаются с таким оверхедом по заголовкам, что сравнивать его с 32/64-битной величиной длины строки - вообще срам. ;) > сможет распарсить без привязки к языку, платформе, етц - мы жесточайше > факаем мозг, делаем не слишком тривиальные преобразования и что там еще, Это всё чушь. Поточная сущность ввода-вывода позволяет подставить любые заголовки до или после строк. Хоть терминировать '\0', хоть записать размер в беззнаковое целое - как угодно. А уж вес этих операций делает любые разговоры об оверхеде на пару-тройку операций с двойным словом просто неприличными. Это всё троллинг. iZEN вообще всех затроллил - начал тред и сел смотреть на массакр. :) > в общем как обычно. Известное дело, ага. Не, ну можно конечно Угу, да. Не, ну конечно же можно. > себе поднасрать на ровном месте, затребовав сложную сериализацию-десериализацию, но это > похоже на создание себе проблем сначала, а потом героическую борьбу с > ними. Нахрена бы? :) Вот именно, нахрена бы? > Ну, эта ересь как-то исторически прижилась, поэтому она есть. Если так придираться, Вы уже определитесь, вам ASCIIZ-строки не нравятся или их альтернативы? ;) > UTF-8 с его переменным числом байтов на символ - тоже не Вот уж где оверхед, так это парсинг не-ASCII текста в UTF-8! Правда, даже этот оверхед в большинстве случаев ничего не решает, и мы тут просто троллим порожняком. > подарок, только вот кодировать каждую букву как 32 или более битов Кодировать! О, кошмар! О, ужас!!!1 Бегом переходить на UTF-8 за полчаса - уж там-то, наверное, кодирования нет. ;) > ради того чтобы японцы/китайцы могли свои иерглифы пропихивать - жирновато будет, > не? :) Гы. Лол. >> Это спекуляции о постороннем, но я таки замечу, что на современных суперскалярах >> всё не так очевидно, как в листинге ассемблера. > Ессно, зависит от, но в общем случае чем больше инструкций, обращений к Тролололо в общем случае. > памяти и прочая - тем дольше они выполняются. И чем жирнее > код - тем меньше шансов что он целиком попадет в кеш > и резко выиграет в скорости. И чем дольше, тем жирнее, ага. ;) > Ну да, всякие там жабисты любят дрюкаться с профайлером: их софт вечно > тормозит, поэтому они зеленеют в профайлерах намного больше чем сишники/сиплюсплюсники, > я это заметил, ыгы :))). И главное почему-то никто не пишет > критичные к скорости программы на этих ваших крутых и правильных языках. Потому что пока правильные языки проектировались с учётом требований и обязывали производителей компиляторов к стандартизации для применения торговых марок-названий языка, академическое сообщество весело и задорно клепало экосистему Си-подобных языков, включая ОС, и её апологетов, привлекая внимание индустрии к тому, что уже освоено и "is just good enough". > Почему-то игры, сжатие, шифрование, кодеки, ну 3D и прочая навернутая математика > которую надо в реалтайме успевать - все как одно на сях На ассемблере. > или плюсах. Хотя казалось бы JIT дает кучу теоретических преимущесв и Или фортране. Алсо, спидфаг детектед. > что там еще. Обычно умудряются эти преимущества легко похерить кучей рантайм > проверок, излишне задрюканными сущностями типа "интегер - это объект" и прочими > наворотами. Потому что спидфаги нихрена не целевая аудитория мелких транснациональных конторок, которые клепают эти платформы. Что в позе неуловимых Джо позволяет первым прокачать ЧСВ и набухнуть от чувства сопричастности с Самым Быстрым Языком (нужный подчеркнуть).
	Ответить | Правка | ^ к родителю #246 | Наверх | Cообщить модератору

	268. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Dvorkin (??) on 09-Мрт-11, 18:43
	> Потому что спидфаги нихрена не целевая аудитория мелких транснациональных конторок, > которые клепают эти платформы. Что в позе неуловимых Джо позволяет первым прокачать ЧСВ > и набухнуть от чувства сопричастности с Самым Быстрым Языком (нужный подчеркнуть). я бы посмотрел, как мир бы тужился с виндоус и линукс на джаве или питоне, спидфаги, говоришь, хреновы?
	Ответить | Правка | ^ к родителю #264 | Наверх | Cообщить модератору

	270. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от коксюзер on 09-Мрт-11, 18:54
	>> Потому что спидфаги нихрена не целевая аудитория мелких транснациональных конторок, >> которые клепают эти платформы. Что в позе неуловимых Джо позволяет первым прокачать ЧСВ > и набухнуть от чувства сопричастности с Самым Быстрым Языком (нужный подчеркнуть). > я бы посмотрел, как мир бы тужился с виндоус и линукс на > джаве или питоне, > спидфаги, говоришь, хреновы? Когда я пишу "другие низкоуровневые языки", обвиняют в отсутствии конкретики, когда пишут "Ада", переводят разговор на джавы и питоны. Что за жизинь, э! ;)
	Ответить | Правка | ^ к родителю #268 | Наверх | Cообщить модератору

	19. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от caps on 08-Мрт-11, 12:40
	Удивительно, но в ядре "вражеской" системы от МС этот тип строк используется повсеместно. Наверняка там работают тупые придурки, которые  для безопасности пространства ядра бездарно тратят целых 2 байта на строку. (там для длины строки используется word тип)
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	103. "Взлом Linux через подключение USB-устройства стал реальность..."	+8 +/–
	Сообщение от test (??) on 08-Мрт-11, 17:10
	Ну и как, сильно безопасное получилось?
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	104. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от коксюзер on 08-Мрт-11, 17:14
	> Ну и как, сильно безопасное получилось? Несильно, ибо строки не единственная и даже не самая серьёзная проблема си.
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	216. "Взлом Linux через подключение USB-устройства стал реальность..."	+2 +/–
	Сообщение от User294 (ok) on 09-Мрт-11, 05:36
	> Несильно, ибо строки не единственная и даже не самая серьёзная проблема си. Да уж. Индусы успешно доказывают что обделаться с критичными последствиями можно и на яве, питоне, пхп, [insert your favorite language here]. Ну не переполнение буфера так ремот инклюд, sql иньекция, XSS, CSRF ... - вам как, сильно полегчало? Ну упрет хацкер 100500 аккаунтов от гмыльников, фэйсовконтактов и прочая и вообще базу похерит/изменит, наприер - не факт что это нанесет меньше ущерба чем какое-то там переполнение буфера. В конечном итоге хакерье нынче давно уже не интересует возможность выполнить код ради возможности выполнить код. Это их интересует чтобы поиметь профит или данные пользователей. И возможность с дикими извращениями при физическом доступе к машине поиметь доступ к 1 машине - далеко не самая страшная дырень в свете таких реалий. Куда моднее массовое, ремотное поимение, bulk-рассылка спама, массовой кражи конфиденциальных и ценных данных, при том первое как правило нужно в основном для второго и третьего. Самое странное в этом то что дыры в сишном коде при работе с сетью встречаются весьма редко - дыр в web-приложениях например почему-то в 100500 раз больше оказывается. Хотя, казалось бы, переполнений буферов нет, стек хрен сорвешь, ну что еще этим ... не хватает для безопасного написания программ?!
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	61. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Sw00p aka Jerom on 08-Мрт-11, 14:52
	> Т.е. хранить 32 байта с длинной строки, когда сама строка занимает один > байт это нормально? блин - проверка должна быт ьи в функцию должна передаваться длина строки
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	79. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от коксюзер on 08-Мрт-11, 16:16
	> блин - проверка должна быт ьи в функцию должна передаваться длина строки Конечно должна. Это же какой контроль!
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	77. "Взлом Linux через подключение USB-устройства стал реальность..."	+5 +/–
	Сообщение от коксюзер on 08-Мрт-11, 16:14
	> Т.е. хранить 32 байта с длинной строки, когда сама строка занимает один > байт это нормально? Ненормально - путать биты с байтами и забывать о возможности параметризации типов.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	69. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Аноним (??) on 08-Мрт-11, 15:41
	> Ок, для успешной индексации строк с over 2 млрд. символов всегда надо будет хранить лишних 4 байта, для любой строки, удачи ! А тебе успешного выяснения длинны строки. Жди когда найдет заветный байт в 2хгиговом куске данных
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	247. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от User294 (ok) on 09-Мрт-11, 15:38
	> А тебе успешного выяснения длинны строки. Жди когда найдет заветный байт в > 2хгиговом куске данных А в чем принципиальная разница по скорости: проверять ли байт на то что он равен нулю, и если да - то забить, или проверять что счетчик байтов дотикал до нужного значения, и если равен - то забить? С точки зрения трансформации в машинный код - получится примерно одинаково. С точки зрения попадания в кещ - по идее  в него не попадет только 2Гб данных, остальное уместится даже в самый мизерный в кеш. Я что-то упустил и в каком-то месте наступает зверский профит?
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	251. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Аноним (??) on 09-Мрт-11, 16:31
	В некоторых алгоритмах желательно иметь длину строки заранее, например, для склеивания двух строк должна быть известна длина первой, т.е. имеем бесполезное пробегание циклом по строке. В результате, если надо склеить 10 строк по 10 символов, получаем 10*(1+2+...+9) = 450 чтений символов. Для 100-символьной строки замедление в 6 раз, круто? )
	Ответить | Правка | ^ к родителю #247 | Наверх | Cообщить модератору

	262. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от User294 (ok) on 09-Мрт-11, 17:39
	> В некоторых алгоритмах желательно иметь длину строки заранее, например, для склеивания > двух строк должна быть известна длина первой, Это только в том (относительное редком) случае, если destination совпадает с первой строкой, там есть достаточно места куда можно отрастить результат и допустимо менять содержимое. Хотя черт с вами, уговорили, можно таскать счетчик отдельно и иногда это и правда будет эффективнее. А какая проблема сделать это на си если такая задача есть и ее скорость критична? :) А то что все и вся не пихают по дефолту - ну так если впихать все и вся по принципу "а вдруг пригодится?!" - получится еще одна ява, где можно уснуть пока hello world стартанет...
	Ответить | Правка | ^ к родителю #251 | Наверх | Cообщить модератору

	263. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от iZEN (ok) on 09-Мрт-11, 17:43
	>> В некоторых алгоритмах желательно иметь длину строки заранее, например, для склеивания >> двух строк должна быть известна длина первой, > Это только в том (относительное редком) случае, если destination совпадает с первой > строкой, там есть достаточно места куда можно отрастить результат и допустимо > менять содержимое. Хотя черт с вами, уговорили, можно таскать счетчик отдельно > и иногда это и правда будет эффективнее. А какая проблема сделать > это на си если такая задача есть и ее скорость критична? Проблема в том, что в сях оно будет не на уровне компилятора, а где-то "сбоку" в левой библиотечке, о которой многие разработчики будут не в курсе, и будут писать собственные велосипедики, несовместимые с ней.
	Ответить | Правка | ^ к родителю #262 | Наверх | Cообщить модератору

	266. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от коксюзер on 09-Мрт-11, 18:15
	>> В некоторых алгоритмах желательно иметь длину строки заранее, например, для склеивания >> двух строк должна быть известна длина первой, > Это только в том (относительное редком) случае, если destination совпадает с первой > строкой, там есть достаточно места куда можно отрастить результат и допустимо А если не совпадает, длину обеих строк не обязательно знать для выделения буфера под результат, ага-ага. ;) > менять содержимое. Хотя черт с вами, уговорили, можно таскать счетчик отдельно > и иногда это и правда будет эффективнее. А какая проблема сделать > это на си если такая задача есть и ее скорость критична? Проблема не в том, чтобы сделать это на Тюринг-полном языке, а в том, что что решение получится относительно неудобным. Можно вообще проставить вопрос, зачем Си если есть лисп, фортран и ассемблер? > :) А то что все и вся не пихают по дефолту > - ну так если впихать все и вся по принципу "а > вдруг пригодится?!" - получится еще одна ява, где можно уснуть пока > hello world стартанет... Закупайте Фейри в цистернах. :Р
	Ответить | Правка | ^ к родителю #262 | Наверх | Cообщить модератору

	274. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Аноним (??) on 09-Мрт-11, 19:42
	> А если не совпадает, длину обеих строк не обязательно знать для выделения буфера под результат, ага-ага. ;) А если не совпадает, обе строки пробегаются в любом случае, и разницы по времени никакой, что со счетчиком, что без. Другое дело, что это далеко не каждый случай. В том же примере со строками 10х10 очень накладно будет перебрасывать строки между буферами туда-сюда, выделять память каждый раз, это же страшно медленно, лучше заранее выделить буфер с запасом. Существует рекомендация выделять память блоками по 2^N байт, это здорово сокращает фрагментацию и количество выделений-освобождений, при этом прога сжирает максимум вдвое больше памяти, чем ей реально нужно. > Проблема не в том, чтобы сделать это на Тюринг-полном языке, а в том, что что решение получится относительно неудобным. Можно вообще проставить вопрос, зачем Си если есть лисп, фортран и ассемблер? Стандарт скоро не перепишешь, а отдельно взятый компилер (GCC) - запросто. В настройках компиляции переключатель типов строк по умолчанию, и строковая библиотека в двух вариантах.
	Ответить | Правка | ^ к родителю #266 | Наверх | Cообщить модератору

	277. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от paxuser (ok) on 09-Мрт-11, 20:05
	> А если не совпадает, обе строки пробегаются в любом случае, и разницы > по времени никакой, что со счетчиком, что без. Не в любом случае, а в ряде случаев. В любом случае как раз нужно знать длину каждой строки ("пробежаться" по обеим один раз), выделить буфер размером с обе и "пробежаться" по строкам второй раз, при копировании. > Другое дело, что это далеко не каждый случай. В том же примере > со строками 10х10 очень накладно будет перебрасывать строки между буферами туда-сюда, Обсуждение абстрактных алгоритмов класса "туда-сюда" вносит конструктив и способствует взаимопониманию. > выделять память каждый раз, это же страшно медленно, лучше заранее выделить > буфер с запасом. Существует рекомендация выделять память блоками по 2^N байт, > это здорово сокращает фрагментацию и количество выделений-освобождений, при этом прога > сжирает максимум вдвое больше памяти, чем ей реально нужно. Я так понял, когда та же джава разом выделяет память под кучу, сишники тычат в неё пальцами и сравнивают такой расход памяти с утечками. А прижмешь их на предмет эффективной работы со строками, начинают рассказывать о преаллокации и оверхеде "максимум вдвое больше". Очень показательно. Наверное, если спросить про сериализацию строк с предварительным указанием размера в заголовках (тот же HTTP), они будут рассказывать о хранении длины в структурах и массивах. Ведь это же так медленно, пересчитывать её каждый раз! Поэтому в Си всё быстро, и контроль полный (ну ведь можно же хранить в структурах, кто не даёт-то?). То ли дело в других языках - всё джавой накрылось и дотнет полный. > Стандарт скоро не перепишешь, а отдельно взятый компилер (GCC) - запросто. В > настройках компиляции переключатель типов строк по умолчанию, и строковая библиотека в > двух вариантах. Дооо, нужно просто допилить GCC, добавить строковый тип (который не нужен, ведь оверхед максимум вдвое больше!), и всё пучком. Других проблем нет.
	Ответить | Правка | ^ к родителю #274 | Наверх | Cообщить модератору

	281. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от фыв (??) on 09-Мрт-11, 23:17
	> Не в любом случае, а в ряде случаев. В любом случае как раз нужно знать длину каждой строки ("пробежаться" по обеим один раз), выделить буфер размером с обе и "пробежаться" по строкам второй раз, при копировании. strcat не выделяет память. И я вроде уже писал, что выделять каждый раз память зело накладно, особенно если заранее известна предельная длина результата. > Обсуждение абстрактных алгоритмов класса "туда-сюда" вносит конструктив и способствует взаимопониманию. См выше. Попробуйте представить, что будет в том примере 10х10, если каждый раз под результат будет выделяться память, и оцените быстродействие. Помимо указанной задержки в 6 раз на лишнее копирование/пробегание будет задержка при выделении огрызков 10, 20, ..., 90, 100 байт, которые по окончании операции станут не нужны и освободятся, отлично фрагментировав память. Неужели не проще выделить буфер на 100 байт _один раз_ и работать с ним? > Я так понял, когда та же джава разом выделяет память под кучу, сишники тычат в неё пальцами и сравнивают такой расход памяти с утечками. А прижмешь их на предмет эффективной работы со строками, начинают рассказывать о преаллокации и оверхеде "максимум вдвое больше". Очень показательно. Это вы сами с собой разговариваете? Красиво у вас там все, должно быть, черт побери > Дооо, нужно просто допилить GCC, добавить строковый тип (который не нужен, ведь оверхед максимум вдвое больше!), и всё пучком. Других проблем нет. Вас сишники в магазине что ли обвешали? Или в детстве отнимали деньги на обеды?
	Ответить | Правка | ^ к родителю #277 | Наверх | Cообщить модератору

	285. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от paxuser (ok) on 10-Мрт-11, 04:31
	> strcat не выделяет память. И я вроде уже писал, что выделять каждый Ещё бы выделял. Всё руками. > раз память зело накладно, особенно если заранее известна предельная длина результата. Накладно, но всегда возможно или допустимо, в отличие от преаллокации по оценке сверху. И давайте без strcat как-то уже. Или проверку на выход за границы буфера в общем случае тоже можно не делать? :) Алсо, с вами скучно троллить. > выделить буфер на 100 байт _один раз_ и работать с ним? В этом случае проще. А когда нужно дать отлуп пользователю (источнику входных данных), если результат не вместится в буфер? Предложите начать копировать, а ошибку вернуть в случае заполнения буфера? Нет, вы спросите, что мешает пользователю передать размер строки вместе со строкой (как собственно и происходит чаще всего). То есть, предложите так или иначе пробросить передачу размера по всей цепочке вызовов. Мол, пользователь знает длину строки, поскольку он её откуда-то получил, вот пусть и передаст. И вроде бы проблема решена, но традиционно для Си - нагибая пользователей API. А если API чего-то не предусматривает (плохие проектировщики изначально сделали его простым) - это не проблема языка. Ведь так? И потом, конкатенация - частный случай. Как думаете, сложно найти задачу по эффективной работе со строками, для которой придётся переизобрести строки с хранимой длиной? С подстроками у си как? Ах, ну да: изобретаем свой структурный тип (не совместимый с нуль-терминацией и стандартными функциями), и всё замечательно. Полный контроль. И не рассказывайте мне, что таких задач нет - есть, решал пару месяцев назад и плевался. > Это вы сами с собой разговариваете? Красиво у вас там все, должно > быть, черт побери Это я рассуждаю вслух. Вам, вот, повод поёрничать дал. А вы продолжайте, не стесняйтесь - ваши догадки о причинах моей нелюбви к Си весьма любопытны. > Вас сишники в магазине что ли обвешали? Или в детстве отнимали деньги > на обеды? Ну конечно же дело во мне. Придумал проблемы, которых нет.
	Ответить | Правка | ^ к родителю #281 | Наверх | Cообщить модератору

	10. "Взлом Linux через подключение USB-устройства стал реальность..."	–8 +/–
	Сообщение от Аноним (??) on 08-Мрт-11, 12:12
	А если мне нужна строка > 255 символов? Думай прежде, чем писать
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	21. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от frankl on 08-Мрт-11, 12:51
	учил turbo pascal? Выходи из анабиоза, есть строки в паскале превышающие 255... >Думай прежде, чем писать ты хотя бы думай. Хоть когда нибудь.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	14. "Взлом Linux через подключение USB-устройства стал реальность..."	+5 +/–
	Сообщение от anonymous (??) on 08-Мрт-11, 12:23
	ну и какое отношение имеют стандартные библиотеки C, которые ориентрируются на терминирующий нулевой символ к коду ядра линукс, где этих библиотек нет и быть не может? не надо путать язык и используемые им библиотеки. да, покормил.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	31. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от anonymous (??) on 08-Мрт-11, 13:12
	прошу прощения, невнимательно читал новость. >связанный с использованием для копирования содержимого строки небезопасной функции strcpy(), вместо учитывающего длину строки варианта strlcpy(). таки они скопировали часть функций в ядро. впрочем, всё равно, это недостаток  этих функций, а никак не языка.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	80. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от коксюзер on 08-Мрт-11, 16:19
	> таки они скопировали часть функций в ядро. впрочем, всё равно, это недостаток >  этих функций, а никак не языка. Конечно-конечно. Уж в языке-то есть тип данных, позволяющий отказаться от ручного управления границами. И стандарт на библиотеки есть, и их реализаций - пруд пруди. А виноваты программеры, да.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	16. "Взлом Linux через подключение USB-устройства стал реальность..."	+15 +/–
	Сообщение от тоже Аноним (ok) on 08-Мрт-11, 12:34
	ВНЕЗАПНО! И С, и тем более С++ позволяют реализовать строку именно так, как вам это нужно. С любыми проверками и любой оптимизацией - по вкусу. Без хитрых хаков для кривых костылей...
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	73. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Ytch on 08-Мрт-11, 15:50
	Именно так! А еще, в ряде случаев, можно сделать проверки длин и расстановку защитных '\0' в концах массивов ДО вызова продедур копирования/сравнения/и т. п. и не тратить время на лишние проверки на каждой итерации циклов.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	82. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от коксюзер on 08-Мрт-11, 16:27
	> ВНЕЗАПНО! И С, и тем более С++ позволяют реализовать строку именно так, > как вам это нужно. > С любыми проверками и любой оптимизацией - по вкусу. Без хитрых хаков > для кривых костылей... Особенно в Си. Прямо бери и реализуй литералы и неявные преобразования типов. Ага, ну-ну. А в С++ кроме строк проблем нет, конечно же - полный контроль над адресной арифметикой, ага. Ну-ну. ;)
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	176. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от тоже Аноним (ok) on 08-Мрт-11, 22:10
	Вы не любите языки, на которых нельзя написать фреймворк и сделать вид, что это другой язык? Тогда низкоуровневые языки просто не для вас. Проблема, которую вы пытаетесь придумать, решается одной функцией. Если в вашем коде используется только определенный вами тип строк и любая входящая строка преобразуется к вашему типу через одну, предусматривающую вероятность переполнения, функцию, то в вашем коде переполнения строки не будет. Вот и все...
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	187. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от коксюзер on 08-Мрт-11, 22:57
	> Вы не любите языки, на которых нельзя написать фреймворк и сделать вид, > что это другой язык? Тогда низкоуровневые языки просто не для вас. Пляска вокруг убогой системы типов и её последствия - фамильная черта языков семейства Си. В нормальных низкоуровневых языках этого нет. > Проблема, которую вы пытаетесь придумать, решается одной функцией. Если в вашем коде Реальная, а не абстрактная, проблема, отсутствие которой вы пытаетесь придумать, воплощена в массе унаследованного кода. Обсуждаемая новость - об одном из её проявлений. Предлагаемые структурные строковые типы на Си - это неудобный костыль без нативной поддержки в языке и библиотеках, который используют единицы из тысяч, в лучшем случае. > используется только определенный вами тип строк и любая входящая строка преобразуется > к вашему типу через одну, предусматривающую вероятность переполнения, функцию, то в > вашем коде переполнения строки не будет. Вот и все... Действительно, вот и всё: и удобно, и все пользуются, и унаследованный код сам себя переписал, и все остальные проблемы Си решились сами собой.
	Ответить | Правка | ^ к родителю #176 | Наверх | Cообщить модератору

	226. "Взлом Linux через подключение USB-устройства стал реальность..."	–1 +/–
	Сообщение от тоже Аноним (ok) on 09-Мрт-11, 08:33
	Фамильная черта тех, кто гонит на С - упоминание неких "нормальных языков" без конкретизации... Каким образом людям, писавшим драйвера, удалось унаследовать у кого-то код - для меня загадка.
	Ответить | Правка | ^ к родителю #187 | Наверх | Cообщить модератору

	227. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от коксюзер on 09-Мрт-11, 08:56
	> Фамильная черта тех, кто гонит на С - упоминание неких "нормальных языков" > без конкретизации... Ада. > Каким образом людям, писавшим драйвера, удалось унаследовать у кого-то код - для > меня загадка. А отгадка в том, что вы вынимаете слова из контекста.
	Ответить | Правка | ^ к родителю #226 | Наверх | Cообщить модератору

	230. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от тоже Аноним (ok) on 09-Мрт-11, 10:29
	Конечно! Нет унаследованного кода - нет проблемы!
	Ответить | Правка | ^ к родителю #227 | Наверх | Cообщить модератору

	259. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от коксюзер on 09-Мрт-11, 17:26
	> Конечно! Нет унаследованного кода - нет проблемы! Да что вы говорите! Ещё раз: у Си полно проблем помимо кривых строк. Чтобы их решить, нужно превратить Си в Cyclone. Никакой пляской с идиомами и API здесь не отделаться.
	Ответить | Правка | ^ к родителю #230 | Наверх | Cообщить модератору

	248. "Взлом Linux через подключение USB-устройства стал реальность..."	–1 +/–
	Сообщение от User294 (ok) on 09-Мрт-11, 15:57
	> Ада. Ну и где операционки на ней и желающие на оной их писать? Не хочу ничего сказать, но все навороты типизации и излишние умничания компилера при работе с железом будут только жесточайше МЕШАТЬСЯ, когда потребуется например загнать ровно 4 байта да еще в строго определенном endianess'е в регистры вон той железяки. И заметьте, железяка хочет только так и никак иначе. На сях это даже относительно реально делать без огроменного геморроя. Как раз в силу простоты типов и отсутствия наворотов там где они только мешаются.
	Ответить | Правка | ^ к родителю #227 | Наверх | Cообщить модератору

	250. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от klalafuda on 09-Мрт-11, 16:12
	> Ну и где операционки на ней и желающие на оной их писать? Не хочу ничего сказать, но все навороты типизации и излишние умничания компилера при работе с железом будут только жесточайше МЕШАТЬСЯ, когда потребуется например загнать ровно 4 байта да еще в строго определенном endianess'е в регистры вон той железяки. И заметьте, железяка хочет только так и никак иначе. На сях это даже относительно реально делать без огроменного геморроя. Как раз в силу простоты типов и отсутствия наворотов там где они только мешаются. Непосредственно загнать 4 байта в регистры вон той железяки - это примерно 0 целых хрен десятых % от трудоемкости общего кода ядра. Решается минимальным тоненьким врапером над непосредственным доступом к физической памяти/регистрам/etc хоть на ассемблере. Который вылизывается до блеска специальным стадом котов. Все остальное - это самый обычный код. В котором собственно и делают те самые неприятные ошибки самые обычные люди. И уже на этом уровне 'широкие возможности C' - это скорее геморрой нежели благо. Никому в трезвом умен и здравом сознании не приходит в голову браться писать на C действительно сложный ответственный код в 21м веке. Как минимум - выбор за C++. А зачастую и что-то куда более высокоуровневое - жаба, эрланг, те или иные скриптовые решения - зависит от конкретной ситуации. Но никак не ассемблер или C.
	Ответить | Правка | ^ к родителю #248 | Наверх | Cообщить модератору

	267. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от User294 (ok) on 09-Мрт-11, 18:27
	> Непосредственно загнать 4 байта в регистры вон той железяки - это примерно > 0 целых хрен десятых % от трудоемкости общего кода ядра. Угу, а код драйверов вы смотреть не пробовали? Там такого кода - хоть отбавляй, и драйвера - весьма существенный кусок ядра, собссно :) > Решается минимальным тоненьким врапером над непосредственным доступом > к физической памяти/регистрам/etc хоть на ассемблере. Который вылизывается > до блеска специальным стадом котов. Все остальное - это самый обычный код. Этот обычный код в основном занимается как раз довольно необычными низкоуровневыми задачами. Может я что-то и не понимаю в этой жизни, но общематематические и прикладные задачи (ака "обычный код") не являются целью ради которой делают ядра ОС. Ядра как раз по задумке именно прослойка между железом и прикладным софтом, не привязанным к железу и желательно особенностям низкоуровневой реализации конкретной ОС. Предлагаете делать врапперы в врапперах? А в тех врапперах не надо врапперов? :) > В котором собственно и делают те самые неприятные ошибки самые обычные люди. > И уже на этом уровне 'широкие возможности C' - это скорее геморрой нежели благо. Ну так пишите программы работающие с юсб через юзермод на чемнить высокоуровневом, правда мне почему-то кажется что это будет не самым безгеморройным начинанием :) > Никому в трезвом умен и здравом сознании не приходит в голову браться > писать на C действительно сложный ответственный код в 21м веке. Именно сложный - да, только странная какая-то цель: "написать сложный код". Код должен быть простым и прозрачным. > Как минимум - выбор за C++. А зачастую и что-то куда более высокоуровневое > - жаба, эрланг, те или иные скриптовые решения - Ну так напишите на этом кернель, а я посмотрю на параметры и подумаю - надо оно мне, или в сад. На кой хрен мне враппер между моей программой и оборудованием писаный на жабе, а? Тем более что ява - затевалась для независимости от оборудования, по поводу чего она сама нуждается в враппере, ибо там "немного забыли" реализовать свои дрова для тех же юсб-звуковух и прочая :) > зависит от конкретной ситуации. Но никак не ассемблер или C. Ха, вы будете учить системщиков как им надо писать кернелы? Не, хренушки, так не катит. Давайте вы сделаете ваше крутое, правильное, и на чем вам там надо? И вот когда оно всех зарулит - тогда ваш тезис "никак не ассемблер или C" и будет доказан, имхо :). Только вот высокоуровневые сложные конструкции ИМХО не очень просто и быстро трансформируются в простые наборы байтов и даже битов с которыми работает железо, если что. А приколитесь, бывают железки которые хотят, допустим не 8 и не 16 битов. А 12 битов, например. Ничему не противоречит послать по сериальной шине именно 12 битов, а вовсе не 8 или 16. Интересно было бы посмотреть как вы 12-битные слова, нативные для железки будете в высокоуровневые абстракции упаковывать и какая будет скорость враппинга всего этого :).Особенно если чипмейкер не искал легких путей и сделал так что первые 9 битов - одно поле, а еще три - другое. Во вы там наврапаетесь то :)
	Ответить | Правка | ^ к родителю #250 | Наверх | Cообщить модератору

	269. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от коксюзер on 09-Мрт-11, 18:53
	> Угу, а код драйверов вы смотреть не пробовали? Там такого кода - > хоть отбавляй, и драйвера - весьма существенный кусок ядра, собссно :) Теоретики такие теоретики: на дворе XXI век, а они до сих в порты по 4 байта пишут. :D > Этот обычный код в основном занимается как раз довольно необычными низкоуровневыми задачами. На той же Аде все эти низкоуровневые задачи решаются быстрее и надёжнее. :Р > Может я что-то и не понимаю в этой жизни, но общематематические :D > и прикладные задачи (ака "обычный код") не являются целью ради которой > делают ядра ОС. Ядра как раз по задумке именно прослойка между Да-да, в [s]СССР[/s] ядре линукса алгоритмов нет. :))) > железом и прикладным софтом, не привязанным к железу и желательно особенностям > низкоуровневой реализации конкретной ОС. Предлагаете делать врапперы в врапперах? А в > тех врапперах не надо врапперов? :) Ну может вы что-то знаете, чего мы не знаем? Вот Аде, например, какие врапперы нужны? Они ведь нужны, да? > Ну так пишите программы работающие с юсб через юзермод на чемнить высокоуровневом, > правда мне почему-то кажется что это будет не самым безгеморройным начинанием > :) Ага, лишние апи, лишние баги в ядре... Тут уж без Релифа никуда. :D > Именно сложный - да, только странная какая-то цель: "написать сложный код". Код > должен быть простым и прозрачным. Простым и прозрачным прям как опухшее монолитное ядро. :D >> зависит от конкретной ситуации. Но никак не ассемблер или C. > Ха, вы будете учить системщиков как им надо писать кернелы? Не, хренушки, Ну так и Вирт тоже учит. Давайте Вирта попинаем за академичность и отрыв от практики - это уже становится модно. :) > так не катит. Давайте вы сделаете ваше крутое, правильное, и на > чем вам там надо? И вот когда оно всех зарулит - Та гуано вопрос. 30 миллионов евро, и через 5 лет будет вам ядро. > тогда ваш тезис "никак не ассемблер или C" и будет доказан, Школоло. :Р Всех можно в контру зарулить, а ОС - они разные все, со своими достоинствами, недостатками и сферами применения. Я тут слышал тезис, согласно которому, обероны и системы на Аде, которые работают в критических промышленных и военных отраслях - это нифига не промышленный уровень. :) Промышленны - это видимо, когда много, везде, и хомячку видно. :Р > имхо :). Только вот высокоуровневые сложные конструкции ИМХО не очень просто > и быстро трансформируются в простые наборы байтов и даже битов с И даже кубитов, чо уж там. > которыми работает железо, если что. А приколитесь, бывают железки которые хотят, Гыгы. > допустим не 8 и не 16 битов. А 12 битов, например. > Ничему не противоречит послать по сериальной шине именно 12 битов, а > вовсе не 8 или 16. Интересно было бы посмотреть как вы > 12-битные слова, нативные для железки будете в высокоуровневые абстракции упаковывать Так 12-битные слова или байты, теоретический вы наш? :) > и какая будет скорость враппинга всего этого :).Особенно если чипмейкер не Враппинг!!1 > искал легких путей и сделал так что первые 9 битов - > одно поле, а еще три - другое. Во вы там наврапаетесь > то :) Та не говори, заврапало уже врапать (врап-врап).
	Ответить | Правка | ^ к родителю #267 | Наверх | Cообщить модератору

	280. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от тоже Аноним (ok) on 09-Мрт-11, 23:16
	> Теоретики такие теоретики: на дворе XXI век, а они до сих в порты по 4 байта пишут. :D Несмотря на XXI век, компьютер до сих пор включается в розетку и оперирует битами. Действительно, чудовищно. Но вы не зацикливайтесь на этом, у вас-то все хорошо...
	Ответить | Правка | ^ к родителю #269 | Наверх | Cообщить модератору

	283. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от paxuser (ok) on 10-Мрт-11, 01:06
	>> Теоретики такие теоретики: на дворе XXI век, а они до сих в порты по 4 байта пишут. :D > Несмотря на XXI век, компьютер до сих пор включается в розетку и > оперирует битами. > Действительно, чудовищно. Но вы не зацикливайтесь на этом, у вас-то все хорошо... Да, у меня (как впрочем и у вас) дрова давно гоняют данные с/на железо в основном через прямой доступ к памяти, а портовый ввод-вывод присутствует кое-где и кое-как лишь для инициализации и переключения режимов + всякая мишура, вроде сенсоров, последовательных и параллельных портов. Но вы не зацикливайтесь на фактах... ;)
	Ответить | Правка | ^ к родителю #280 | Наверх | Cообщить модератору

	265. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от коксюзер on 09-Мрт-11, 18:06
	>> Ада. > Ну и где операционки на ней и желающие на оной их писать? В гугле. > Не хочу ничего сказать, но все навороты типизации и излишние умничания > компилера при работе с железом будут только жесточайше МЕШАТЬСЯ, когда потребуется МЕШАТЬСЯ!!!!!111 8-*** > например загнать ровно 4 байта да еще в строго определенном endianess'е Так спидфаг или не спидфаг? А то спидфаги выравнивают структуры даже на CISC-архитектурах (не имею ничего против, кстати). ;) > в регистры вон той железяки. И заметьте, железяка хочет только так > и никак иначе. На сях это даже относительно реально делать без И заметьте, в Аде, в отличие от Си, в котором нет языковых средств безопасного программирования, есть языковые средства небезопасного оптимизированного программирования. Они там используются по выбору программиста и могут быть запрещены на уровне компилятора в рамках отдельных package, чтобы, например, не утруждать себя аудитом кода на предмет наличия неоправданных небезопасных оптимизаций. Вот где контроль, а не в этих ваших сях. :Р > огроменного геморроя. Как раз в силу простоты типов и отсутствия наворотов > там где они только мешаются. Все задачи в мире сводятся к тем, которые удобны программисту на Си как раз в силу простоты типов и отсутствия наворотов, ага. ;)
	Ответить | Правка | ^ к родителю #248 | Наверх | Cообщить модератору

	271. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от User294 (ok) on 09-Мрт-11, 19:07
	> В гугле. В гугле обычный линух на дешевых серверах :P. Да-да, гуглить для вас будет это решето на говняном х86... :))) > МЕШАТЬСЯ!!!!!111 8-*** Судя по тому что вменяемых операционок, готовых для использования до сих пор почему-то нет, видимо вы правы с усилением эмоций. Ну или почему все как идиоты пишут оси на сях когда вокруг уже несколько десятков лет как есть более правильные языки? >> например загнать ровно 4 байта да еще в строго определенном endianess'е > Так спидфаг или не спидфаг? В идеале программа должна занимать как можно меньше места, работать как можно быстрее, потребляя как можно меньше памяти :))). Я не виноват что эти требования иногда противоречат друг другу :P. > А то спидфаги выравнивают структуры даже на > CISC-архитектурах (не имею ничего против, кстати). ;) Как ни странно я тоже ничего против не имею. Если это не ведет к тому что вместо, допустим, мегабайта памяти жрется, скажем, 4. А то мало ли, линух работает и в железках где RAM всего 16 Мб бывает и никакого свопа, например. В общем все хорошо в меру. > И заметьте, в Аде, в отличие от Си, в котором нет языковых > средств безопасного программирования, есть языковые средства > небезопасного оптимизированного программирования. Они там используются > по выбору программиста и могут быть запрещены на уровне компилятора > в рамках отдельных package, чтобы, например, не утруждать себя аудитом кода > на предмет наличия неоправданных небезопасных оптимизаций. Вот где > контроль, а не в этих ваших сях. :Р Звучит неплохо. Только почему-то никто не пользуется адой, мир почему-то выбрал си. И дурные х86 с ископаемой системой команд и пачкой костылей. И почему-то я бы предпочел кернел где аудит все-таки сделали. А то если есть возможность "не утруждать себя аудитом кода", зная человеков я просто уверен что в итоге получится очередной энтерпрайзный крап где баг на баге и багом погоняет. Улет системы в панику а то и возможность сплойтом получить - явно не способствует тому чтобы плодить баги в коде, т.к. чревато :) > Все задачи в мире сводятся к тем, которые удобны программисту на Си > как раз в силу простоты типов и отсутствия наворотов, ага. ;) Вы только представьте себе, а ответная сторона ака фирмвара того же юсб-девайса ... обычно тоже пишется на си, ну, может с кусочками асма (хардкорный вариант - на голом асме, но нынче желающих это делать уже не так много как раньше). Логично что взаимодействовать с ней удобнее всего из тех же сей получается :)
	Ответить | Правка | ^ к родителю #265 | Наверх | Cообщить модератору

	273. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от paxuser (ok) on 09-Мрт-11, 19:37
	>> В гугле. > В гугле обычный линух на дешевых серверах :P. Да-да, гуглить для вас > будет это решето на говняном х86... :))) Поставим ответ иначе: гугль знает. >> МЕШАТЬСЯ!!!!!111 8-*** > Судя по тому что вменяемых операционок, готовых для использования до сих пор Ну так сделайте. Линух вон сперва вылез из грязи в князи, а потом крупные игроки пришли. А вы хотите чтобы за вас кто-то что-то делал. А оно этим кому-то надо - делать то что надо ВАМ а не ИМ? :) > почему-то нет, видимо вы правы с усилением эмоций. Ну или почему Хомячку не видно, а они есть. ;) > все как идиоты пишут оси на сях когда вокруг уже несколько > десятков лет как есть более правильные языки? Ну а почему все как идиоты сидят на винде когда вокруг уже несколько десятков лет есть BSD и линукс? Почему все как идиоты сидят на CISC-процессорах, когда вокруг давно есть RISC и VLIW? Почему все летают на дозвуковых самолётах и ездят на ЖД-поездах? Потому что привыкли, дёшево и сердито. Good enough. > В идеале программа должна занимать как можно меньше места, работать как можно > быстрее, потребляя как можно меньше памяти :))). Я не виноват что > эти требования иногда противоречат друг другу :P. Иногда программа должна быть надёжной и безопасной, написана на привычном и хорошо знакомом, выразительном и хорошо читаемом языке с нативной поддержкой параллельных вычислений, по которому на рынке труда есть спрос и предложение, за которым стоят крупные корпорации, заинтересованные в популяризации своего языка и платформы среди промышленников, военных, бизнеса, хомячков и геймеров. Кто виноват и доколе? > Как ни странно я тоже ничего против не имею. Если это не > ведет к тому что вместо, допустим, мегабайта памяти жрется, скажем, 4. Это главное, да. > А то мало ли, линух работает и в железках где RAM > всего 16 Мб бывает и никакого свопа, например. В общем все > хорошо в меру. Ага, всё хорошо в меру всегда и везде. ;) > Звучит неплохо. Только почему-то никто не пользуется адой, мир почему-то выбрал си. Вот ответ на вопрос: почему-то! :) И всё встало на свои места! :) > И дурные х86 с ископаемой системой команд и пачкой костылей. И Действительно, глупость. Альтернатив-то полно в каждом магазине, и совместимость полная. > почему-то я бы предпочел кернел где аудит все-таки сделали. А то > если есть возможность "не утруждать себя аудитом кода", зная человеков я Можно не проводить аудит на предмет конкретных недостатков => аудит не будут проводить вообще. Ага. Btw, его и сейчас никто не проводит, кроме единичных энтузиастов, пентестеров и криминала. ;) > просто уверен что в итоге получится очередной энтерпрайзный крап где баг > на баге и багом погоняет. Улет системы в панику а то Где-то я это уже [s]слышал[/s] видел. ;) > и возможность сплойтом получить - явно не способствует тому чтобы плодить > баги в коде, т.к. чревато :) Ага. Железная надёжность и высокий уровень ответственности за безопасность. Именно это мы сейчас и видим. Алсо, свобода - это рабство. ;) > Вы только представьте себе, а ответная сторона ака фирмвара того же юсб-девайса > ... обычно тоже пишется на си, ну, может с кусочками асма > (хардкорный вариант - на голом асме, но нынче желающих это делать > уже не так много как раньше). Логично что взаимодействовать с ней > удобнее всего из тех же сей получается :) Согласен, разница просто огромна: на сях я в порт или маппинг пишу/читаю, а на Аде и оберонах я в порти или маппинг пишу/читаю. Вы правы, ту мне возразить нечего.
	Ответить | Правка | ^ к родителю #271 | Наверх | Cообщить модератору

	28. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от Аноним (??) on 08-Мрт-11, 13:05
	Я бы на вашем месте прежде чем троллить изучил матчасть, но видимо этот путь не для вас, так вот вопрос, какие именно строки вы имеете ввиду, QString, CString, std::string или какие-то ещё?
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	35. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Аноним (??) on 08-Мрт-11, 13:18
	Поскольку это ядро, то очевидно не std::string ;)
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	62. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Sw00p aka Jerom on 08-Мрт-11, 14:53
	> Я бы на вашем месте прежде чем троллить изучил матчасть, но видимо > этот путь не для вас, так вот вопрос, какие именно строки > вы имеете ввиду, QString, CString, std::string или какие-то ещё? СТЛ ваш ни чем не лучше
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	83. "Взлом Linux через подключение USB-устройства стал реальность..."	–1 +/–
	Сообщение от коксюзер on 08-Мрт-11, 16:31
	> Я бы на вашем месте прежде чем троллить изучил матчасть, но видимо > этот путь не для вас, так вот вопрос, какие именно строки > вы имеете ввиду, QString, CString, std::string или какие-то ещё? А я бы на вашем месте изучил языки с более строгими системами типов, прежде чем кичиться формальным наличием выбора в рамках отдельно взятой проблемы (как будто других нет). Но очевидно, это путь не для вас.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	93. "Взлом Linux через подключение USB-устройства стал реальность..."	–1 +/–
	Сообщение от анон on 08-Мрт-11, 16:45
	> А я бы на вашем месте изучил языки с более строгими системами > типов, прежде чем кичиться формальным наличием выбора в рамках отдельно взятой > проблемы (как будто других нет). Но очевидно, это путь не для > вас. Предлагаете писать ядро на лиспе?
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	100. "Взлом Linux через подключение USB-устройства стал реальность..."	+2 +/–
	Сообщение от коксюзер on 08-Мрт-11, 17:07
	> Предлагаете писать ядро на лиспе? То есть лисп в ваших глазах - это язык со строгой системой типов? :))
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	113. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от анон on 08-Мрт-11, 17:57
	хаскель?) окамл?) уточните, на чем же нада писать ядра?)
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	126. "Взлом Linux через подключение USB-устройства стал реальность..."	–1 +/–
	Сообщение от klalafuda on 08-Мрт-11, 19:33
	> уточните, на чем же нада песать ядра?) Очевидно Ада. На пару с Обероном.
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	155. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Ytch on 08-Мрт-11, 20:49
	>> уточните, на чем же нада песать ядра?) >Очевидно Ада. На пару с Обероном. Это просто бред или какая-то очень тонкая ирония?
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	160. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от коксюзер on 08-Мрт-11, 20:54
	> Это просто бред или какая-то очень тонкая ирония? А что, разве на Аде и оберонах не написано ни одного ядра?
	Ответить | Правка | ^ к родителю #155 | Наверх | Cообщить модератору

	171. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от pavlinux (ok) on 08-Мрт-11, 21:42
	>> Это просто бред или какая-то очень тонкая ирония? > А что, разве на Аде и оберонах не написано ни одного ядра? неа
	Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

	178. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от gegMOPO4 (ok) on 08-Мрт-11, 22:18
	http://en.wikipedia.org/wiki/Oberon_(operating_system)
	Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

	183. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от pavlinux (ok) on 08-Мрт-11, 22:44
	> http://en.wikipedia.org/wiki/Oberon_(operating_system) Исходники ядра можно?
	Ответить | Правка | ^ к родителю #178 | Наверх | Cообщить модератору

	188. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от gegMOPO4 (ok) on 08-Мрт-11, 22:59
	Да, там свободная лицензия.
	Ответить | Правка | ^ к родителю #183 | Наверх | Cообщить модератору

	194. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Аноним (??) on 08-Мрт-11, 23:31
	>> http://en.wikipedia.org/wiki/Oberon_(operating_system) > Исходники ядра можно? ftp://ftp.inf.ethz.ch/pub/ETHOberon/Native/StdAlone/ не?
	Ответить | Правка | ^ к родителю #183 | Наверх | Cообщить модератору

	197. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от pavlinux (ok) on 08-Мрт-11, 23:50
	>>> http://en.wikipedia.org/wiki/Oberon_(operating_system) >> Исходники ядра можно? > ftp://ftp.inf.ethz.ch/pub/ETHOberon/Native/StdAlone/ не? Не, там бинарники и примеры.
	Ответить | Правка | ^ к родителю #194 | Наверх | Cообщить модератору

	288. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от cobold (ok) on 10-Мрт-11, 13:58
	> http://en.wikipedia.org/wiki/Oberon_(operating_system) Эта операционка была для Вирта самым большим фейлом в его жизни, IMHO. Крах идеи о том что можно писать академическим подходом вещи применимые на практике - вылизывать байты, когда память дешевеет дикими темпами; не заниматься абстракциями аппаратуры, когда целевая аудитория - пользователи персоналок, со всем уже тогда имевшимся зоопарком железа; совершенно не заботиться о usability пользовательских интерфейсов, хотя примеров удачных (и не очень) реализаций было уже достаточно. Знаете, у новичков такое порой случается: делать то что возможно, вместо того что требуется. Для Вирта это должен был быть конец карьеры.
	Ответить | Правка | ^ к родителю #178 | Наверх | Cообщить модератору

	291. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от paxuser (ok) on 10-Мрт-11, 19:17
	>> http://en.wikipedia.org/wiki/Oberon_(operating_system) > Эта операционка была для Вирта самым большим фейлом в его жизни, IMHO. Действительно, фейл. Но не по части инженерных и потребительских качеств. Он долго артачился сделать исходники свободными, академическое сообщество энтузиастов не сколотил и не особенно, на сколько я знаю, старался продвигать свою систему и язык за пределами вуза. > Крах идеи о том что можно писать академическим подходом вещи применимые > на практике - вылизывать байты, когда память дешевеет дикими темпами; не http://www.sql.ru/forum/actualthread.aspx?bid=16&tid=689811 - там перечислены некоторые случаи применения оберонов на практике. На базе паскаля была создана Ада, модула летала в космос уже в 80-ых. А крах идеи о том, что что-то можно писать "не академическим подходом", мы наблюдаем сегодня на примере юниксов и Си: проблемы с надёжностью, безопасностью, эффективностью разработки, плюс немасштабируемость выбранных архитектурных решений и потеря контроля за сложностью систем (тех самых моноядерных, одну из которых Торвальдс назвал раздутой и признался, что не видит путей решения этой проблемы). > заниматься абстракциями аппаратуры, когда целевая аудитория - пользователи персоналок, Ну да, других целевых аудиторий не бывает же. > со всем уже тогда имевшимся зоопарком железа; совершенно не заботиться о > usability пользовательских интерфейсов, хотя примеров удачных (и не очень) реализаций Для своего времени интерфейс оберонов был весьма удобен. Да и не создатели ОС должны его развивать, а сообщество, о формировании которого Вирт как раз и не позаботился. > было уже достаточно. Знаете, у новичков такое порой случается: делать то > что возможно, вместо того что требуется. Для Вирта это должен был > быть конец карьеры. :) В качестве домашнего задания предлагаю подумать, почему на практике этот конец до сих пор не наступил. ;)
	Ответить | Правка | ^ к родителю #288 | Наверх | Cообщить модератору

	127. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от коксюзер on 08-Мрт-11, 19:33
	> хаскель?) окамл?) > уточните, на чем же нада песать ядра?) Т.е. вы мне кагбе придлогаите передти от тролинга к розговору по сущиству?
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	147. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от анон on 08-Мрт-11, 20:36
	Нет не предлагаю, т.к. по существу вам просто нечего сказать. Иначе б давно сказали) А уж каким местом статическая типизация к новости про кернел, вообще непонятно.
	Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

	154. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от коксюзер on 08-Мрт-11, 20:47
	> Нет не предлагаю, т.к. по существу вам просто нечего сказать. Иначе б > давно сказали) Я говорил и не раз. Если вы считаете, что нет Тюринг-полных типобезопасных языков на которых были бы написаны реально применяемые ОС, это ваши проблемы. > А уж каким местом статическая типизация к новости про кернел, вообще непонятно. И при таком уровне внимания/понимания вы хотите, чтобы я распинался перед вами "по существу"? Сейчас всё брошу и начну, да.
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	276. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Аноним (??) on 09-Мрт-11, 19:53
	Ядро на Хаскеле - это интересно... Уж оно-то будет отлично параллелизоваться, быть страшно оптимальным и типобезопасным, но я что-то не знаю осей на Хаскеле. Жааль
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	44. "Взлом Linux через подключение USB-устройства стал реальность..."	–17 +/–
	Сообщение от Толстый (ok) on 08-Мрт-11, 13:47
	хехе, красноглазое быдло заминусовало правильный пост. Не только строки но и массивы в целом в С - это epic fail. D к примеру сделал тоже все правильно, массивы представляют собой структуру, содержащую указатель и длину массива.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	53. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от Udzhen (ok) on 08-Мрт-11, 14:11
	Что Вам мешает написать собственную реализацию? Вот к примеру как выглядят строки в ядре Nt: typedef struct _UNICODE_STRING {     USHORT Length;     USHORT MaximumLength;     PWSTR  Buffer; } UNICODE_STRING; typedef UNICODE_STRING *PUNICODE_STRING;
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	81. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Толстый (ok) on 08-Мрт-11, 16:20
	> Что Вам мешает написать собственную реализацию? > Вот к примеру как выглядят строки в ядре Nt: > typedef struct _UNICODE_STRING { >     USHORT Length; >     USHORT MaximumLength; >     PWSTR  Buffer; > } UNICODE_STRING; > typedef UNICODE_STRING *PUNICODE_STRING; Вот именно, у каждого Васи своя реализация, несовместимая с реализацией Пети. А еще есть алгоритмы которые надо дублировать для контейнеров и строк.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	122. "Взлом Linux через подключение USB-устройства стал реальность..."	+2 +/–
	Сообщение от Udzhen (ok) on 08-Мрт-11, 18:52
	Ну так вперед! Докажите миру что Ваша реализация безопасней, быстрей и удобней! Все Вам только спасибо скажут...
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	129. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от коксюзер on 08-Мрт-11, 19:40
	> Ну так вперед! Докажите миру что Ваша реализация безопасней, быстрей и удобней! Всё уже реализовано и доказано. > Все Вам только спасибо скажут... Нет, "все" будут жаловаться на необходимость изучить новое, на непривычное, на отсутствие массового рынка труда, на Отсутствие Контроля и т.п.. Хотят есть кактус, пусть едят.
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	91. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от анон on 08-Мрт-11, 16:42
	> D к примеру сделал тоже все правильно, массивы представляют собой структуру, содержащую указатель и длину массива. Да, это помогает избежать сегфолта, разменивая его на логические ошибки, вот только их отлаживать еще труднее. Ну и результате имеем неустранимый оверхед на рантайм-проверку границ массива.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	106. "Взлом Linux через подключение USB-устройства стал реальность..."	–1 +/–
	Сообщение от коксюзер on 08-Мрт-11, 17:18
	>> D к примеру сделал тоже все правильно, массивы представляют собой структуру, содержащую указатель и длину массива. > Да, это помогает избежать сегфолта, разменивая его на логические ошибки, вот только > их отлаживать еще труднее. > Ну и результате имеем неустранимый оверхед на рантайм-проверку границ массива. Вы этот оверхед видели, замеряли, реализация таких проверок на ассемблере вам знакома, сравнительный анализ "оверхеда" с вычислением длин строк в средней программе на Си делали? Нет. Зато пафоса и апломба - вагон.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	114. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от анон on 08-Мрт-11, 17:58
	> Вы этот оверхед видели, замеряли, реализация таких проверок на ассемблере вам знакома, > сравнительный анализ "оверхеда" с вычислением длин строк в средней программе на > Си делали? Нет. А вы, простите, видели, что я делал а что нет?) Зато баттхерта и агрессии у вас - вагон)
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	134. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от коксюзер on 08-Мрт-11, 19:54
	>> Вы этот оверхед видели, замеряли, реализация таких проверок на ассемблере вам знакома, >> сравнительный анализ "оверхеда" с вычислением длин строк в средней программе на >> Си делали? Нет. > А вы, простите, видели, что я делал а что нет?) Вот я и спрашиваю: вы видели, делали? Если нет, к чему эти юления со смайликами? > Зато баттхерта и агрессии у вас - вагон) Батхёрт действительно есть, но не по вашей милости. Мне с поделиями на Си ещё работать и работать. Благо, не только с ними. Агрессии? Вы себе льстите.
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	148. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от анон on 08-Мрт-11, 20:37
	> Батхёрт действительно есть, но не по вашей милости. Мне с поделиями на > Си ещё работать и работать. Если вы такой умный и знаете как надо а как ненадо, почему работаете на работе, которая вызывает у вас баттхерт?
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	152. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от коксюзер on 08-Мрт-11, 20:42
	> Если вы такой умный и знаете как надо а как ненадо, почему > работаете на работе, которая вызывает у вас баттхерт? Потому что других ОС у рынка для меня нет.
	Ответить | Правка | ^ к родителю #148 | Наверх | Cообщить модератору

	202. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Аноним (??) on 09-Мрт-11, 02:06
	> Вот я и спрашиваю: вы видели, делали? Вы его не спрашивали, а предположили заранее. Надменность - не лучший способ доказать правоту.
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	206. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от коксюзер on 09-Мрт-11, 02:58
	>> Вот я и спрашиваю: вы видели, делали? > Вы его не спрашивали, а предположили заранее. Надменность - не лучший способ > доказать правоту. Не лучший, но любые попытки доказать правоту тут как правило тщетны (я уже пытался, в комментариях к другим новостям).
	Ответить | Правка | ^ к родителю #202 | Наверх | Cообщить модератору

	272. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от User294 (ok) on 09-Мрт-11, 19:14
	> сравнительный анализ "оверхеда" с вычислением длин строк в средней программе на > Си делали? Нет. Зато пафоса и апломба - вагон. Ну вон quicklz - одна и та же либа, при том авторами писаны реализации на сях, сишарпе и яве. Бенчмарки можно прямо на их же сайте и посмотреть. Почему-то ява и дотнет стабильно в 2.5 - 3 раза тормознее в этой задаче, несомненно критичной к скорости (либа позиционируется как чемпион по скорости). Наверное, рантайм проверки как раз и делают свое черное дело - подумал Штирлиц. Ну, алгоритм то реализуется одинаковый, блин?! И вообще, почему-то гуры от компрессии советуют начинающим, которые прутся с своими чудо-велосипедами на C# пойти выучить си++, если конечно те хотят чтобы их архивером кто-то еще и пользоваться бы стал хоть немного а параметры (время работы vs степень сжатия) стали бы сравнимы с архиваторами подобного типа. Это наверное вовсе не потому что разница в несколько раз появляется от простой замены сишарпа на си/си++, без изменения самого алгоритма. Ага... :)
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	275. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от paxuser (ok) on 09-Мрт-11, 19:45
	> Ну вон quicklz - одна и та же либа, при том авторами > писаны реализации на сях, сишарпе и яве. Бенчмарки можно прямо на > их же сайте и посмотреть. Почему-то ява и дотнет стабильно в > 2.5 - 3 раза тормознее в этой задаче, несомненно критичной к Значит и Ада сольёт в 3 раза. Тут к гадалке не ходи. В ней же строки тоже немутабельные, и рантайм-проверок(с)тм(r) полно. > то реализуется одинаковый, блин?! И вообще, почему-то гуры от компрессии советуют > начинающим, которые прутся с своими чудо-велосипедами на C# пойти выучить си++, Советуют, да. > если конечно те хотят чтобы их архивером кто-то еще и пользоваться Почему-то, ага. > бы стал хоть немного а параметры (время работы vs степень сжатия) > стали бы сравнимы с архиваторами подобного типа. Это наверное вовсе не > потому что разница в несколько раз появляется от простой замены сишарпа > на си/си++, без изменения самого алгоритма. Ага... :) Ну дык. Алсо, "язык программирования Ада" - сразу видно, что его делали мелкософт, оракл, RIAA, масоны и Гитлер. Будет тормозить, просить денег и зигу кидать, это ж очевидно.
	Ответить | Правка | ^ к родителю #272 | Наверх | Cообщить модератору

	55. "Взлом Linux через подключение USB-устройства стал реальность..."	+2 +/–
	Сообщение от анон on 08-Мрт-11, 14:31
	Кто вам мешает сделать struct my_str {     char *ptr;     size_t len; }; и писать надежно, безопасно, ънтерпрайзно(с)?
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	78. "Взлом Linux через подключение USB-устройства стал реальность..."	–4 +/–
	Сообщение от Толстый (ok) on 08-Мрт-11, 16:16
	ты очень умный, только почему тогда никто этого не сделал, а вместо этого мы имеем целый зоопарк реализаций контейнеров?
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	84. "Взлом Linux через подключение USB-устройства стал реальность..."	+2 +/–
	Сообщение от анон on 08-Мрт-11, 16:32
	> ты очень умный, только почему тогда никто этого не сделал, а вместо > этого мы имеем целый зоопарк реализаций контейнеров? Это сделала например майкрофост в MFC да и много где еще. Что значит "никто не сделал" и тут же "зоопарк реализаций"? Противоречишь сам себе.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	86. "Взлом Linux через подключение USB-устройства стал реальность..."	–3 +/–
	Сообщение от коксюзер on 08-Мрт-11, 16:34
	> Это сделала например майкрофост в MFC да и много где еще. > Что значит "никто не сделал" и тут же "зоопарк реализаций"? Противоречишь сам > себе. Ура, он противоречит сам себе! Наличие проблемы заретушировано претензиями к оппонентам! Всё замечательно!
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	242. "Взлом Linux через подключение USB-устройства стал реальность..."	–1 +/–
	Сообщение от Аноним (??) on 09-Мрт-11, 14:16
	> Ура, он противоречит сам себе! Наличие проблемы заретушировано претензиями к оппонентам! Всё замечательно! Проблема у тебя в голове.
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	85. "Взлом Linux через подключение USB-устройства стал реальность..."	–1 +/–
	Сообщение от коксюзер on 08-Мрт-11, 16:33
	> Кто вам мешает сделать > struct my_str { >     char *ptr; >     size_t len; > }; > и писать надежно, безопасно, ънтерпрайзно(с)? Литерал этого типа в студию, для начала.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	87. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от анон on 08-Мрт-11, 16:34
	> Литерал этого типа в студию, для начала. Что еще за "литерал типа"? В str указатель, в len длина строки, что непонятного?
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	101. "Взлом Linux через подключение USB-устройства стал реальность..."	–2 +/–
	Сообщение от коксюзер on 08-Мрт-11, 17:09
	>> Литерал этого типа в студию, для начала. > Что еще за "литерал типа"? > В str указатель, в len длина строки, что непонятного? С вами - всё предельно ясно.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	117. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от анон on 08-Мрт-11, 18:06
	> С вами - всё предельно ясно. Ок!
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	125. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от gegMOPO4 (ok) on 08-Мрт-11, 19:22
	struct my_str s = { "abc", 3 };
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	128. "Взлом Linux через подключение USB-устройства стал реальность..."	–2 +/–
	Сообщение от коксюзер on 08-Мрт-11, 19:36
	> struct my_str s = { "abc", 3 }; Ну вот, вычисление длины строки "на глазок" и ошибка на единицу в простейшем примере. Браво.
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	133. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от gegMOPO4 (ok) on 08-Мрт-11, 19:52
	Чтобы не морочить себе голову и не ошибиться, можно использовать простой макрос. #define MY_STR(L) { L, sizeof(L)-1 } struct my_str s = MY_STR("abc");
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	136. "Взлом Linux через подключение USB-устройства стал реальность..."	–2 +/–
	Сообщение от коксюзер on 08-Мрт-11, 20:06
	> #define MY_STR(L) { L, sizeof(L)-1 } > struct my_str s = MY_STR("abc"); Это феерический мрак. sizeof(L) вернёт количество элементов в массиве, включая терминирующий '\0'. У len тип size_t, и хранит он размер массива, а не индекс последнего элемента. Единицу зачем отнимаете?
	Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

	142. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от gegMOPO4 (ok) on 08-Мрт-11, 20:28
	Что вас удивляет? Что строковые литералы в Си неявно содержат терминирующий NUL? Что поэтому sizeof строкового литерала на 1 больше длины строки?
	Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

	149. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от коксюзер on 08-Мрт-11, 20:37
	> Что вас удивляет? Что строковые литералы в Си неявно содержат терминирующий NUL? > Что поэтому sizeof строкового литерала на 1 больше длины строки? Меня удивляет, что в ответ на замечание об ошибке на единицу вы написали эквивалентный по семантике макрос, а на тему "индекс последнего элемента vs. размер массива" начинаете "недоумевать" только сейчас. Особенно это странно в колее разговора о strl-функциях, коим в size передаётся размер массива, включая '\0', в чём и заключается их главное отличие от strn-функций. И честно говоря, я уверен, что сейчас вы просто отмазываетесь, не желая признать за собой типичную ошибку.
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

	159. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от gegMOPO4 (ok) on 08-Мрт-11, 20:54
	Я написал, как избежать ошибки в подсчёте числа символов. Да, теперь я вижу в чём была ваша ошибка -- вы почему-то считаете, что длина строки на единицу больше количества символов, содержащихся в ней. Функции strl* принимают размер буфера, который содержит строку и терминирующий NUL. Его размер должен быть по крайней мере на единицу больше предполагаемой длины строки.
	Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

	166. "Взлом Linux через подключение USB-устройства стал реальность..."	–1 +/–
	Сообщение от коксюзер on 08-Мрт-11, 21:20
	> Я написал, как избежать ошибки в подсчёте числа символов. Да, теперь я Какой ошибки? Давайте по порядку. Если следовать вашей логике, по которой в len показанного структурного типа должна записываться длина строки без учёта '\0', то мой комментарий, на который вы ответили, был ошибочен весь. Если так, вы могли бы мне возразить, предположив, что автор структурного типа предлагает хранить в len именно длину строки. Но вы этого не сделали. Вы предложили семантически эквивалентный макрос, который, по вашим словам, помог бы "избежать ошибки в подсчёте числа символов". То есть, прочитав мой комментарий, вы согласились с наличием ошибки в приведённом литерале... Которую теперь не считаете ошибкой? Так была ли ошибка? Вот эта непоследовательность и склоняет меня к мысли, что вы просто юлите. > вижу в чём была ваша ошибка -- вы почему-то считаете, что > длина строки на единицу больше количества символов, содержащихся в ней. Нет. Я считаю, что в len должен храниться размер массива символов, включая '\0', поскольку в операциях со значениями размеров строк без учёта '\0' чаще допускаются ошибки. И авторы strl-функций со мной согласны. К тому же, терминирующий нуль - анахронизм, мешающий применять wide-кодировки с символами постоянной длины, содержащими нулевые байты. > Функции strl* принимают размер буфера, который содержит строку и терминирующий NUL. Его > размер должен быть по крайней мере на единицу больше предполагаемой длины > строки. По-моему, теперь вы делаете вид, что терминирующий '\0' не является частью строки в Си: "строку и терминирующий NUL" - если это ваша изначальная точка зрения, то почему она такая противоречивая и идёт в разрез со стандартной терминологией?
	Ответить | Правка | ^ к родителю #159 | Наверх | Cообщить модератору

	181. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от gegMOPO4 (ok) on 08-Мрт-11, 22:39
	Признаюсь, я неправильно понял ваш первый комментарий. Показалось, что вы намекаете на возможность ошибки в такой записи. То, что вы будет оспаривать, что длина строки из трёх символов равна трём, мне и в голову не пришло. Да, ваш комментарий ошибочен весь. > Нет. Я считаю, что в len должен храниться размер массива символов, включая '\0', поскольку в операциях со значениями размеров строк без учёта '\0' чаще допускаются ошибки. И авторы strl-функций со мной согласны. Это исключительно ваши личные убеждения. И авторы strl-функций с вами не согласны -- третий аргумент называется size, а не len. Не говоря уже о том, что ASCIIZ-строки к данному представлению вообще не имеют отношения. > К тому же, терминирующий нуль - анахронизм, мешающий применять wide-кодировки с символами постоянной длины, содержащими нулевые байты. Да, и поэтому при представлении строки как указателя на массив символов и длины он не нужен. > По-моему, теперь вы делаете вид, что терминирующий '\0' не является частью строки в Си: "строку и терминирующий NUL" - если это ваша изначальная точка зрения, то почему она такая противоречивая и идёт в разрез со стандартной терминологией? Да не является. NUL не часть строки в Си, а ограничивающий её символ. Моя точка зрения вполне последовательна и согласуется со стандартной терминологией, как Си, так и общекомпьютерной.
	Ответить | Правка | ^ к родителю #166 | Наверх | Cообщить модератору

	196. "Взлом Linux через подключение USB-устройства стал реальность..."	–1 +/–
	Сообщение от коксюзер on 08-Мрт-11, 23:43
	> Признаюсь, я неправильно понял ваш первый комментарий. Показалось, что вы намекаете на > возможность ошибки в такой записи. То, что вы будет оспаривать, что > длина строки из трёх символов равна трём, мне и в голову К чему эти абсурдные инсинуации? Вы прекрасно понимаете, что я имел ввиду. В len должен храниться размер массива символов с терминирующим '\0', точка. > не пришло. Да, ваш комментарий ошибочен весь. С вашей точки зрения. С моей, структурный строковый тип без нуль-терминации - ни с чем не совместимый нонсенс, который способствует ошибкам переполнения на единицу и создаёт неадекватные трудности при работе с библиотечными функциями, которые принимают нуль-терминированные строки. > Это исключительно ваши личные убеждения. И авторы strl-функций с вами не согласны > -- третий аргумент называется size, а не len. Не говоря уже Они со мной "не согласны" только в названии аргумента, а вы просто юлите. > о том, что ASCIIZ-строки к данному представлению вообще не имеют отношения. К какому данному представлению? К структурному? В параллельном мире могут не иметь, а в реальном, если вы делаете свой, более безопасный строковый тип, потрудитесь обеспечить простоту его применения при работе с библиотеками. Жду возражений! >> К тому же, терминирующий нуль - анахронизм, мешающий применять wide-кодировки с символами постоянной длины, содержащими нулевые байты. > Да, и поэтому при представлении строки как указателя на массив символов и > длины он не нужен. Я хотел сказать, что реализовать строковый структурный тип, совместимый и с wide-кодировками, и с нуль-терминированными строками в Си практически невозможно. Но меня интересует другое. Вы что, считаете, что структурный строковый тип не должен быть совместим с нуль-терминированными строками? > Да не является. NUL не часть строки в Си, а ограничивающий её > символ. Моя точка зрения вполне последовательна и согласуется со стандартной Нулевой байт не является частью нуль-терминированной строки, я вас правильно понял? > терминологией, как Си, так и общекомпьютерной. Можете назвать источник такой терминологии, что-нибудь для примера?
	Ответить | Правка | ^ к родителю #181 | Наверх | Cообщить модератору

	233. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от arturpub (ok) on 09-Мрт-11, 11:14
	В len обычно хранят длину строки, а размер массива обычно называют size. Для примера: strlen("abc") == 3, хотя sizeof("abc") == 4. Т.о. хоть нулевой символ и является частью строки, считается, что в ее длину он не входит. По-моему, именование len vs size вполне естественно и интуитивно понятно. Существуют и необычные случаи, но для меня очевидно, что предложенная структура подразумевает хранение ASCIIZ и ее длины в терминах strlen().
	Ответить | Правка | ^ к родителю #196 | Наверх | Cообщить модератору

	256. "Взлом Linux через подключение USB-устройства стал реальность..."	–1 +/–
	Сообщение от коксюзер on 09-Мрт-11, 17:17
	> В len обычно хранят длину строки, а размер массива обычно называют size. > Для примера: strlen("abc") == 3, хотя sizeof("abc") == 4. Т.о. хоть Вы мне ещё букварь почитайте по слогам, в едином дидактическом порыве. > нулевой символ и является частью строки, считается, что в ее длину > он не входит. По-моему, именование len vs size вполне естественно и А по-моему, вполне естественно хранить не len, а size, независимо от его названия. Особенно, предлагая определение типа в контексте разговора о strl-функциях и проблеме со строками. Но я, кажется, понял, почему собеседники завели этот нелепый спор о совершенно вторичных названиях... > интуитивно понятно. Существуют и необычные случаи, но для меня очевидно, что > предложенная структура подразумевает хранение ASCIIZ и ее длины в терминах strlen(). И знаете, почему? Похоже, что безопасные строковые типы им в действительности не нужны. Почему не нужны - вопрос отдельный, но такое отношение позволяет им всерьёз рассуждать о структурном типе, не совместимом с ASCIIZ. И именно поэтому они выдвинули формальное решение, не удосужившись, похоже, даже представить, насколько оно жизнеспособно в реальном мире. Вам очевидно, что структурный тип должен хранить указатель именно на ASCIIZ-строку? Замечательно! Хоть кому-то очевидно.
	Ответить | Правка | ^ к родителю #233 | Наверх | Cообщить модератору

	286. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от arturpub (ok) on 10-Мрт-11, 13:12
	> Вы мне ещё букварь почитайте по слогам, в едином дидактическом порыве. Вы просили пример, вот я и подумал, что созвучия разбудят вашу интуицию. > И знаете, почему? Похоже, что безопасные строковые типы им в действительности не > нужны. Почему не нужны - вопрос отдельный, но такое отношение позволяет Ничего за них сказать не могу, может так, а может и эдак. Лично я не приверженец си/++, но от сожалений о том что "все идиоты" никто мудрее не станет, и писать что-то на стандартных сях ни у кого необходимости не отпадет. Поэтому необходимо, так сказать, знать врага в лицо и разговаривать на его языке; вовремя не отличил сайз от лена -- попал на буфер-оверфло или еще на что-нибудь. По мне так вообще печально, что я вместо компилятора выбираю битовые паттерны для своих данных.
	Ответить | Правка | ^ к родителю #256 | Наверх | Cообщить модератору

	290. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от paxuser (ok) on 10-Мрт-11, 18:58
	> Вы просили пример, вот я и подумал, что созвучия разбудят вашу интуицию. Не просил. Мне всё равно, как называется атрибут, главное - что он хранит. В случае массивов size и length вообще синонимы. > Лично я не приверженец си/++, но от сожалений о том что "все > идиоты" никто мудрее не станет, и писать что-то на стандартных сях Идиотами я никого не называл и не считаю. В банальных ошибках подозревал, но вариант с безразличием скорее всё расставил по местам.
	Ответить | Правка | ^ к родителю #286 | Наверх | Cообщить модератору

	299. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от arturpub (ok) on 11-Мрт-11, 11:42
	> Не просил. Мне всё равно, как называется атрибут, главное - что он > хранит. В случае массивов size и length вообще синонимы. Ну даете, блин.. ) зы: посоветуйте плиз что-нибудь из цикла "Ада за 3 дня не для тупых", я как-то брался, но тогда домашнего интернета в этой стране еще не было, а теперь времени не вагон.
	Ответить | Правка | ^ к родителю #290 | Наверх | Cообщить модератору

	300. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от paxuser (ok) on 11-Мрт-11, 12:08
	> Ну даете, блин.. ) Я изначально говорил о размерах массивов, а не длинах строк. Умеющий читать, да учёл. > зы: посоветуйте плиз что-нибудь из цикла "Ада за 3 дня не для > тупых", я как-то брался, но тогда домашнего интернета в этой стране > еще не было, а теперь времени не вагон. По 2005-ой есть хороший викибук: http://en.wikibooks.org/wiki/Ada_Programming Квадратные книги видел только по 95-ой, не проникся. Плюс RM не для тупых: http://www.adaic.org/resources/add_content/standards/05aarm/...
	Ответить | Правка | ^ к родителю #299 | Наверх | Cообщить модератору

	301. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от arturpub (??) on 11-Мрт-11, 17:07
	> По 2005-ой есть хороший викибук: http://en.wikibooks.org/wiki/Ada_Programming > Квадратные книги видел только по 95-ой, не проникся. Плюс RM не для > тупых: http://www.adaic.org/resources/add_content/standards/05aarm/... Сенкс, а то как раз пятница свободная выдалась.
	Ответить | Правка | ^ к родителю #300 | Наверх | Cообщить модератору

	144. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от анон on 08-Мрт-11, 20:29
	> Это феерический мрак. sizeof(L) вернёт количество элементов в массиве, включая терминирующий > '\0'. У len тип size_t, и хранит он размер массива, а > не индекс последнего элемента. Единицу зачем отнимаете? Если у вас есть голова, попробуйте воспользоватся ей. Тогда, может, дойдет, что именно из-за \0 и отнимаем единицу. Т.к. в нем нет нужды раз уж мы указываем длину строки. Если вы и так все знаете, к чему эти "покажите литералы" и т.п.? Хочецца посамоутверждаться?
	Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

	169. "Взлом Linux через подключение USB-устройства стал реальность..."	–3 +/–
	Сообщение от коксюзер on 08-Мрт-11, 21:35
	> Если у вас есть голова, попробуйте воспользоватся ей. Тогда, может, дойдет, что > именно из-за \0 и отнимаем единицу. Т.к. в нем нет нужды > раз уж мы указываем длину строки. В литерале '\0' в конце строки есть, почему в len он учитываться не должен? И правильно ли я вас понял, вы предлагаете сделать структурный строковый тип несовместимым с нуль-терминированными строками, работая с размерами по образу и подобию strn-функций? Какой оригинальный и жизнеспособный замысел! Алсо, ваш литерал с подсчётом количества символов на глазок - это смех и слёзы. Хоть бы макрос предложили, как другой товарищ тут. > Если вы и так все знаете, к чему эти "покажите литералы" и > т.п.? Хочецца посамоутверждаться? То есть, армия хамоватых ура-апологетов бездарного Си у меня не может вызывать иных эмоций, кроме желания самоутвердиться? Да вы по себе судите, неуважаемый.
	Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

	139. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от анон on 08-Мрт-11, 20:24
	Есть тут ошибка или нет, можно сказать только взглянув на функции, работающие с этой структурой.
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	141. "Взлом Linux через подключение USB-устройства стал реальность..."	–1 +/–
	Сообщение от коксюзер on 08-Мрт-11, 20:26
	> Есть тут ошибка или нет, можно сказать только взглянув на функции, работающие > с этой структурой. Я ждал этой отмазки, но она не катит, поскольку собеседник отвечал на моё замечание об ошибке на единицу. Его макрос совершает ровно ту же ошибку.
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	145. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от анон on 08-Мрт-11, 20:30
	> Я ждал этой отмазки, но она не катит, поскольку собеседник отвечал на > моё замечание об ошибке на единицу. Его макрос совершает ровно ту > же ошибку. Где там ошибка-то? Строка из 3 (трех!) элементов, нулл не нужен т.к. указываем непосредственно длину.
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	243. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Аноним (??) on 09-Мрт-11, 14:23
	>> Кто вам мешает сделать >> struct my_str { >>     char *ptr; >>     size_t len; >> }; >> и писать надежно, безопасно, ънтерпрайзно(с)? > Литерал этого типа в студию, для начала. my_str s = MY_STR("RTFM!");
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	59. "Взлом Linux через подключение USB-устройства стал реальность..."	+5 +/–
	Сообщение от СуперАноним on 08-Мрт-11, 14:48
	>EPIC FAIL C/C++ Попроси разработчиков ядра FreeBSD, пусть они его на жабе перепишут :))
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	60. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Sw00p aka Jerom on 08-Мрт-11, 14:50
	+1 чт оприкольно - они не хотят это изменять мол какая разница проверку сделает программист или данная проверка уже будет в самой функции - ГОВНО ПОДЕЛИЕ - нету уже доверие всяким стандартным библиотекам
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	94. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от анон on 08-Мрт-11, 16:47
	> чт оприкольно - они не хотят это изменять > мол какая разница проверку сделает программист или данная проверка уже будет в > самой функции - ГОВНО ПОДЕЛИЕ - нету уже доверие всяким стандартным > библиотекам Чем будет лучше, если библиотека проверит и обнаружит обращение за границы массива? Да, по сегфолту не упадем, но ошибка может аукнутся в другом месте.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	102. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от коксюзер on 08-Мрт-11, 17:10
	> Да, по сегфолту не упадем, но ошибка может аукнутся в другом месте. Действительно, ну чем DoS лучше полной компрометации? Да ничем.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	132. "Взлом Linux через подключение USB-устройства стал реальность..."	+2 +/–
	Сообщение от FFASM on 08-Мрт-11, 19:49
	Вот почему OpenBSD написали ядро на C и особых проблем не ощущают? На мой взгляд действует прицнип: новичёк, руки кривые? Не лесь в C/C++. Чем более низкоуровневый язык, тем больше он даёт свободы реализации алгоритма так, что бы он работал максимально быстро. К примеру на практически любом ассемблере есть множество инструкций, которые не имеют нормальных аналогов в C. Короч если руки кривые, предоставь возможность компилятору/инторпритатору следить за тобой.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	135. "Взлом Linux через подключение USB-устройства стал реальность..."	–1 +/–
	Сообщение от klalafuda on 08-Мрт-11, 19:55
	> Вот почему OpenBSD написали ядро на C и особых проблем не ощущают? Джо ты? Тебя так до сих пор и не поймали?
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	213. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от User294 (ok) on 09-Мрт-11, 05:00
	> Джо ты? Тебя так до сих пор и не поймали? Напишите востребованную ОС с непозорными параметрами на чем-то еще, фигле. Кто-то не дает?
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

	245. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от klalafuda on 09-Мрт-11, 15:05
	> Напишите востребованную ОС с непозорными параметрами на чем-то еще, фигле. Кто-то не дает? Зачем? Мне и линуксы вполне хватает.
	Ответить | Правка | ^ к родителю #213 | Наверх | Cообщить модератору

	140. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от коксюзер on 08-Мрт-11, 20:24
	> Вот почему OpenBSD написали ядро на C и особых проблем не ощущают? http://openbsd.org/images/hackathons/c2k10.gif > На мой взгляд действует прицнип: новичёк, руки кривые? Не лесь в > C/C++. Это пройдёт. > Чем более низкоуровневый язык, тем больше он даёт свободы реализации алгоритма так, > что бы он работал максимально быстро. К примеру на практически любом > ассемблере есть множество инструкций, которые не имеют нормальных аналогов в C. Скорость - не единственное требование к программам. К тому же, не все классы оптимизаций доступны компиляторам С/С++, дающим на выходе код с традиционным рантаймом. Например: http://morepypy.blogspot.com/2011/02/pypy-faster-than-c-on-c... > Короч если руки кривые, предоставь возможность компилятору/инторпритатору следить за > тобой. И много вы знаете совершенных людей с абсолютно прямыми руками, которые никогда не ошибаются?
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	185. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Аноним (??) on 08-Мрт-11, 22:50
	> классы оптимизаций доступны компиляторам С/С++, дающим на выходе код с традиционным > рантаймом. Да, да, да. JIT в теории может, блабла. На практике - а хрен там. Вот когда ядра, библиотеки и все остальное критичное к скорости будут писать на питонах, явах и прочих мегатормозилах - тогда и приходите.
	Ответить | Правка | ^ к родителю #140 | Наверх | Cообщить модератору

	203. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Аноним (??) on 09-Мрт-11, 02:13
	> Скорость - не единственное требование к программам. Почему микроядро еще не везде где можно? Почему ядра ОС, игры с графикой, рендеры, матсофт и т.п. не пишут на безопасных языках? (маргинальных примеров не надо)
	Ответить | Правка | ^ к родителю #140 | Наверх | Cообщить модератору

	208. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от коксюзер on 09-Мрт-11, 03:08
	>> Скорость - не единственное требование к программам. > Почему микроядро еще не везде где можно? > Почему ядра ОС, игры с графикой, рендеры, матсофт и т.п. не пишут > на безопасных языках? (маргинальных примеров не надо) А кто из крупных игроков на рынке стоит за этими микроядрами, безопасными языками, кто тратит ресурсы на создание и развитие инфраструктуры? Никто. А ядра ОС на безопасных языках пишут.
	Ответить | Правка | ^ к родителю #203 | Наверх | Cообщить модератору

	214. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от User294 (ok) on 09-Мрт-11, 05:12
	> А кто из крупных игроков на рынке стоит за этими микроядрами, Крупные игроки приходят когда видят что получилась нужная штука, лучше других, т.е. пахнет профитом. У микроядер своих проблем хватает и потому они остались нишевой штукой, а практически жизнеспособные системы почему-то сплошь и рядом монолиты да гибриды. > безопасными языками, Ну да, майкрософт и оракль - незначительные конторки с их явами и дотнетами. Мелочевка. > кто тратит ресурсы на создание и развитие инфраструктуры? Никто. Ну так тратьте. Линух вон сперва вылез из грязи в князи, а потом крупные игроки пришли. А вы хотите чтобы за вас кто-то что-то делал. А оно этим кому-то надо - делать то что надо ВАМ а не ИМ? :) > А ядра ОС на безопасных языках пишут. Да, а еще 100500 лет про микроядра орали, да толку то?
	Ответить | Правка | ^ к родителю #208 | Наверх | Cообщить модератору

	218. "Взлом Linux через подключение USB-устройства стал реальность..."	+2 +/–
	Сообщение от коксюзер on 09-Мрт-11, 05:58
	> Крупные игроки приходят когда видят что получилась нужная штука, лучше других, т.е. > пахнет профитом. У микроядер своих проблем хватает и потому они остались > нишевой штукой, а практически жизнеспособные системы почему-то сплошь и рядом монолиты > да гибриды. Ага, это даже доказательства не требует. Оно же очевидно. >> безопасными языками, > Ну да, майкрософт и оракль - незначительные конторки с их явами и > дотнетами. Мелочевка. Ну да, тред можно не читать, главное - к знакомы словами прицепиться и ляпнуть что-нибудь. >> кто тратит ресурсы на создание и развитие инфраструктуры? Никто. > Ну так тратьте. Линух вон сперва вылез из грязи в князи, а Ну так трачу, представьте себе. > потом крупные игроки пришли. А вы хотите чтобы за вас кто-то Да, хочу. > что-то делал. А оно этим кому-то надо - делать то что > надо ВАМ а не ИМ? :) Больше капса, больше смайликов, вы не стесняйтесь. Главное ведь - забыть, что я отвечал на чужой вопрос, а не в жилетку плакался. >> А ядра ОС на безопасных языках пишут. > Да, а еще 100500 лет про микроядра орали, да толку то? Дофига толку. Самолёты на них работают, ракеты, космические корабли, судоходство и прочая промышленность, телекомы. Но это всё х#ита, конечно же. На ведь писюках нет? Нет. Ну и слив защитан мне, да. P.S. И кагбе можно даже не замечать, что за микроядра я не агитировал. Не это ведь в троллинге главное, ага.
	Ответить | Правка | ^ к родителю #214 | Наверх | Cообщить модератору

	253. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от User294 (ok) on 09-Мрт-11, 16:58
	> Ага, это даже доказательства не требует. Оно же очевидно. Хорошо, ну так крупные игроки добровольно  (!!!) выбрали то что им пришлось по вкусу. А вы, собссно, кто чтобы с кого-то что-то требовать с нахрапом? Если вы полагаете что сможете лучше - докажите делом, тогда, может быть, и остальные подтянутся. Если, конечно, их понятия о "лучше" совпадут с вашими (что совсем не факт, но шансы есть). А если вы будете указывать другим как и что им следует делать - они как максимум не очень вежливо оббъяснят вам куда вам следует пройти. > Ну да, тред можно не читать, Да вы тут гранд-мастеры троллинга :) надо ж столько флуда вывалить из-за одной тупой уязвимости в драйвере, которая эксплуатируется путем вырезания гланд через жопу автогеном, пардон. Но ведь реальная опасность дыры ("наиболее элитные перцы с наклонностями шпионов может и поимеют десяток-другой локалхостов") - это ж не важно, да? Главное поистекать говном какой плохой си, какие пи...сы на нем пишут столь парашные операционки и прочая. Я вижу ровно 1 проблему: вы забыли предложить миру вашу операционку, лучше. Без сей и пи...сов, зато с шахматами и поэтессами. Поэтому все как лохи и лузеры пользуются тем что есть и работает. Достаточно неплохо работает. Не идеально, но свои задачи выполняет. А идеального софта почему-то вообще не бывает :) > главное - к знакомы словами прицепиться и ляпнуть что-нибудь. А эти слова случайно были не "си", "Linux" и "уязвимость"? Ну или какого тут поднялся такой многостраничный троллинг? :) > Ну так трачу, представьте себе. Я рад за вас, все дела. Вам надо - вы и упираетесь, все честно. А в лично моем понимании, надежная система должна быть прежде всего простой как топор. Товарисч D. J. Berstein вон делом доказал что на си можно написать надежную программу. Кстати его понятия о надежности вообще не привязаны к языку - он вообще рассмотрел надежность программ, причины багов (в частности, проблем секурити) и как можно минимизировать оные. Почему-то ему си при этом нифига не помешал. В этом плане современное железо с даташитами на сотни страниц а то и больше - оставляет желать лучшего, вообще-то. В нем тоже багов - есть. >> потом крупные игроки пришли. А вы хотите чтобы за вас кто-то > Да, хочу. Хотеть не запретишь. Хотите себе. Имхо долго и не факт что успешно будете хотеть. > я отвечал на чужой вопрос, а не в жилетку плакался. А по стилю больше похоже на плач несмеяны. Добро пожаловать в реальный мир, мир акул бизнеса, костылей и подпорок. Простите пожалуйста что ваши кульные теоретические концепты которые где-то там в теории могли бы хорошо делать что-то, тут никому нафиг не нужны, никто за это не платит и прочая. Как максимум тут вы можете рассчитывать на ваш энтузазизм, голову и пару рук. Если сильно повезет - может сумеете сколотить команду единомышленников, а один из миллиона через ...цать лет может даже и найдет инвестора который купится на красивые спичи. Но это не гарантировано, а кроме того, акул-инвесторов не интересуют все эти ваши концепции, их интересуют конкретные результаты, которые профит приносят. А как оно там внутри сделано - им вообще насрать, вы прикиньте? :). И горе вам если вы сорвете сроки, не сможете сделать то что обещали и прочая - вазелина понадобится много. > Дофига толку. Самолёты на них работают, А конкретные модели самолетов - осилите? А то я читал как у какого-то из боингов сделано - там ни про какие микроядра почему-то ни звука. Зато звуки про резервирование, юзание 2 разных архитектур процессоров, реализацию 1 и того же алгоритма 2-я разными командами програмеров, на 2 разных языках + сравнение результата вычислений обоих компьютеров, етц, етц. Ну в общем чтобы не могла возникнуть ситуация когда оба компьютера словят синхронно один и тот же баг и он останется не замечен, возможно с достаточно неприятными последствиями. Вот это я понимаю - чуваки настроены на то чтобы баги не пролезли + автоматическое обнаружение оных. Я также в курсе систем которые голосуют на уровне железа по принципу "2 из 3" например, так что бажный модуль может быть вычислен. > ракеты, космические корабли, Почему-то в них обычно стараются применять довольно примитивные процессоры. Наверное потому что радиация и все такое, а чем сложнее проц - тем он нежнее к таким вещам и более склонен к сбоям, в нем более вероятны ошибки и прочая (никогда не пробовала почитать Errata на современные процы? Там жесткач полнейший, только его видят сильно некоторые :D). А на простом проце - обычно крутится нечто сильно кастомное, под задачу. У простого проца пардон даже системы деления привилегий может не быть. Ну и накукуй там микроядра? Там обычно простая как топор фирмварина которая выверена до битика и делает свою задачу. > судоходство и прочая промышленность, телекомы. Ой, почему-то в реально критичных к отказу местах стоят простые чипы, быстро реагирующие на события, а желательно и вообще аппаратные защиты, т.к. софт и 100% надежность - очень трудносовместимые понятия. Простые - потому что чем сложнее чип, тем он глючнее, менее предсказуем, в нем больше багов (да, в чипах тоже бывают баги, google://Errata если что). У простого чипа - и фирмварина простая как топор. Собссно микроядро - всего лишь выносит сложность из ядра в другие куски системы, а в целом сложность системы особо не падает. Как максимум можно собрать простую систему которая ничерта не умеет. Только что с ней потом делать на серверах и прочая? Ну, я знаю ровно 1 применение на серверах и десктопах: назвать это гипервизором и изолировать друг от друга более сложные ОС. Но сложность систем никуда не девается и баги остаются, ессно, просто они изолированы и локализованы :) > Но это всё х#ита, конечно же. На ведь писюках нет? А знаете, если вы въе в стену на вашем авто и надо срочно вам подушку безопасности надуть, чтоб вы не выпорхнули в стекло и не размазались по стене - почему-то надувать ее, спасая вашу жо, будет в общем случае примитивный проц-"таракан" с датчиком и с не менее примитивной фирмвариной, чуть ли не единственной целью существования которого является именно это действо. И фирмварина примитивна и вылизана до битика, потому что если юзер вылетит в лобовое стекло - как-то нехорошо получится, да? А отсуствие многозадачности намекает на то что не надо ни защищаться от остальных задач, ни делить с ними время. Сложность системы падает в десятки раз. Вот тогда уже начинает идти разговор о какой-то там надежности решений, частью которых является софт. А пишут этот софт почему-то на асме и сях. Таких небезопасных, пля... > Нет. Ну и слив защитан мне, да. Слив вам засчитан за то что существует например уйма мелких процов в критичных к отказу местах ... запрограмленых на этих самых жутко небезопасных сях и асме. При том баги в фирмваре оных - скорее исключение чем правило. Потому что цена ошибки - соответствующая, и делается все возможное чтобы ошибок просто не было. Потому что внезапное надувание подушки без причины - как минимум очень неприятный сюрприз с риском для здоровья, а профукивание момента когда ее надо надуть - и вовсе может означать что юзер просто сыграет в ящик. > P.S. > И кагбе можно даже не замечать, что за микроядра я не агитировал. Угу, вы в основном просто набрасывали на вентилятор что линуксы - говно, си - отстой, только все это очень напоминает анекдот про цирк и "все клоуны - пи..сы!" :) > Не это ведь в троллинге главное, ага. Да уж! Так, глядя сколько тут натроллили из-за уязвимости которую можно поюзать только с спецжелезкой при физическом доступе к компу. Не, мне правда интересно, хотя-бы сотню компов на планете за следующие пару месяцев так сломают? :)
	Ответить | Правка | ^ к родителю #218 | Наверх | Cообщить модератору

	284. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от paxuser (ok) on 10-Мрт-11, 02:56
	Ооо, какая знатная простыня! И как же я тебя пропустил, дорогая... Сейчас накатаю ответную. >> Ага, это даже доказательства не требует. Оно же очевидно. > Хорошо, ну так крупные игроки добровольно  (!!!) выбрали то что им > пришлось по вкусу. А вы, собссно, кто чтобы с кого-то что-то > требовать с нахрапом? Если вы полагаете что сможете лучше - докажите А я с кого-то что-то требую? :) Нет. Но я догадываюсь, откуда растут ноги у таких упрёков: когда напоминаешь людям о недостатках их выбора/результатов работы/предмете обожания, они ищут хоть какой-то повод дать ответ по системе "сперва добейся" и "с чего вы взяли, что вам кто-то что-то обязан?". ;) Алсо, не хотите обосновывать, так и говорите. ;) > делом, тогда, может быть, и остальные подтянутся. Если, конечно, их понятия > о "лучше" совпадут с вашими (что совсем не факт, но шансы "Сперва добейся, потом критикуй!" (ц) ;) > есть). А если вы будете указывать другим как и что им > следует делать - они как максимум не очень вежливо оббъяснят вам > куда вам следует пройти. О, да! К "другим" даже с готовыми патчами обращаться - дело неблагодарное в большинстве случаев. Ибо политика + нежелание брать на себя труд по изучению и сопровождению кода "ради какой-то там безопасности". ;) > Да вы тут гранд-мастеры троллинга :) надо ж столько флуда вывалить из-за Дык! ;) > одной тупой уязвимости в драйвере, которая эксплуатируется путем вырезания гланд через > жопу автогеном, пардон. Но ведь реальная опасность дыры ("наиболее элитные перцы > с наклонностями шпионов может и поимеют десяток-другой локалхостов") - это ж > не важно, да? Главное поистекать говном какой плохой си, какие пи...сы Конечно, не важно. Троллинг начался с поста 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 >> Не это ведь в троллинге главное, ага. > Да уж! Так, глядя сколько тут натроллили из-за уязвимости которую можно поюзать > только с спецжелезкой при физическом доступе к компу. Не, мне правда > интересно, хотя-бы сотню компов на планете за следующие пару месяцев так > сломают? :) Да-да, именно из-за этой уязвимости. Других нет. ;)
	Ответить | Правка | ^ к родителю #253 | Наверх | Cообщить модератору

	184. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Аноним (??) on 08-Мрт-11, 22:47
	> EPIC FAIL C/C++. Имейте совесть! В вашей яве дыры безопасности чинят ДЕСЯТКАМИ в каждом релизе. Сначала перепишите вашу яву на ней самой а потом будете набрасывать. А то пилить сук на котором сидишь - это типичная изеновщина!
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	254. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от iZEN (ok) on 09-Мрт-11, 17:04
	>> EPIC FAIL C/C++. > Имейте совесть! В вашей яве дыры безопасности чинят ДЕСЯТКАМИ в каждом релизе. Пруф или не было! > Сначала перепишите вашу яву на ней самой а потом будете набрасывать. The Maxine Virtual Machine Project: http://labs.oracle.com/projects/maxine/ > А то пилить сук на котором сидишь - это типичная изеновщина! Чегоооо?
	Ответить | Правка | ^ к родителю #184 | Наверх | Cообщить модератору

	255. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Andrey Mitrofanov on 09-Мрт-11, 17:12
	>>> EPIC FAIL C/C++. >> А то пилить сук на котором сидишь - это типичная изеновщина! > Чегоооо? Он конечно же имел в виду, что ты ещё не дописал корректнес-прувер Си[++]-кода на своём Джавве, не доказал _его корректность и не прочекал свои обозаемые бизди коре^Wбеиз систем и джавве веэм. Ваш К.О.
	Ответить | Правка | ^ к родителю #254 | Наверх | Cообщить модератору

	232. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Аноним (??) on 09-Мрт-11, 11:01
	Ждём от тебя ОС на паскакале, а также компилятор умеющий все те же платформы и оптимизации что и хотя бы gcc.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	282. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Алексей (??) on 10-Мрт-11, 00:54
	Согласен. А Java не подходит для написания ядра операционных систем.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Взлом Linux через подключение USB-устройства стал реальность..."	+13 +/–
Сообщение от klalafuda on 08-Мрт-11, 11:57
Забавно но не более. Ядро - точно такой же обычный код как и любой другой, который пишут самые обычные люди. Имеющие право на ошибку. Нашли-исправили - ну и молодцы.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	71. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Аноним (??) on 08-Мрт-11, 15:47
	просто ошибок скорее всего много, усб драйвера писались не очень квалифицированными кадрами на отмашь
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	173. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Аноним (??) on 08-Мрт-11, 21:46
	А где не так?
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

5. "Взлом Linux через подключение USB-устройства стал реальность..."	–1 +/–
Сообщение от Аноним (??) on 08-Мрт-11, 11:59
> связанный с использованием для копирования содержимого строки небезопасной функции strcpy(), вместо учитывающего длину строки варианта strlcpy(). Мдееееееее
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
Сообщение от anonymous (??) on 08-Мрт-11, 12:06
Предупрежден - значит вооружен.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
Сообщение от balex (??) on 08-Мрт-11, 12:07
А почему бы ядру предварительно не "подравнять" строку идентификации устройства, а потом отдать драйверью на "самоидентификацию". Я так понимаю тот же udev вполне могбы это делать
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	17. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от тоже Аноним (ok) on 08-Мрт-11, 12:36
	> Я так понимаю тот же udev вполне могбы это делать И еще немножечко шить. Если вы хотите пользоваться системой, которая лучше программ и пользователя знает, что им нужно - могу подсказать один адресок... а то и не один...
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

15. "Взлом Linux через подключение USB-устройства стал реальность..."	+18 +/–
Сообщение от Анон on 08-Мрт-11, 12:29
Ого, таки к 2011 году они нашли способ как сломать линуху через "флешку" (типа утрирую) всего то нужно уметь программить контроллеры с поддержкой юсб, знать особенности некоторых драйверов встроенных в ядро или модулем к нему, понимать принцип инициализации железа в линукс. Очень легкий способ, прямо-таки виндовый авторан (а это уже сарказм). Опасно только для тех к чьему компу имеют доступ левые люди.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	20. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от caps on 08-Мрт-11, 12:46
	> Ого, таки к 2011 году они нашли способ как сломать линуху через > "флешку" (типа утрирую) всего то нужно уметь программить контроллеры с поддержкой > юсб, знать особенности некоторых драйверов встроенных в ядро или модулем к > нему, понимать принцип инициализации железа в линукс. Очень легкий способ, прямо-таки > виндовый авторан (а это уже сарказм). > Опасно только для тех к чьему компу имеют доступ левые люди. Ну да, в Иране тоже думали, что используя флешку и отключив авторан - все будет ок. Если у тебя нет паранои - это не означает что за тобой не наблюдают... А уязвимость уровня ядра - это всегда серьезно. Что еще раз подтверждает верный выбор архитектуры QNX для своей ОС.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	24. "Взлом Linux через подключение USB-устройства стал реальность..."	+3 +/–
	Сообщение от klalafuda on 08-Мрт-11, 12:54
	> А уязвимость уровня ядра - это всегда серьезно. Что еще раз подтверждает верный выбор архитектуры QNX для своей ОС. Вообще то это как бы ортогонально. Совершенно похрену, что именно пробивать: ядро или io-usb или как там его. Собственно, usb сервис в QNX4/6 пробить даже легче. В том плане, что, будучи обычным процессом, работая с ним нет необходимости изголяться с ядерными руткитами и пр. специфичными заморочками. Вполне достаточно штатных готовых решений коих в сети вагон с маленькой тележкой.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	52. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от user455 on 08-Мрт-11, 14:10
	так это просто говорит о том, что линукс стал популярнее, не более того. если бы надо было - нашли бы и 10 лет назад
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	89. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от коксюзер on 08-Мрт-11, 16:39
	> Ого, таки к 2011 году они нашли способ как сломать линуху через > "флешку" (типа утрирую) всего то нужно уметь программить контроллеры с поддержкой > юсб, знать особенности некоторых драйверов встроенных в ядро или модулем к > нему, понимать принцип инициализации железа в линукс. Очень легкий способ, прямо-таки > виндовый авторан (а это уже сарказм). Идите на Full-Disclosure и расскажите всем, как сложно, оказывается, адаптировать по чужим инструкциям чужие эксплойты для строковых переполнений в ванильном ядре. Все обрадуются и вздохнут с облегчением. > Опасно только для тех к чьему компу имеют доступ левые люди. Для хомячков неопасно, проблема надуманна, вопрос закрыт, ура.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	109. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от A1ek (ok) on 08-Мрт-11, 17:39
	интересно сработает уязвимость к виртуалке с проброшенным юсб
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	168. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от К.О. on 08-Мрт-11, 21:29
	Скорее, сработает еще в гипервизоре - ибо проброс допустим в том же ESXi осуществляется опосредованно, через Linux DOM0
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

	219. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от User294 (ok) on 09-Мрт-11, 05:59
	> Ого, таки к 2011 году они нашли способ как сломать линуху через > "флешку" (типа утрирую) всего то нужно уметь программить контроллеры с поддержкой > юсб, знать особенности некоторых драйверов встроенных в ядро или модулем к > нему, понимать принцип инициализации железа в линукс. Не, ну а что, плохо чтоли? Пока выпускают патч, куча двуногих отхватит экспериенса оптом в цифровой технике сразу в куче направлений :) 1) Как НЕ НАДО писать программы. Конкретный пример ошибки и к чему она ведет - почти как у немцев в ролике про технику безопасности с расчлененкой :) 2) ЮСБ и что внутри 3) Микроконтроллеры и их дружба с юсб. 4) Как оно с линухом взаимодействует. После получения таких знаний вы сможете, пардон, пойти и сделать свой Kinect или что там еще, с шахматами и поэтессами.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	234. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Аноним (??) on 09-Мрт-11, 11:39
	> Опасно только для тех к чьему компу имеют доступ левые люди. Ога, идешь так по ДЦ, хоп, стойка не закрытая - тык-вытык флеху и дальше идешь, а там уже доступ к тебе на мыло скидывается...
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	244. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Аноним (??) on 09-Мрт-11, 14:40
	>> Опасно только для тех к чьему компу имеют доступ левые люди. > Ога, идешь так по ДЦ, хоп, стойка не закрытая - тык-вытык флеху > и дальше идешь, а там уже доступ к тебе на мыло > скидывается... А видеокамер там типа нету?
	Ответить | Правка | ^ к родителю #234 | Наверх | Cообщить модератору

	249. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от User294 (ok) on 09-Мрт-11, 16:04
	> Ога, идешь так по ДЦ, хоп, стойка не закрытая - тык-вытык флеху Нормальный такой ДЦ, где посторонние могут безнаказанно тыкать ваш сервер.
	Ответить | Правка | ^ к родителю #234 | Наверх | Cообщить модератору

23. "Взлом Linux через подключение USB-устройства стал реальность..."	+2 +/–
Сообщение от strange (??) on 08-Мрт-11, 12:53
Реальность приблизилась к картине из боевика. :) Типа, в бункер проникает группа лиц высочайшей квалификации и 5 сек взламывает корпоративный кластер, втыкая в разъем такую штучку, похожую на флешку. Без перезагрузок и остановки сервера сливают нужные данные и благополучно (или нет) покидают место преступления. :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	25. "Взлом Linux через подключение USB-устройства стал реальность..."	+3 +/–
	Сообщение от klalafuda on 08-Мрт-11, 12:57
	> Реальность приблизилась к картине из боевика. :) Типа, в бункер проникает группа лиц высочайшей квалификации и 5 сек взламывает корпоративный кластер, втыкая в разъем такую штучку, похожую на флешку. Без перезагрузок и остановки сервера сливают нужные данные и благополучно (или нет) покидают место преступления. :) Вообще то, это сможет сделать даже уборщица. Будучи предварительно снабжена соответствующей 'флешкой'. Прошел мимо воткнул-выткнул зараза села пошел дальше. Какой уж там боевик..
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	27. "Взлом Linux через подключение USB-устройства стал реальность..."	+2 +/–
	Сообщение от strange (??) on 08-Мрт-11, 13:05
	Не, это конечно да.. Но с перестрелкой и спецэффектами веселее как-то. Не везде ведь уборщиц пускают в серверные. Да и шкафы закрыты.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	30. "Взлом Linux через подключение USB-устройства стал реальность..."	+2 +/–
	Сообщение от klalafuda on 08-Мрт-11, 13:11
	> Не, это конечно да.. Но с перестрелкой и спецэффектами веселее как-то. Не везде ведь уборщиц пускают в серверные. Да и шкафы закрыты. Не завидую админам, в серверные которых никогда не пускают уборщиц...
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	37. "Взлом Linux через подключение USB-устройства стал реальность..."	+2 +/–
	Сообщение от arachnid (ok) on 08-Мрт-11, 13:25
	в нашей серверной уборщиц не было лет 5. и почему Вы нам не завидуете?
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	41. "Взлом Linux через подключение USB-устройства стал реальность..."	+2 +/–
	Сообщение от klalafuda on 08-Мрт-11, 13:31
	> в нашей серверной уборщиц не было лет 5. и почему Вы нам не завидуете? Грязь же, нет? Разве что эта 'серверная' все пять лет была закрыта и работала абсолютно автономно и туда никто не заходил. В противном случае, грязь и пыль все равно заносится. А если посмотреть на вещи реалистичнее, то среднестатистические адмыны зачастую любят ещё и посидеть в этом адском месте, покурочить что-нить. Кваку погонять. Сутками. Ессно с кофем пивом чипсами печеньками и пр. Со всеми вытекающими (иногда на пол).
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	48. "Взлом Linux через подключение USB-устройства стал реальность..."	+4 +/–
	Сообщение от Demo (??) on 08-Мрт-11, 14:00
	>> в нашей серверной уборщиц не было лет 5. и почему Вы нам не завидуете? > Грязь же, нет? Раз в три месяца подмести и раз в пол-года помыть полы не так уж трудно. Если, конечно, туда не табунами ходят. Сначала уборщицу не пускали потому что в серверной на полу осталось много кабелей после переезда, сейчас валяющихся кабелей нет, всё закрыто в шкафах, но всеравно не пускаем, т. к. бабке трудно объяснить, что в воду нужно добавлять антистатик и менять в ведре воду 3 раза, а не размазывать грязной тряпкой ровным слоем пыль по всей площади.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	51. "Взлом Linux через подключение USB-устройства стал реальность..."	+4 +/–
	Сообщение от klalafuda on 08-Мрт-11, 14:08
	> Раз в три месяца подмести и раз в пол-года помыть полы не так уж трудно. Если, конечно, туда не табунами ходят. Сначала уборщицу не пускали потому что в серверной на полу осталось много кабелей после переезда, сейчас валяющихся кабелей нет, всё закрыто в шкафах, но всеравно не пускаем, т. к. бабке трудно объяснить, что в воду нужно добавлять антистатик и менять в ведре воду 3 раза, а не размазывать грязной тряпкой ровным слоем пыль по всей площади. Ну так нефик на чистоте экономить! Нужно брать бабушек с профильным ВО в звании не ниже капитана с соотв. допуском. И все будет ок.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	67. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от the joker (ok) on 08-Мрт-11, 15:33
	> Ну так нефик на чистоте экономить! Нужно брать бабушек с профильным > ВО в звании не ниже капитана с соотв. допуском. И все будет ок. Тогда уже лучше самому сообщить капитану рутовый пароль и пододвинуть удобное кресло.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	191. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Demo (??) on 08-Мрт-11, 23:16
	> Нужно брать бабушек с профильным ВО   Нужно. Но по поводу "брать" не ко мне. Я лишь винтик в огромной бюрократической машине. А на предлагаемую зарплату бабушки с профильным В/О идти что-то не хотят. Да и в этом году хотят направление офис-клининга отдать в аутсорсинг, вот тогда вообще дело "труба" будет (ИМХО). (Вспоминая _КАК_ рабочие подрядной организации устанавливали кондиционер, я с ужасом представляю что будут творить уборщицы...)
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	229. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от zazik (ok) on 09-Мрт-11, 09:35
	> А если посмотреть на вещи реалистичнее, то среднестатистические адмыны зачастую любят ещё > и посидеть в этом адском месте, покурочить что-нить. Кваку погонять. Сутками. > Ессно с кофем пивом чипсами печеньками и пр. Со всеми вытекающими > (иногда на пол). Играть в серверной? Брр, какой ужас, холодно, шумно, неудобно. Неужели не приятнее в уютном кабинете в любимом продавленном кресле с выставленным в "прохладу" кондиционером сидеть?
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	289. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от arachnid (ok) on 10-Мрт-11, 14:40
	>> в нашей серверной уборщиц не было лет 5. и почему Вы нам не завидуете? > Грязь же, нет? Разве что эта 'серверная' все пять лет была закрыта > и работала абсолютно автономно и туда никто не заходил. В противном > случае, грязь и пыль все равно заносится. > А если посмотреть на вещи реалистичнее, то среднестатистические адмыны зачастую любят ещё > и посидеть в этом адском месте, покурочить что-нить. Кваку погонять. Сутками. > Ессно с кофем пивом чипсами печеньками и пр. Со всеми вытекающими > (иногда на пол). ну вот нет грязи. в уличной обуви там никто не ходит, окон нет. не буду говорить, что на полу "можно есть", но и залежей пыли за шкафами или песка на полу не наблюдается. а уж про "посидеть"... - в серверной прохладно и очень шумно - что нифига не увеличивает желание поработать в оной :)
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	45. "Взлом Linux через подключение USB-устройства стал реальность..."	+2 +/–
	Сообщение от strange (??) on 08-Мрт-11, 13:52
	Вполне реально, почему нет. Пыли-грязи нет, потому как очистка воздуха и кондюшник. Серверная закрыта плотно, войти можно в сменной обуви и халате. Админы заходят чтоб диск в рейде поменять. Для экспериментов у них свое помещение есть. Ну а я не стану завидовать админам, которые кофе с печеньками на выдвинутом юните пьют. Описываю случай правильный и идеальный. В жизни действительно часто не так, но есть. Често, сам видел. Входил по пропуску. Парень со службы охраны так и мотался за нами, за дверями стоял. Хотя вроде ничего у них особенного такого и не было, инфы никакой. Узел коммутации на область.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	33. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от alf (??) on 08-Мрт-11, 13:14
	Ога, корпоративный кластер, на корпоративных кластерах этот модуль так необходим. >/lib/modules/2.6.*/kernel/sound/usb/caiaq/snd-usb-caiaq.ko
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	36. "Взлом Linux через подключение USB-устройства стал реальность..."	+3 +/–
	Сообщение от klalafuda on 08-Мрт-11, 13:21
	> Ога, корпоративный кластер, на корпоративных кластерах этот модуль так необходим. Ну если на то пошло, то на корпоративном кластере вообще очень необходимы ядра 2.6.37+ а особенно сегодня...
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	92. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от коксюзер on 08-Мрт-11, 16:44
	>> Ога, корпоративный кластер, на корпоративных кластерах этот модуль так необходим. > Ну если на то пошло, то на корпоративном кластере вообще очень необходимы > ядра 2.6.37+ а особенно сегодня... Других переполнений в других драйверах нет, да. А все кластеры работают на пересобранных ядрах без лишних драйверов и с отключённой поддержкой автозагрузки модулей, ага.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	177. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Michael Shigorin (ok) on 08-Мрт-11, 22:18
	Вы сперва доберитесь до USB на лезвии, угу.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

26. "Взлом Linux через подключение USB-устройства стал реальность..."	+4 +/–
Сообщение от Аноним (??) on 08-Мрт-11, 12:57
Короче это феерическая уязвимость в вакуме, все бы такие, массово эпидемию цервей и вирусов не вызовет, позволит в общем-то сломать хакеру один конкретный комп, то есть опасна в плане конкуренты подкупят уборщика что бы тот вставил спец устройство в сервер и слил секретную инфу, вопрос чего делает на сервере юсб порт открыт. Короче для серьезных систем серьезные уязвимости, так даже жить как-то интереснее.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

29. "Взлом Linux через подключение USB-устройства стал реальность..."	+4 +/–
Сообщение от ФФ (ok) on 08-Мрт-11, 13:09
Что делать, если я не использую этот драйвер caiaq? Что делать, как помочь потенциальному злоумышленнику?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	32. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от klalafuda on 08-Мрт-11, 13:13
	> Что делать, если я не использую этот драйвер caiaq? Что делать, как помочь потенциальному злоумышленнику? А его не нужно 'использовать'. Вполне достаточно, чтобы он присутствовал в системе. При появлении в порту соотв. устройства его поднимут автоматически.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	225. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от ФФ (ok) on 09-Мрт-11, 08:19
	"не использую" == "отсутствует в системе"
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	172. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от rocketman on 08-Мрт-11, 21:42
	Расскажи о методе терморектального криптоанализа
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

38. "Взлом Linux через подключение USB-устройства стал реальность..."	+5 +/–
Сообщение от Иван Иванович Иванов on 08-Мрт-11, 13:25
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.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	50. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от ram_scan on 08-Мрт-11, 14:05
	Уязвимость класса "а я сервак забутал и вместо инита шелл вписал" :-D Только сложнее делается. Железку надо паять, программизмом занимаццо...
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	68. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от the joker (ok) on 08-Мрт-11, 15:39
	> 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. Ну так даже дядя -- не мой! -- Билл сказал, что "если у злоумышленника есть физический доступ к вашему компьютеру, то это уже не ваш компьютер". А уж дядя Билл умеет впарить трояна.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	224. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Andrey (??) on 09-Мрт-11, 07:30
	> 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: ты можешь сам подключить подключить такое устройство. Вредоносное ПО для смартфонов -- это реальность.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

39. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
Сообщение от Аноним (??) on 08-Мрт-11, 13:27
Уязвимость — она, конечно, и в Африке уязвимость, но что-то мне кажется, что autorun.inf на обычной флешке гораздо более опасный, чем уязвимость в модуле ядра для которой нужно а) иметь вышеуказанный модуль в системе (да, tinycore вряд ли его имеет) б) иметь разрешение владельца компьютера всунуть в USB какую-то хреновину (не флешку!) в) иметь эту самую хреновину и запрограммировать ее нужным образом
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	43. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от segoon (ok) on 08-Мрт-11, 13:46
	После решения (в) обернуть устройство в корпус флешки не составит труда (б).
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	95. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от коксюзер on 08-Мрт-11, 16:51
	> Уязвимость — она, конечно, и в Африке уязвимость, но что-то мне кажется, > что autorun.inf на обычной флешке гораздо более опасный, чем уязвимость в > модуле ядра для которой нужно > а) иметь вышеуказанный модуль в системе (да, tinycore вряд ли его имеет) И какой процент линуксов идёт с такими ядрами? Никакой. > б) иметь разрешение владельца компьютера всунуть в USB какую-то хреновину (не флешку!) Это запросто. Оставить "флэшку" в курилке и прочая инженерия уже давно откровением не является. > в) иметь эту самую хреновину и запрограммировать ее нужным образом Сложно, но возможно. Особенно по чужим инструкциям, с эксплойтом на базе одного из фреймворков.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	138. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от segoon (ok) on 08-Мрт-11, 20:22
	> И какой процент линуксов идёт с такими ядрами? К примеру, в Owl вообще нет модулей ядра для звука, они там ни к чему.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	143. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от коксюзер on 08-Мрт-11, 20:28
	>> И какой процент линуксов идёт с такими ядрами? > К примеру, в Owl вообще нет модулей ядра для звука, они там > ни к чему. Я знаю. И какой процент у Owl? Никакой, хоть и незаслуженно.
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	221. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от User294 (ok) on 09-Мрт-11, 06:09
	> Это запросто. Оставить "флэшку" в курилке и прочая инженерия уже давно откровением > не является. Ой, анонимусы вон натянули конторку "безопасностью" методом инженерии без всяких флешек. Они спросили пасс на ссш и попросили выключить фаер. И главное им сказали пасс и вырубили фаер. И затрат сил в 100 раз меньше, и против идиотов - любая ОС бессильна. В итоге куча почты этой кульной конторки теперь вывалена в торентах и читается всеми желающими, конторка ощущает на себе как выглядит EPIC FAIL перерастающий в полярного лиса, ну а анонимусы явно отхватили EPIC WIN... настолько EPIC что вы даже с 10 флехами пожалуй такого не отхватите :)
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	97. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Аноним (??) on 08-Мрт-11, 16:58
	>в) иметь эту самую хреновину и запрограммировать ее нужным образом контроллер стоит около 3-5$, в корпус флешки умещается на раз, конечное устройство будет стоит не дороже 10$ поповоду программирования: для этих девайсов вагон и маленькая тележка примеров, в том числе усб. ну да, нужна некоторая изобретательность (как и всегда) чтобы всунуть вредноносный код, но это такое
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

40. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
Сообщение от А. Н. Оним on 08-Мрт-11, 13:28
>Драйвер caiaq, разработанный в рамках проекта ALSA для звуковых плат компании Native Instruments, входит в базовую поставку Linux-ядра и загружается автоматически в большинстве Linux-дистрибутивов, включая серверные системы. Зачем на серверной системе нужна звуковая плата (и вообще поддержка звуковых устройств)?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

42. "Взлом Linux через подключение USB-устройства стал реальность..."	+4 +/–
Сообщение от segoon (ok) on 08-Мрт-11, 13:33
Чтобы предотвратить загрузку драйвера: $ echo 0 > /sys/bus/usb/devices/usbX/authorized_default Documentation/usb/authorization.txt
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	164. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от crypt (??) on 08-Мрт-11, 21:11
	> Чтобы предотвратить загрузку драйвера: > $ echo 0 > /sys/bus/usb/devices/usbX/authorized_default > Documentation/usb/authorization.txt Сколько понаписали и только один человек догадался написать простое решение. Как вариант можно вообще составить список основных модулей ядра, а потом sysctl -w kernel.modules_disabled=1 p.s. У меня почему-то нет Documentation/usb/authorization.txt
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	165. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от segoon (ok) on 08-Мрт-11, 21:19
	> Сколько понаписали и только один человек догадался написать простое решение. Как вариант > можно вообще составить список основных модулей ядра, а потом >  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...
	Ответить | Правка | ^ к родителю #164 | Наверх | Cообщить модератору

	174. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от crypt (??) on 08-Мрт-11, 22:02
	Ответ оценил. Интересную штуку написал Инакий Перец-Гонзалес из Интел. :-) > В authorized в некотором смысле более жёсткое разграничение Скорее более гибкое и скриптовать больше. Но круто однозначно. Если уж размышлять дальше, то  может быть так, что ошибка будет в каком-нибудь "соседнем" модуле. Например, в драйвере ФС или еще каком-нибудь обработчике блочного устройства. В примере по ссылке эксплуатация уязвимости возможно в момент монтирования устройства для проверки. В первичном выступление парня из IBM что-то есть на тему, но подробно не помню, а пересматривать лень.
	Ответить | Правка | ^ к родителю #165 | Наверх | Cообщить модератору

	179. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от segoon (ok) on 08-Мрт-11, 22:23
	> Если уж размышлять > дальше, то  может быть так, что ошибка будет в каком-нибудь > "соседнем" модуле. Например, в драйвере ФС или еще каком-нибудь обработчике блочного > устройства. Уже размышляли и не раз.  Последний раз тут: http://www.openwall.com/lists/oss-security/2011/02/23/5 Проблема в том, что в стандартную модель безопасности не вписывается физический доступ к машине.  Практически все компоненты системы, работающие с устройствами, не ожидают некорректного ввода и практически не проверены на переполнения и пр.  Файловые системы, уровень блочного устройства, партишны, драйвера устройств - целей у атакующего довольно много. Единственная ИМХО существующая защита - это автоматическое монтирование флешки с nosuid,nodev, но этого, очевидно, недостаточно.
	Ответить | Правка | ^ к родителю #174 | Наверх | Cообщить модератору

	186. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от crypt (??) on 08-Мрт-11, 22:54
	Я верю, что не америку открыл, просто хотел сказать, что пишу одну теорию. Модель безопасности не учитывает физический доступ, вот как? (линк гляну позже) За родину обидно, будут теперь всякие подпорки делать. nosuid, nodev - имхо, совсем бесполезно. А еще эта новость про ошибку на уровне драйвера, а в видео от IBM все-таки в юзерспейсе убивали скринсейвер (тут я жду, когда полностью весь в дистрибутиве будет собираться с -fPIC и соотв. использовать ASLR).
	Ответить | Правка | ^ к родителю #179 | Наверх | Cообщить модератору

47. "Взлом Linux через подключение USB-устройства стал реальностью"	+/–
Сообщение от Yuriy (??) on 08-Мрт-11, 13:55
А новость писал чем-то обрадованный пользователь OpenBSD, исходя из имени правильной функции strlcpy()?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	57. "Взлом Linux через подключение USB-устройства стал реальностью"	+1 +/–
	Сообщение от klalafuda on 08-Мрт-11, 14:46
	> А новость писал чем-то обрадованный пользователь 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 может повлечь за собой наведенные ошибки уже совсем другого рода.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	74. "Взлом Linux через подключение USB-устройства стал реальностью"	+1 +/–
	Сообщение от nuclight (ok) on 08-Мрт-11, 15:54
	С критикой, конечно, нельзя не согласиться. А вот с тем, что на основании этой критики функцию не включают в стандартную библиотеку, согласиться уже никак нельзя. По, как минимум, двум причинам: 1) совместимость: strcat/strcpy, очевидно, куда опаснее, и тем не менее они всё же поддерживаются 2) не включать на основании "тупое использование повредит" - это не Unix-way подход, а виндовый. Для того, кто знает, что делает, возможность должна присутствовать. В конце концов, в ядре и glib она есть, а в glibc нету, с какой стати Дреппер считает себя умнее?..
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	75. "Взлом Linux через подключение USB-устройства стал реальностью"	–1 +/–
	Сообщение от klalafuda on 08-Мрт-11, 16:10
	> 1) совместимость: strcat/strcpy, очевидно, куда опаснее, и тем не менее они всё же поддерживаются Это - ANSI C. Плох он или хорош - это тем не менее стандарт. Так что - приходится. > 2) не включать на основании "тупое использование повредит" - это не Unix-way подход, а виндовый. Для того, кто знает, что делает, возможность должна присутствовать. В конце концов, в ядре и glib она есть, а в glibc нету, с какой стати Дреппер считает себя умнее?.. А почему собственно дядя Дреппер - глупее? Почему strlcpy есть в ядре - понятно. Уже готовые 3d party драйвера. Тут хочешь не хочешь, но включишь. Не до жиру. Почему в glib есть - тоже понятно. Туда какой только гадости не пихают - все, до чего руки дотянутся. Что тут удивляться.. А вот зачем пихать нестандартную и вызывающую вполне обоснованные нарекания strlcpy в стандартную, замечу, libc - это конечно большой вопрос. В конце-концов, если так хочется strlcpy - берите glibc и вперед, с песнею. Иначе уже завтра (злая) половина гнутых поделий будет обвешана такими мелкими 'стандартными' (в одной системе) хаками, как елка игрушками. Вот включат strlibc в ANSI C/POSIX - пожалуйста.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	96. "Взлом Linux через подключение USB-устройства стал реальностью"	+1 +/–
	Сообщение от коксюзер on 08-Мрт-11, 16:57
	> вызывающую вполне обоснованные нарекания strlcpy в стандартную, замечу, libc - это > конечно большой вопрос. В конце-концов, если так хочется strlcpy - берите > glibc и вперед, с песнею. Иначе уже завтра (злая) половина гнутых Glibc - единственная мейнстримная libc, в которой нет strl-функций.
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	105. "Взлом Linux через подключение USB-устройства стал реальностью"	+/–
	Сообщение от исчо_адын_аноним on 08-Мрт-11, 17:15
	> Glibc - единственная мейнстримная libc, Fixed
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	98. "Взлом Linux через подключение USB-устройства стал реальностью"	+1 +/–
	Сообщение от nuclight (ok) on 08-Мрт-11, 17:02
	>> 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 системах собираются только с напильником.
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	110. "Взлом Linux через подключение USB-устройства стал реальностью"	+1 +/–
	Сообщение от klalafuda on 08-Мрт-11, 17:43
	> А подумать? В стандарте оно до сих пор именно по причине совместимости. При чем здесь - подумать? Стандарт на libc есть? Есть. В стандарте strcpy & K присутствуют? Присутствуют. Пардон, но если реализация libc претендует на совместимость со стандартом она просто обязана их иметь. Не задавая ненужных вопросов на тему хорошие они или нет. Пусть каждый сам для себя решает - использовать ту или иную ф-ть предоставляемую *стандартной* libc или же не использовать. > Дядя Дреппер _считает_ себя умнее и вправе указывать другим. У него и других идиосинкразий хватает, впрочем, об этом лучше netch расскажет. Кроме glib, еще есть кеды, самба и rsync - они тоже идиоты гадость пихают, да? Ну и "готовые 3d party" - это ровно та же причина, совместимость. Приложений-то, чай, побольше с этой функцией будет, чем драйверов. Дядя Дреппер как бы не ананимус с лора. В отличие от он все-таки мейнтейнит ту самую glibc. И было бы очень странным, если бы он в свою очередь не имел права веского а то и решающего голоса. Равно как и права иметь своё, собственное, мнение на то, как и что должно включаться в его проект а что - нет. Не нравится? Используйте что-то другое, делайте своё, etc - не проблема. Существует достаточно большое количество систем в том числе популярных, в которых нет 'проблемы' в лице дяди Дреппера. Впрочем, в каждой из них есть уже свой дядя ровно с такими же правами вето и своими собственными тараканами в голове. Причем тут кеды, самба и рсинк я так и не понял. Если я не ошибаюсь, мы сейчас про strlcpy и glibc. Внутренности самбы сами по себе вызывают большие сомнения в адекватности разработчиков. Использовать strlcpy в кедах, имея на руках нормальный C++ в придачу с Qt - тоже. > На самом деле за позицией Дреппера совершенно явно торчат уши "оно придумано не нами, а в BSD" - иначе бы в обосновании была не идеологически-политическая хрень (а у *никсов, напомню, философия Tools, not policy), а гораздо более практичное "оно по-разному работает на BSD и солярке, чего нам выбрать-то?". Интриги заговоры разоблачения... Враги. Вокруг одни враги, это факт. > Вы, может быть, сильно удивитесь, но они _уже_ обвешаны хаками от одной системы, причем как бы уже не половина, а большинство софта написаны непортабельно, т.е. на отличных от Linux системах собираются только с напильником. То, что что-то обвешано хаками - это конечно же веский повод добавить ещё одну степень свободы. Чтобы уж до кучи.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	111. "Взлом Linux через подключение USB-устройства стал реальностью"	+1 +/–
	Сообщение от nuclight (ok) on 08-Мрт-11, 17:48
	klalafuda, вот не надо FUDа. В этом сообщении нет ни одного аргумента, одна херота. Ответить можно только на абзац о самбе: в приводившейся статье на википедии есть такое: "Many application packages and libraries include their own copies of these functions, including glib, rsync, Samba, KDE, and the Linux kernel itself."
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	115. "Взлом Linux через подключение USB-устройства стал реальностью"	+1 +/–
	Сообщение от klalafuda on 08-Мрт-11, 18:05
	> 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: С учетом того, что оппонент плавно перешел на матерную аргументацию своих мыслей, это ветку, я думаю, можно плавно закруглять.
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	120. "Взлом Linux через подключение USB-устройства стал реальностью"	–1 +/–
	Сообщение от nuclight (ok) on 08-Мрт-11, 18:23
	> то с ними. Но это явно не повод включать все это > хозяйство в стандартную libc. Содержимое которой в первую очередь регламентируется не > пожеланиями того или иного гения но вполне конкретным описанным стандартом. Хотите > расширений в любых мыслимых измерениях? Какие проблеме - используйте Это не аргумент, потому что расширения сверх стандарта в glibc присутствуют, и не так уж мало. Остальное - опять херня. > PS: С учетом того, что оппонент плавно перешел на матерную аргументацию своих > мыслей, это ветку, я думаю, можно плавно закруглять. Могу посоветовать посмотреть на Луговского.
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	180. "Взлом Linux через подключение USB-устройства стал реальностью"	+/–
	Сообщение от Michael Shigorin (ok) on 08-Мрт-11, 22:29
	> Могу посоветовать посмотреть на Луговского. 1) не стоит (я был против допущения его в ALT и свои разрушения там он нанёс); 2) тем более не стоит, что http://m-ike.livejournal.com/118340.html
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	307. "Взлом Linux через подключение USB-устройства стал реальностью"	+/–
	Сообщение от nuclight (ok) on 24-Май-11, 18:43
	>> Могу посоветовать посмотреть на Луговского. > 1) не стоит (я был против допущения его в ALT и свои > разрушения там он нанёс); > 2) тем более не стоит, что http://m-ike.livejournal.com/118340.html Михаил, я немного более в курсе ситуации с Луговским, чем большинство сторонних людей. Я с ним не раз переписывался лично. И про этот пост, разумеется, был в курсе, когда писал. Так вот, в контексте треда - не роляет совершенно.
	Ответить | Правка | ^ к родителю #180 | Наверх | Cообщить модератору

56. "Взлом Linux через подключение USB-устройства стал реальностью"	–1 +/–
Сообщение от Марат (??) on 08-Мрт-11, 14:44
А скажите мне не посвященному, какая проблема админу отключать и включать драйвер USB скриптом? Само собой включать по делу когда без этого никак? Домашним пользователям я думаю все это монопенисуально. Тем кому нужна защита аж прямо досмерти этого USB, втыкайте флешку в другой комп соединенный с первым по сети. Сейчас они стоят копейки Соответственно держите только один LAN порт открытым
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	58. "Взлом Linux через подключение USB-устройства стал реальностью"	+/–
	Сообщение от klalafuda on 08-Мрт-11, 14:47
	> А скажите мне не посвященному, какая проблема админу отключать и включать драйвер USB скриптом? Само собой включать по делу когда без этого никак? Домашним пользователям я думаю все это монопенисуально. Тем кому нужна защита аж прямо досмерти этого USB, втыкайте флешку в другой комп соединенный с первым по сети. Сейчас они стоят копейки Соответственно держите только один LAN порт открытым Ээээ... И что же должно стоять на этом, другом, компе? Что туда можно совершенно безопасно втыкать флешки?
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	65. "Взлом Linux через подключение USB-устройства стал реальностью"	+/–
	Сообщение от Марат (??) on 08-Мрт-11, 15:17
	> Ээээ... И что же должно стоять на этом, другом, компе? Что туда > можно совершенно безопасно втыкать флешки? Я понимаю что вы мне намекаете что второй комп тоже будет взломан с пом. этой тулзы по USB, а я хотел сказать, что взломаный линукс, не делает проблем с передачей файла через LAN на "чистый компьютер". Кроме того малый комп, я подчеркиваю, если все уже так очень сурово, может иметь линукс загружаемый с SD, карточки у которой стоит защелка на защиту от записи на саму эту SD. При перезагрузке вся хрень с малого компа умрет. Ну а если вирусятина делает невозможным работу малого компа, (хотя это редко когда было целью вирусописателей), то тот кто принес такую флешку, должен быть поимет. Чем не вариант?
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

66. "Взлом Linux через подключение USB-устройства стал реальность..."	–2 +/–
Сообщение от Zenitur (ok) on 08-Мрт-11, 15:26
Хы, прикол. Молодцы, развили всё-таки идею! Пользу людям сделали.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

70. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
Сообщение от Аноним (??) on 08-Мрт-11, 15:45
это же победа! /me достал свою плату на at91sam7s128 и пошел писать усб
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	211. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от User294 (ok) on 09-Мрт-11, 04:53
	> это же победа! > /me достал свою плату на at91sam7s128 и пошел писать усб И правда - победа :)). Попрактиковаться в програминге sam7 - всяко не вредно. Хотя cortex'ы уже актуальнее :P. Вот такое вот отличие: виндузятники матерятся на авторан и выгребают вири. А *никсоиды програминг юсб в микроконтроллерах осваивают :)). Так держать!
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	238. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от crypt (??) on 09-Мрт-11, 13:25
	>от такое вот отличие: виндузятники > матерятся на авторан и выгребают вири. M$ официально запатчил авторан.
	Ответить | Правка | ^ к родителю #211 | Наверх | Cообщить модератору

	258. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от User294 (ok) on 09-Мрт-11, 17:21
	> M$ официально запатчил авторан. Ага, не прошло и 20 лет как до них все-таки дошло, что у юзеров от этого оказывается вирусы бывают! А сколько там лет до этого вирусня автоматом попадала с mp3 плееров, фотоаппаратов и прочих флешек и винчей юзерам на компы? Заметьте, со стандартной флехи/фотоаппарата/плеера/прочего являющегося стандартным mass storage. Что "немного" серьезнее чем поимение системы путем создания кастомной железки. Ну вот и посмотрим, смогут ли пингвиноиды повторить такой антирекорд. Я готов поспорить что не смогут :)
	Ответить | Правка | ^ к родителю #238 | Наверх | Cообщить модератору

72. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
Сообщение от anthonio (ok) on 08-Мрт-11, 15:48
Если есть физический доступ к серваку, то и без всяких USB-приблуд можно получить root-доступ.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	76. "Взлом Linux через подключение USB-устройства стал реальность..."	+2 +/–
	Сообщение от uldus (ok) on 08-Мрт-11, 16:10
	> Если есть физический доступ к серваку, то и без всяких USB-приблуд можно > получить root-доступ. Без клавиатуры и монитора ??? И вероятность быть пойманным и замеченным при этом почти 100%. Попробуйте получить доступ к системе, пока сотрудник на 20 секунд отошел налить себе кофе или сделать ксерокопию. PS. Сдается мне, что strcpy там не случайно и об этой уязвимости уже давно кто нужно знал. Информация для размышления: http://hbgary.anonleaks.ch/greg_hbgary_com/21960.html
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	212. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от User294 (ok) on 09-Мрт-11, 04:56
	> PS. Сдается мне, что strcpy там не случайно и об этой уязвимости > уже давно кто нужно знал. Информация для размышления: http://hbgary.anonleaks.ch/greg_hbgary_com/21960.html Только планы спалили, дырки починят :) не так уж и плохо вроде? :)
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	260. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от User294 (ok) on 09-Мрт-11, 17:27
	ЗЫ кстати судя по планам конторы HBGary - у них там сплошные Наполеоны работают. Эх, анонимусы такое гнездо Наолеонов разогнали :).Они бы и дальше отжигали с своими требованиями из разряда "мы не знаем как это сделать но надо чтобы было зашибись, желательно по нажатию 1 большой кнопки".
	Ответить | Правка | ^ к родителю #212 | Наверх | Cообщить модератору

	239. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от crypt (??) on 09-Мрт-11, 13:30
	>>http://hbgary.anonleaks.ch/greg_hbgary_com/21960.html О! Сделали удобный просмотр! Я видать жираф и только что увидел.
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

123. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
Сообщение от devlink on 08-Мрт-11, 18:54
конечно большое IMHO, но все это очень смахивает на нормальный такой бэк-дор
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

137. "Взлом Linux через подключение USB-устройства стал реальность..."	–6 +/–
Сообщение от deadless (ok) on 08-Мрт-11, 20:15
даа зачетная такая дырень, слепить usb хреновину и по пути к своей циске  незаметно так воткнуть девайс в пару линупсовых сервачков самое оно. и что характерно User294 по обычаю в таких темах не отписывается, павлинтус тихо молчит в тряпочку, а Мишу Шигорина ваще не видать. Где вы поборники БЫСТРОГО линукса? по?й на дыры, главное же быстро! А учитывая последние тенденции разработчегов скрывать причины патчей, скоро можно ожидать разоблачения великого мифа линуксов как безопасных систем.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	150. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от botman (ok) on 08-Мрт-11, 20:38
	> скоро можно ожидать разоблачения великого мифа линуксов как безопасных систем вначале подождём пока ломающие драйвера появятся... а то что Линукс может работать даже на помойном аппаратном шлаке мы и без вас знаем
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	151. "Взлом Linux через подключение USB-устройства стал реальность..."	+1 +/–
	Сообщение от klalafuda on 08-Мрт-11, 20:42
	> и что характерно User294 по обычаю в таких темах не отписывается, павлинтус тихо молчит в тряпочку, а Мишу Шигорина ваще не видать. Где вы поборники БЫСТРОГО линукса? по?й на дыры, главное же быстро! Ващето сегодня, если конечно кто не заметил - 8е марта. Праздник типа на дворе. Что привязался к людям? Празднуют они. Как закончат - отпишутся. Хорошо если не с бодуна. Иначе пожалеешь, что вспомнил..
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	189. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от pavlinux (ok) on 08-Мрт-11, 23:02
	>> и что характерно 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); .... Пля, ломай не хочу :)
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	198. "Взлом Linux через подключение USB-устройства стал реальность..."	–3 +/–
	Сообщение от Michael Shigorin (ok) on 09-Мрт-11, 00:46
	Я день выступлений проституток, импортированный кларой цеткин, не праздную и другим не советую. А по заданному вопросу -- дырка и дырка, если у кого-то в типа trusted environment шатаются люди со своими девайсами и мимо камер их суют во включенные порты -- видимо, что-то недодумано.  Потому как с 1394 (которого на серверах пока не встречал вроде, правда) доступ к памяти хоста вообще является неотъемлемой фичей by design и никаким обновлением драйвера это не заткнуть, только отключением подсистемы.
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	200. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от коксюзер on 09-Мрт-11, 01:06
	Тут новость об эксплуатации ошибки, а не фичи. А доступ к памяти в том же 1394 по умолчанию в линуксе всегда была отключён, в отличие от винды.
	Ответить | Правка | ^ к родителю #198 | Наверх | Cообщить модератору

	235. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от deadless (ok) on 09-Мрт-11, 11:51
	> Я день выступлений проституток, импортированный кларой цеткин, не праздную и другим не > советую. ну да клара цеткин проститутка, один шигорин дартаньян, угу, nucliht мне открыл глаза на то кто ты есть на самом деле, впрочем я и не сомневался... > А по заданному вопросу -- дырка и дырка, если у кого-то в > типа trusted environment шатаются люди со своими девайсами и мимо камер > их суют во включенные порты -- видимо, что-то недодумано.  Потому > как с 1394 (которого на серверах пока не встречал вроде, правда) > доступ к памяти хоста вообще является неотъемлемой фичей by design и > никаким обновлением драйвера это не заткнуть, только отключением подсистемы. не юли, честно признай это дырень в линуксе, да в том самом линуксе на который всех денно и нощно агитируешь, рассказываешь всем что девелопить под другие ОС это %лядство, а девелопить в альте, в высшем обществе это королевская привелегия. Линукс стоит в сервере и солярка, или венда, или чпукс, этот факт никак не зависит от людей работающих в датацентрах. Ато получается если дырень в линуксе то значит нужно датацентр закрыть на замок, три слоя охраны и главное камер к каждому серваку натыкать. Как это у вас звучит? Если у вас что-то не работает то вам это не нужно. Линукс дыряв by design иначе бы не появлялись все эти SE-Linux (который большинство сразу вырубает), hardened версии и прочее. Торвальдс никогда не ставил безопасность во главу угла, его всегда устраивал уровень качества и безопасности линукса, поэтому аппелировать вы можете только к вашему кормчему, а не рассказывать тут сказки про людей в серверных.
	Ответить | Правка | ^ к родителю #198 | Наверх | Cообщить модератору

	257. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от коксюзер on 09-Мрт-11, 17:21
	> Линукс дыряв by design иначе бы не появлялись все эти SE-Linux (который > большинство сразу вырубает), hardened версии и прочее. Торвальдс никогда не ставил Как ярый пользователь Hardened Gentoo, подтверждаю. :) > безопасность во главу угла, его всегда устраивал уровень качества и безопасности > линукса, поэтому аппелировать вы можете только к вашему кормчему, а не > рассказывать тут сказки про людей в серверных. Всё так.
	Ответить | Правка | ^ к родителю #235 | Наверх | Cообщить модератору

	306. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Michael Shigorin (ok) on 15-Апр-11, 11:25
	> nuclight Прежде чем публично бросать тень на Вадима, подумайте о том, что неадекватность Вашего персонального восприятия может выйти ему боком.  А "открывать глаза" такому зоркому джо -- это, наверное, был тяжкий труд с учётом того, что я-то как раз пишу под своим именем и не скрываюсь. > не юли, честно признай это дырень в линуксе, да в том самом линуксе Это дырень в драйвере, который входит в комплект исходников ядра Linux и который может быть автоматически загружен, если был установлен на системе (плюс ещё ряд условий, часть которых можно подразумевать как обычно актуальные).  У меня на серверах с 2.6.18/32 модуля snd_usb_caiaq.ko не наблюдается.  Вы-то способны признать, что ляпнули от балды? > Ато Всё, по-русски писать не умеете -- следовательно, безграмотный; значит, и специалист бестолковый; отсюда нерелевантный спам в комментариях (да ещё и нецензурный); и что теперь -- расстреливать? Там дырку заткнут, Вам пояснят про раздельное написание "а то" -- и жизнь продолжится, что характерно. > получается если дырень в линуксе то значит нужно датацентр закрыть на замок, > три слоя охраны и главное камер к каждому серваку натыкать. Как это у вас звучит? (задумавшись) Похоже, проблемы с пониманием того, что физическая безопасность -- один из главных пунктов оценки ДЦ, и того, что от ОС может зависеть разве что время на вскрытие при наличии физического доступа.  Вы вообще в курсе, что такое датацентр? > Линукс дыряв by design Нет. > иначе бы не появлялись все эти SE-Linux (который большинство сразу вырубает), > hardened версии и прочее. Тоже нет. (вот только не рассказывайте, что ездите на работу на БТР, а там стоит отключенный от сети опёнок на альфе -- не-ве-рю) > Торвальдс никогда не ставил безопасность во главу угла Это да. > поэтому аппелировать вы можете Надеюсь, за прошедший месяц Вы всё-таки проспались.
	Ответить | Правка | ^ к родителю #235 | Наверх | Cообщить модератору

	190. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Аноним (??) on 08-Мрт-11, 23:03
	> даа зачетная такая дырень, Сэр, поищите тут посты некоего paxuser, он доступно рассказывал у кого как с дырками. В частности он очень низкого мнения о freebsd, и на то у него были причины. А те у кого с секьюрити хорошо - почему-то малопригодны для практического использования.
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	204. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от User294 (ok) on 09-Мрт-11, 02:35
	> даа зачетная такая дырень, Ну, расскажите тогда в какой системе таких дыреней нет и быть не может. Ну, наверное в MINIX какомнить, да? Там нет usb - нет и дыр в нем. Вариант. Для тех кому usb не нужен. Ну так это... можно и из линуха модули юсб вынести и запретить загрузку модулей на ходу. Хаксор обломается ничуть не меньше:) > слепить usb хреновину Да, процесс слепки - очевиден чтописец. Надо всего-то спаять собственную девайсину, прошить в нее собственную фирмвару, спасибо если не скурив еще половину немеряного талмуда спеков юсб, и вот тогда... тогда вы сможете при физическом доступе заюзать дырку. Которую заткнули в феврале, да :). Есть такое подозрение что пока вы сподобитесь - приедет апдейт, и... :) > и по пути к своей циске  незаметно так воткнуть девайс в пару линупсовых > сервачков самое оно. А есть уверенность что в остальных системах похожих ляпов нет? На самом деле проблема тут в том что современное железо - сложное. Вы вообще спеки USB видели? Это такой крутейший талмуд. Вы верите в возможность его реализации без багов? :) > и что характерно User294 по обычаю в таких темах не отписывается, Ну, отписался. А ты какую систему как образец секурности предлагаешь? OpenBSD? В которой нет поддержки уймы железа и с многопроцессорностью проблемы? Minix который вообще нифига не умеет? Или чего? Из реалистичных вариантов? > павлинтус тихо молчит в тряпочку, а Мишу Шигорина ваще не видать. Где > вы поборники БЫСТРОГО линукса? по?й на дыры, главное же быстро! Ну так дыры там запатчат быстрее чем вы успеете спаять и запрограмить железку для поимения, имхо. А потом как-бы уже и поздно :). Кстати, при физическом доступе к машине когда я могу кастомный девайс в юсб впихнуть - я могу и загрузиться с своей флехи, вероятно. После чего я получу полные права в совершенно любой системе :) > А учитывая последние тенденции разработчегов скрывать причины патчей, скоро можно ожидать > разоблачения великого мифа линуксов как безопасных систем. Ну тут некий товарисч paxuser или как там его правильно помнится крепко наподдал и FreeBSD в этом плане. А остальные как-то и не развиваются почти. Не, можно юзать minix какойнить. Если он конечно у вас вообще загрузиться сможет на реальном железе, а не где-то у академиков в виртуалочке. А юсб девайсы... нет фичи - нет проблем? Ну с таким подходом и линуховое ядро - типа секурно: выносите все лишние подсистемы, запрещаете загрузку модулей. Враг не пройдет :).
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	236. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от deadless (ok) on 09-Мрт-11, 12:14
	> Ну, расскажите тогда в какой системе таких дыреней нет и быть не > может. Ну, наверное в 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, это просто слёзы..
	Ответить | Правка | ^ к родителю #204 | Наверх | Cообщить модератору

	241. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от crypt (??) on 09-Мрт-11, 13:45
	> в OpenBSD ляпов секурного плана горааааздо меньше, что-то я не припоминаю, чтоб > еженедельно проблемы безопасности находили в опёнке. User-friendly Secure Functional Pick any two...
	Ответить | Правка | ^ к родителю #236 | Наверх | Cообщить модератору

	278. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от User294 (ok) on 09-Мрт-11, 22:34
	> Слишком много если. Ну, количество "если" потребное для успешного взлома линуха через этот баг не мешает некоторым троллить как я смотрю. А тут вдруг вас "если" засмущали. Странно :) > все сказанное выше отменяет дырень? Нет, не отменяет. Но ее реальная серьезность - почти на уровне плинтуса. Ну сломает пара десятков гиков свой локалхост. И? А товарисчи типа 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.dev/~paxuser а некоторые моменты относительно его точек зрения можно найти например примерно тут: http://www.opennet.dev/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. И если фря еще более-менее активировалась и взамен там баги гребут лопатой ("не ошибается тот кто ничего не делает") то опенок... ну в общем он весьма на любителя с такими темпами развития. Следующим шагом после установки опенка должен быть переезд в укрепленный подземный бункер. На всякий случай. А то что неудобно и ограничений много - ну извините, юзерам оного к геморрою все-равно не привыкать :)
	Ответить | Правка | ^ к родителю #236 | Наверх | Cообщить модератору

	279. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от deadless (ok) on 09-Мрт-11, 23:02
	спасибо юзер, день сегодня и так офигенный, солнышнко и все такое, и ты в очередной раз поднял настроение. :)) Респект и уважуха за своебразное чувство юмора. :)) Ссылки на пакса, почитаю как будет в следующий раз оказия с некоторым количеством свободного времени, чет как то не замечал его раньше. Ну и вобщем фигли спорить, все равно каждый останется на своём мнении, да вертолет собрали на линуксе, я им с бутстрапом децл помог, есть опыт в ковырянии всякого разного типа шыта типа wl500g, перепиливал ихние прошивки, и таки да в то время сидел на бубунте, плевался но сидел, ибо также не ищу геморой на свою %опу, теперь работа преимущественно с фрёй, потому сижу на фре, но сервера мантейню и фрёвые и рхеловые и федоровые и форточные, со всех бабло капает, что характерно практически одинаково :) есть маза пересеть на соляру, должен подвалить новый проект.. ЗЫ: не напрягайся :) писать уже нету больше сил, завтра ж на работу (с)
	Ответить | Правка | ^ к родителю #278 | Наверх | Cообщить модератору

	292. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от deadless (ok) on 10-Мрт-11, 23:53
	почитал я пакса твоего, на мое имхо просто больной причем на всю голову, либо работает в какойто сильно противозаконной сфере, мож 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 уязвимости. Как-то так.
	Ответить | Правка | ^ к родителю #278 | Наверх | Cообщить модератору

	293. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от paxuser (ok) on 11-Мрт-11, 00:58
	> почитал я пакса твоего, на мое имхо просто больной причем на всю А я здесь и всё вижу. ;) > один Фюрер ибн Торльвадс весь в белом. Да и вообще если По диагонали вы меня почитали-то, любезный.
	Ответить | Правка | ^ к родителю #292 | Наверх | Cообщить модератору

	294. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от iZEN (ok) on 11-Мрт-11, 01:18
	>> почитал я пакса твоего, на мое имхо просто больной причем на всю > По диагонали вы меня почитали-то, любезный. Я тоже тебя почитал. Ты больной на голову параноик. Лучше иди читай Криса Касперски в "Системном администраторе", он правильную мысль проводит: неуязвимых систем не бывает, и даже процессоры не защищены от ошибок выполнения.
	Ответить | Правка | ^ к родителю #293 | Наверх | Cообщить модератору

	295. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от paxuser (ok) on 11-Мрт-11, 01:48
	> Я тоже тебя почитал. Ты больной на голову параноик. Лучше иди читай И тоже по диагонали, с тем же результатом. > Криса Касперски в "Системном администраторе", он правильную мысль проводит: неуязвимых > систем не бывает, и даже процессоры не защищены от ошибок выполнения. Касперски не эксперт, мысль эта не его, и я её разделяю.
	Ответить | Правка | ^ к родителю #294 | Наверх | Cообщить модератору

	296. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от paxuser (ok) on 11-Мрт-11, 09:11
	> Как извесно техники аля 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 > уязвимости. Как-то так. Меньше знаешь - лучше спишь, ога.
	Ответить | Правка | ^ к родителю #292 | Наверх | Cообщить модератору

	297. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от deadless (ok) on 11-Мрт-11, 09:41
	> Бтв, что-то я в вашем надрывном потоке сознания не досчитался некоторой доли > этой "всей правды". Ну я процитирую, да. Ну и какой главный вывод? В том что фря сосёт, а линукс рулит? >> • 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 адрес вы уже знаете, сплойт у вас тоже есть, ломайте, я жду.
	Ответить | Правка | ^ к родителю #296 | Наверх | Cообщить модератору

	298. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от paxuser (ok) on 11-Мрт-11, 10:51
	> Ну и какой главный вывод? В том что фря сосёт, а линукс > рулит? Да, такой главный вывод. Написано же прямым текстом: фря сосёт. Вот тут: >>> – 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-ый класс пошли.
	Ответить | Правка | ^ к родителю #297 | Наверх | Cообщить модератору

	302. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от deadless (ok) on 11-Мрт-11, 23:03
	> Да, такой главный вывод. Написано же прямым текстом: фря сосёт. Вот тут: >>>> – 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 совместимое чудо-ядро на эрланге я пожалуй первым это попробую, удручает только то что небезопасный Си использовали при написании безопасного эрланга. Тоже как-то не стыкуется с вашей же теорией тотальной безопасности.
	Ответить | Правка | ^ к родителю #298 | Наверх | Cообщить модератору

	304. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от paxuser (ok) on 12-Мрт-11, 00:41
	> Я уже читал что 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 совместимое чудо-ядро на эрланге я ОС на эрланге - очередной плод вашей бурной инфантильной фантазии, разыгравшейся на почве диагонального чтения. > пожалуй первым это попробую, удручает только то что небезопасный Си использовали > при написании безопасного эрланга. Тоже как-то не стыкуется с вашей же > теорией тотальной безопасности. Уж с вашей теорией тотальной безопасности точно не стыкуется. А у меня всё складно да ладно.
	Ответить | Правка | ^ к родителю #302 | Наверх | Cообщить модератору

182. "Взлом Linux через подключение USB-устройства стал реальность..."	+4 +/–
Сообщение от Гентушник (ok) on 08-Мрт-11, 22:44
$ find /lib/modules/`uname -r`/ -name snd-usb-caiaq.ko -o -name iowarrior.ko $ Ну вот опять надо чего-то доставлять, собирать и паять для того чтобы поломать этот ваш линукс... Всё как не у людей!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	195. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от pavlinux (ok) on 08-Мрт-11, 23:40
	> $ 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.
	Ответить | Правка | ^ к родителю #182 | Наверх | Cообщить модератору

	223. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от Гентушник (ok) on 09-Мрт-11, 06:45
	> Модули ищутся через modprobe -an, через find это как-то по-слакваревски, > а настоящий Гентушник мегагерц бережёт!!! :) Спасибо, схоронил в памяти.
	Ответить | Правка | ^ к родителю #195 | Наверх | Cообщить модератору

	205. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от User294 (ok) on 09-Мрт-11, 02:39
	> Этот Daniel Mack, спеки ваще читает?! Мне вот интересно другое :). А *ты* осилил их целиком прочесть? И как тебе этот талмудец? :)
	Ответить | Правка | ^ к родителю #182 | Наверх | Cообщить модератору

	207. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от pavlinux (ok) on 09-Мрт-11, 03:07
	>> Этот Daniel Mack, спеки ваще читает?! > Мне вот интересно другое :). А *ты* осилил их целиком прочесть? И > как тебе этот талмудец? :) Ну я их давно изучал. Ща ковырнул, чтоб уж точно глянуть размер. А самом деле там много не нужно, для работы вполне хватает USB 1.1, ну а остальное это уже оптимизация.
	Ответить | Правка | ^ к родителю #205 | Наверх | Cообщить модератору

	217. "Взлом Linux через подключение USB-устройства стал реальность..."	+2 +/–
	Сообщение от User294 (ok) on 09-Мрт-11, 05:46
	> Ну я их давно изучал. Ща ковырнул, чтоб уж точно глянуть размер. И как, мозг не опух? :))). Для сравнения - иди вон драйвер UART какогонить заэйсплойть? ;) Там все просто слишком просто для того чтобы можно было эксплойтировать ремотно сам драйвер. Может, старина D.J. Berstein был не так уж и неправ, рассуждая о том как можно уменьшить число багов в софте? Самое веселое что его рассуждения никак не привязаны к ЯП и он умудрился написать несколько довольно секурных программ на обычном си :) > А самом деле там много не нужно, для работы вполне хватает USB > 1.1, ну а остальное это уже оптимизация. Не, ну понятно что если знаешь что долбить - достаточно в конкретное место доки глянуть. А если как скрипткидди - то и вообще думать не надо: взял в руки девайс - получил результат. Все, теперь ты кульхакер! Просто потому что умеешь втыкать девайс в разъем, во! :) А так - попрограммить сие в микроконтроллере - неплохая зарядка для мозга. Придет понимание некоторых сущностей с которыми работает юсб и как сие выглядит со стороны девайса, а полученные скиллы пригодятся для массы иных, более полезных применений. К сожалению, на это способен очень небольшой процент двуногих. Остальные почему-то слишком тупые :)
	Ответить | Правка | ^ к родителю #207 | Наверх | Cообщить модератору

	228. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от guest (??) on 09-Мрт-11, 09:32
	Что вы глупости такие спрашиваете? Если б он не то чтоб читал, а хотя бы посмотрел включив мозг, то глупостей про "а почему в ядре 80байт когда в доке 0xff" не писал бы (наверное)
	Ответить | Правка | ^ к родителю #205 | Наверх | Cообщить модератору

	240. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
	Сообщение от pavlinux (ok) on 09-Мрт-11, 13:41
	> Если б он не то чтоб читал, а хотя бы посмотрел включив  мозг, > то глупостей про "а почему в ядре 80байт когда в доке 0xff" не писал бы (наверное) Ну давай дальше, вместе посмеёмся.... подсказка: char[80], char[0xff]
	Ответить | Правка | ^ к родителю #228 | Наверх | Cообщить модератору

303. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
Сообщение от lucentcode (ok) on 12-Мрт-11, 00:16
Не страшно, можно сконфигурировать и собрать ядро без этого драйвера. А вот что делают в такой ситуации пользователи проприетарных ОС, лучше не думать:)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

305. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
Сообщение от Slot on 12-Мрт-11, 11:17
Аааааааа линух уязвим с любым ядром! ААааааа - я нашел уязвимость - это винчестер! Вот ....!!! Если перечислять все способы взлома при ФИЗИЧЕСКОМ доступе к серваку О_О а? Тут тогда страница не загрузится! Или физдоступа к серваку нет или из ядра все не нужные модули долой или вааще все :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

308. "Взлом Linux через подключение USB-устройства стал реальность..."	+/–
Сообщение от Аноним (??) on 05-Дек-11, 17:49
Народ, можно ли такой схемкой http://conture.by/post/347 запустить движок от веника? Спасибо за ответ.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема