В поставляемом в составе ядра Linux драйвере ozwpan (https://www.kernel.org/doc/readme/drivers-staging-ozwpan-README) выявлено пять уязвимостей (http://seclists.org/oss-sec/2015/q2/446), четыре из которых позволяют (http://seclists.org/oss-sec/2015/q2/432) инициировать крах или зацикливание ядра через отправку специально оформленных пакетов (packet-of-death). Первая (https://lkml.org/lkml/2015/5/13/740) и вторая (https://lkml.org/lkml/2015/5/13/744) проблемы связаны с выходом за границы буфера из-за некорректной обработки знаковых целых чисел, третья (https://lkml.org/lkml/2015/5/13/741) проблема вызвана условиями при которых выполняется деление на ноль, четвёртая проблема (https://lkml.org/lkml/2015/5/13/742) приводит к бесконечному зацикливанию, пятая (https://lkml.org/lkml/2015/5/13/739) проблема вызвана возможности чтения из областей вне границ выделенного буфера. Для демонстрации проявления уязвимостей подготовлены прототипы эксплоитов.
Опасность выявленных уязвимостей компенсирует достаточно специфичный характер драйвера ozwpan, который используется в редких случаях и имеет статус экспериментального (staging), а также необходимость отправки пакетов на канальном уровне в рамках одного сегмента локальной сети. Драйвер ozwpan предоставляет реализацию хост контроллера USB, в которой вместо физического подключения устройства, взаимодействие с периферией осуществляется через Wi-Fi. Драйвер может быть сопряжён с существующими беспроводными устройствами, совместимыми с технологией Ozmo Devices (Wi-Fi Direct). Метод работы сводится к преобразованию USB-команд в протокол второго уровня сетевой модели с последующей передачей в форме пакетов c типом (ethertype) 0x892e. Драйвер принимает такие пакеты, разбирает их и преобразует в функциональность USB.
URL: http://seclists.org/oss-sec/2015/q2/446
Новость: http://www.opennet.ru/opennews/art.shtml?num=42228
>В поставляемом в составе ядра Linux драйвереНу да. А когда выходит новость про GNU Hurd все начинают орать "фу-у-у-у, а зачем нам микроядро. И вообще..."
Эх вы...
Диванный теоретик такой теоретик.
> Диванный теоретик такой теоретик.По моим наблюдениям, в серебряные пули верят только глупые или наивные люди.
Ну в GNU Hurd нет драйвера ozwpan. Нет драйвера - нет проблемы -- так получается :)
Микро ядро разве крешится если драйвер слетел ? или тока в миниксе дрова в юзерспейсе?
Ну вот как можно было так обосраться?
Надо было писать: "новость про Hurd все начинают орать...". Потому, как, если бы для него был драйвер ozwpan, то он бы поставлялся в составе дистрибутива GNU. И уязвимость могла в нём случится.
И не надо рассказывать, что оно от пользователя работает. ботнету это пофигу.
Речь о том, что здесь крах в сетевой подсистеме ядра "кладет" всю систему.
Лично я довольно часто сталкивался с этим, когда звуковая / сетевая / графическая подсистемы падали и приходилось ребутать всю систему.
> Речь о том, что здесь крах в сетевой подсистеме ядра "кладет" всю
> систему.
> Лично я довольно часто сталкивался с этим, когда звуковая / сетевая /
> графическая подсистемы падали и приходилось ребутать всю систему.А почему? Потому что железяка зашла в режим, из которого уже не может выбраться без ресета. И при чём здесь ядро? Как в этом случае поможет драйвер работающий из юзерспейс? Даже при полном фризе после краха в intelHD можно зайти по ssh и любоваться в логи.
И вообще про падения сетевых драйверов и звука явное трололо, не видел такого уже лет 6.
> после краха в intelHD можно зайти по ssh и любоваться в логи.С радеонами такая же фигня. Если софт делает с GPU что-то не то, быавет характерная надпись в логе про "Ring N stalled for M milliseconds" и делется попытка перезагрузки. В лог записывается, ядро работает, по ssh система доступна. Драйвер пытается сделать перезагрузку GPU. Но получается не в 100% случаев. По поводу чего амдшникам порой имеют мозги и они уже 2 раза переделывали логику сброса, чтобы она была более эффективной.
И я не вижу как микроядро поможет в случае когда GPU стоит колом и попытка его сброса не удалась ("Ring N test failed", etc).
> И я не вижу как микроядро поможет в случае когда GPU стоит
> колом и попытка его сброса не удалась ("Ring N test failed",
> etc).О том и реч. А разные кукаретики свято верят, что им поможет микроядро.
ядро отрубит драйвер, а драйвер в свою очередь кинет в лог (Плиз ребут систем), по моему нормальное поведение в случае с микроядром. И ваще зачем микроядро должно волновать аппаратный крах подключаемой железки, не рамка же спалилась.
> ядро отрубит драйвер, а драйвер в свою очередь кинет в лог (Плиз
> ребут систем), по моему нормальное поведение в случае с микроядром.Ну вот в линухе нынче драйвер пишет при этом в лог нечто типа "Ring N test failed". Что примерно эквивалентно по смыслу "please reboot system" :). Ядро при этом живое, но радости с этого мало: на экране то не видно нифига.
Хотя если у тебя ssh живой есть и другой комп под рукой, можешь попробовать рестарт драйвера: rmmod и insmod. Но весь юзермод при этом скончается жестокой смертью, т.к. внутреннее состояние драйвера будет утеряно, обслуживание юзермода ВНЕЗАПНО срубится и тот получит массу внезапных, неожиданных ошибок оптом. А то что железка заработает - далеко не факт. Если один рестарт не прокатил - то и второй такой же по смыслу врядли прокатит.
> И ваще зачем микроядро должно волновать аппаратный крах подключаемой железки,
> не рамка же спалилась.Микроядро это может и не будет волновать, но юзеру у которого монитор ничего не показывает - легче от этого не станет. Собссно и в линухе нынче ядро зачастую живо, когда какой-то периферийный чип ловит клин. Но радости то с этого, если периферия отваливается? По этой причине драйвера на 50% состоят из quirks & workarounds.
> И вообще про падения сетевых драйверов и звука явное трололо, не видел такого уже лет 6.У меня проблемы:
- иногда имею проблемы с HDA intel, лечится это с использованием rmmod/insmod с последующим alsactl init 0 без перезагрузок
- иногда пропадает сеть на одной из служебных машин на сетевухе Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 10), лечится последовательностью команд последовательностью ifconfig через down-интерфеса, удаление адреса, назначение нового и удаление нового ip; это без перезагрузки
- еще есть проблема на одной из сетевух via Rhine в виде очень медленной обработке сетевых пакетов (пинг через эту сетевуху в локальной сети дает в среднем 0.3 ms вместо ожидаемых 0.05 ms; лечится заменой сетевухи на другую
Во всех случаях грешу на железо, т.к. такое же железо в таком же окружении и системной конфигурации на других системах работает без нарекании.
>> И вообще про падения сетевых драйверов и звука явное трололо, не видел такого уже лет 6.
> У меня проблемы:
> - иногда имею проблемы с HDA intel, лечится это с использованием
> rmmod/insmod с последующим alsactl init 0 без перезагрузок
> - иногда пропадает сеть на одной из служебных машин на сетевухе
> Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 10),
> лечится последовательностью команд последовательностью ifconfig через down-интерфеса,
> удаление адреса, назначение нового и удаление нового ip; это без перезагрузкиМне кажется, что её пора менять.
> - еще есть проблема на одной из сетевух via Rhine в
> виде очень медленной обработке сетевых пакетов (пинг через эту сетевуху в
> локальной сети дает в среднем 0.3 ms вместо ожидаемых 0.05 ms;
> лечится заменой сетевухи на другую
> Во всех случаях грешу на железо, т.к. такое же железо в таком
> же окружении и системной конфигурации на других системах работает без нарекании.Ну вот, даже монолитное ядро может.
> Мне кажется, что её пора менять.Это не одно железо, они на разных системах. С проблемами HDA Intel и Realtek вполне можно жить, т.к. они дают о себе знать лишь изредка (от нескольких дней/недель до нескольких месяцев). VIA Rhine пришлось заменить из-за больших задержек и низкой пропускной способности.
> - иногда имею проблемы с HDA intel, лечится это с использованием
> rmmod/insmod с последующим alsactl init 0 без перезагрузокЕсли такой "рестарт драйвера" прокатывает - ядро стало быть живое. А проблемы в логике работы драйвера с оборудованием. В смысле, там еще quirk и воркэраундов на глюки железа надо досыпать, чтобы драйвер мог без выгрузки отрабатывать.
> лечится последовательностью команд последовательностью ifconfig через down-интерфеса,
Не очень понятно как микроядро может помочь в вопросах глюкавости железа. Ядро при этом опять же живое. А то что железка залетела в дурное состояние, а драйвер это не предотвратил и не принял меры если предотвратить все-таки не вышло - вообще не о том.
> виде очень медленной обработке сетевых пакетов
Микроядро, определенно, не ускорит работу системы. Скорее наоборот.
Как бы разговор про то, что неправильно сформированным пакетом можно засрать память других частей ядра. Из юзерспейса это сделать несколько сложнее.
Но если девайс басмастер, то примочки в CPU не помогут это точно.
> Лично я довольно часто сталкивался с этим, когда звуковая / сетевая /
> графическая подсистемы падали и приходилось ребутать всю систему.При том как минимум в случае видео - если посмотреть в логи, можно заметить что обычно ядро линуха вполне себе работает, а драйвер просто не смог перезагрузить повисший GPU.
При этом на машину можно зайти по ssh и прочая. Но радости мало, т.к. GPU висит, его перинициализация не удалась, поэтому графика в ауте. При этом не принципиально, в микроядре драйвер или в монолите - висит ЖЕЛЕЗКА.
> При этом на машину можно зайти по ssh и прочая. Но радости мало, т.к. GPU висит, его перинициализация не удалась, поэтому графика в ауте. При этом не принципиально, в микроядре драйвер или в монолите - висит ЖЕЛЕЗКА.Причем иногда ЖЕЛЕЗКА повисает так что даже poweroff/poweron не помогает и система вешается на POST-тесте. В таких случаях нужно полностью обесточить блок питания и зажать POWER, мне помогало.
> Причем иногда ЖЕЛЕЗКА повисает так что даже poweroff/poweron не помогает и система
> вешается на POST-тесте.Дело в том что в ряде интерфейсов нынче ресет "софтварный". Скоростные сериальные шины зачастую не имеют выделенного провода под RESET. Поэтому RESET там лишь команда по проводам. Если на той стороне все померло окончательно, настолько что команды более не парсятся - опаньки, просто нажать ресет на системнике может быть недостаточно :)
> В таких случаях нужно полностью обесточить блок питания
> и зажать POWER, мне помогало....а некоторое железо, как то куски чипсета и прочая - получают питание с дежурки. Поэтому особо строптивым железкам может не хватить и даже обычного отключения питания.
Почему-то на клятой В-нде все работает - драйвер перезапускается, и все. Я сталкивался с таким, что даже игра продолжала работать после перезапуска, хотя чаще, конечно, крашится. Вот хотелось бы в онтопике также чтоб было.
> Почему-то на клятой В-нде все работает - драйвер перезапускается, и все. Я
> сталкивался с таким, что даже игра продолжала работать после перезапуска, хотя
> чаще, конечно, крашится. Вот хотелось бы в онтопике также чтоб было.Неоднократно наблюдал как мой интегрированный HD3200 падает от перегрева (разогнан, а радиатор маловат). На пару секунд фриз а затем я вновь вижу иксы. В dmesg видно что gpu reset. Игра сегфолтится но затем запускаешь вновь и продолжаешь. ЧЯДНТ?
Не работаешь зря. Скоро примут закон о тунеядстве, и будут год принудительных работ давать таким лоботрясам красноглазым ))) Зак. собрание Санкт-Петербурга, культурной столицы наркопотребителей, уже внесло проект закона в гос. ду*у.
> запускаешь вновь и продолжаешь. ЧЯДНТ?Разгоняешь древний крап вместо того чтобы купить более нормальный GPU, который без разгона в хренадцать раз быстре :)
> Почему-то на клятой В-нде все работает - драйвер перезапускается, и все. Я сталкивался с таким, что даже игра продолжала работать после перезапуска, хотя чаще, конечно, крашится. Вот хотелось бы в онтопике также чтоб было.Выше я писал про случай когда poweroff/poweron не помогает, так вот, в клятой винде это тоже не поможет как и не поможет под android, osx, plan9, ..
> Почему-то на клятой В-нде все работает - драйвер перезапускается, и все. Я сталкивался с таким, что даже игра продолжала работать после перезапуска, хотя чаще, конечно, крашится. Вот хотелось бы в онтопике также чтоб было.В обычных случаях помогает рестарт X или rmmod/insmod fglrx и последующий запуск X.
> Почему-то на клятой В-нде все работает - драйвер перезапускается, и все.Вот это далеко не факт. В смысле, там тоже GPU recovery проходит не в 100% случаев. А остальные драйвера и вовсе обычно теряют девайс до ребута.
> чаще, конечно, крашится. Вот хотелось бы в онтопике также чтоб было.
Там так бывает :). Выглядит забавно, как минимум у опенсорсного радеона: картинка паузится, на время до ~10 секунд (дефолтный таймаут ответа от GPU == 10 000 миллисекунд). А потом немного мерцает (в момент сброса GPU) и вскоре снимается с паузы. Если GPU recovery прошел успешно.
> Ну да. А когда выходит новость про GNU Hurd все начинают орать
> "фу-у-у-у, а зачем нам микроядро. И вообще..."1) при чём здесь?
2) попробуйте отстрелить миниксу какой-нить драйвер tty, поудивляйтесь.
пункт 2 у вас идиотский какой-то
> пункт 2 у вас идиотский какой-тоКак буд-то в tty багов не было?
Ну бывали, и что? На то и есть RS, чтобы перезапускать упавшие сервисы.
> А когда выходит новость про GNU Hurd все начинают оратьНу так пользуйся Hurd и продемонстрируй нам там драйвер ozwpan работающий лучше. Тогда не будем орать.
А зачем в эзернет-то, чем ip плох
опеннет все таки полон икспертов
У тебя IP поверх TokenRing работает?
> У тебя IP поверх TokenRing работает?IP может работать поверх чего угодно, начиная от последовательного порта (SLIP, PPP) и заканчивая почтовыми голубями (RFC1149).
> А зачем в эзернет-то, чем ip плохА нафуя там лишний уровень? Чтоб побольше парсить было?
> А нафуя там лишний уровень?Чтобы можно было отправлять пакеты из другого физического сегмента?
2 физических сегмента можно связать 1 логическим канальным - vlan. И даже l2 туннели сейчас умеют делать.
> 2 физических сегмента можно связать 1 логическим канальным - vlan. И даже
> l2 туннели сейчас умеют делать.Но зачем?
Судя по археологическим раскопкам "Ozmo, Inc" никогда не имела цели отправлять данные из другого сегмента. Их область - это PAN (personal area network) - от сантиметров до нескольких метров. Это было что-то вроде wireless USB, только с беспроводной частью поверх Wifi.
> Чтобы можно было отправлять пакеты из другого физического сегмента?Странный человек - хочет упростить хакерью ремотный взлом периферии :)
> А зачем нам мягкое, когда есть теплое?fixed
ужас! в staging-модуле обнаружена ошибка! йадро опасносте!
> ужас! в staging-модуле обнаружена ошибка! йадро опасносте!Хороший стимул подольше помариновать драйвер в staging. Нехай его автор осознает что сетевой драйвер надо писать с осторожностью сапера, разминирующего хитрозагнутую мину. В сети везде кругом "потенциальные противники". И 5 дыр за раз в 1 драйвере, к тому же сетевом - ну, знаете ли?!?
>> ужас! в staging-модуле обнаружена ошибка! йадро опасносте!
> Хороший стимул подольше помариновать драйвер в staging. Нехай его автор осознает чтоНет! Зовите http://www.phoronix.com/scan.php?page=news_item&px=MTc1NTY Грэга.
> сетевой драйвер надо писать с осторожностью сапера, разминирующего хитрозагнутую мину.
>ужас! в staging-модуле обнаружена ошибка! йадро опасносте!Ну когда была точно такая же ситуация с Releng branch FreeBSD - ляпиксоидов от истерии это не остановило, почему ви теперь таки в удивлении?!?! :)
Ничего "специального" в этом драйвере нет, а ошибка - типичное сипиписное гуано, написанное на чёрте каком опасном языке.
Юзайте Ди, да пребудут с вами границы массивов! :)
D никто и никогда не преднпзначал для писания ядра. Годится ли он для этого -невеломо. И, кстати, в реоизном билде все проверки границ вырубаются - как и везде, где не пофигу быстродействие
> преднпзначал
> невеломо.
> реоизномТы что, с тетриса сюда писал? :)
> Юзайте Ди,ди - для лузеров типа тебя. На нём за столько лет _ничего_ не написано. Звоночек.
Поддерживаю! Надо переписать ядро на Java! :D
тогда уж на хаскеле или АДА ;)
или Фортране.
а для осиливших(да, есть пара портов, увы) можно и покруче чегонить изобрести.
вроде порта ОС-и на Forth.
или существующих у нас и шведов соотв - форков UX на модула-2 и эрланге.
Сначала системд перепишите, а потом на святое замахивайтесь ;-)
А ещё лучше - на перл ))
> Юзайте Ди, да пребудут с вами границы массивов! :)Сразу после того как ты на этом напишешь ядра операционок.
>третья проблема вызвана условиями при которых выполняется деление на ноль
>выполняется деление на ноль
>деление на нольВ мире Linux возможно невозможное! :)
Я знаю точно невозможное - возможно
Делить на ноль, снести винду неосторожно )))
Итак, последние 20-30 лет мы видим тенденцию на работе с памятью. А именно то что в целом в C/C++ есть проблема в том, что никто или не что не следит за границами памяти. Помоему назревает новый стандарт языка D с решением проблем (p.s. самозванцев из Digital Mars кстати непонятно на каком основании заняли букву D).
А заодно мы заметим что проверка каких-нибудь границ в тугом цикле - гробит скорость работы. Раза в три. "Жаба не тормозит!!!111"