а шо под лялех тоже есть флешеры видях?

после прошивания перезагружаться необходимо же, иначе не то что эффекта не будет, а и висюн можно огрести

Ну не в оперативку же оно грузит прошивки. Сам подумай.

после прошивания перезагружаться необходимо же, иначе не то что эффекта не будет, а и висюн можно огрести

Грузится не в ПЗУ, а в память устройства. Каждый раз при загрузке.

Про висюн - это да. Новые прошивки с UVD для radeon при проигрывании кодеком ffwm3vdpau делают не висюн, но вывод на экран монитора секунд на 10 замерзает, и после этого отключается режим энергосбережения видеокарты - у меня по крайней мере. Повторять не стал.

Хотя это скорее баги ПО.

хм, в память видюхи?

тогда это не фирмварь выходит, а «хак» памяти с автозапуском...

костыль то есть))

Опять ты не угадал - и не в оперативку видеокарты.

Меня беспокоит факт того, что при использовании открытого AMD драйвера нужно вкомпилять закрытые прошивки в ядро.
Может можно как-то сделать, чтоб было не вкомпилено?

Ещё я поднимал вопрос про опасность использования проприетарных драйверов (3-ий вопрос), может в этой теме кто-то расскажет подробнее о методах защиты, т.к полноценного ответа там не получил. Писали про Xen, но на сколько оправдано его использование для видео драйвера? Наверняка ведь будет падение производительности. Можно ли защититься SeLinux'ом?

Про микрокод процессоров речь не идет, здесь мне все более-менее ясно.

То что ты описал - тоже микрокод, но не для центрального процессора. Если в системе нет IOMMU или подобной технологии (например TrustZone) через которые ты можешь управлять доступом к системным ресурсам - все что угодно могут делать, это такие же bus master как CPU - имеют разделяемый доступ к ресурсам и в общем случае неконтролируемый.

Как правило чуть менее чем вообще все firmware это настолько зажопленные блобы, от самих производителей железа, что говорить о еще каких-либо «хаках» в общем то глупо.

Причина появления firmware - лицензия ядра linux. И соответственно какое его содержимое тоже можно догадаться.

Дальше такой глупый вопрос - кто конкретно догадается «ломать» нечто при помощи firmware? Сам производитель железа оставит «закладки» ? Или некий «мифический хакер» который отреверсит firmware получит его исходник и дальше сделает с ним свои гнусные пакости ?

В первом случае там объемы не те а во втором всегда можно сравнить с firmware из иных источников и версий. Как правило там даже разные версии не так уж сильно отличаются.

В общем trupiko либо выключай свою паранойю вовсе и прекращай плодить бессмысленные топики либо включай на максимум и начинай с самого главного блоба BIOS/uEFI.

Писали про Xen, но на сколько оправдано его использование для видео драйвера

Для защиты от уязвимостей в программах считаю, что все, что может усложнить нападение на хост, оправдано. В том числе виртуализация и мандатное управление доступом. В SELinux есть песочница для иксов sandbox_xserver_t (сам не пробовал). Но кроме иксов, есть еще mesa и куча другого ПО, которое задействуется для вывода картинки на экран. В нем тоже могут быть уязвимости.

И если то, что говорит анон - правда, и фёрмварь для устройств, ничем не отличается от микрокода для процессоров, то все вообще печально. Сам не разбираюсь в этом, если честно.

Как правило чуть менее чем вообще все firmware это настолько зажопленные блобы.

Это понятно.

Дальше такой глупый вопрос - кто конкретно догадается «ломать» нечто при помощи firmware?

Если не удалось взломать легким путем, почему бы и нет.

Сам производитель железа оставит «закладки» ? Или некий «мифический хакер» который отреверсит firmware получит его исходник и дальше сделает с ним свои гнусные пакости ?

Не исключено все, что ты написал. Читаешь мои мысли.

начинай с самого главного блоба BIOS

Увы, не хватает мозгов... а так бы расковырял свою материскую плату отверткой.

Для защиты от уязвимостей в программах считаю, что все, что может усложнить нападение на хост, оправдано. В том числе виртуализация и мандатное управление доступом. В SELinux есть песочница для иксов sandbox_xserver_t (сам не пробовал). Но кроме иксов, есть еще mesa и куча другого ПО, которое задействуется для вывода картинки на экран. В нем тоже могут быть уязвимости.

Ну mesa — open source, я же про блобы говорю, а не про уязвимости.

Если не удалось взломать легким путем, почему бы и нет.

Закладки в прошивках роутеров это одно а потенциальные закладки в firmware от оборудования в ядре linux это несколько другое.

Во первых у прошивок роутеров объем в несколько раз больше. Во вторых у них это понятно - там информация ходит и удаленный доступ к ней это модно/весело/и ваще…

А firmware от оборудования в ядре linux работает несколько иначе, объемы у него совершенно не те чтобы туда что то зловредное встроить. И кроме того я не проверял… но что то мне подсказывает что само ядро linux не даст зловредить из firmware. А если и даст то велькам ту hardened-gentoo и твои волосы будут мягкими и шелковистыми.

Увы, не хватает мозгов... а так бы расковырял свою материскую плату отверткой.

Т.е. копеечкная прошивка от железки созданная ради того чтобы не нарушать лицензию ядра это пипец как страшно а вот единственная почти всегда неизменная программа работающая ВСЕГДА и не смотря на ЛЮБЫЕ операционные системы работающие поверх нее да еще и не контролируемая НИЧЕМ это вовсе не страшно? Ну ок.

Во первых у прошивок роутеров объем в несколько раз больше. Во вторых у них это понятно - там информация ходит и удаленный доступ к ней это модно/весело/и ваще…

Есть прошивки и для ethernet- и wifi- устройств. Информация там ходит та же самая.

Во первых у прошивок роутеров объем в несколько раз больше.

8.0K	/lib/firmware/radeon/REDWOOD_me.bin
8.0K	/lib/firmware/radeon/REDWOOD_pfp.bin
4.0K	/lib/firmware/radeon/REDWOOD_rlc.bin
24K	/lib/firmware/radeon/REDWOOD_smc.bin
116K	/lib/firmware/radeon/CYPRESS_uvd.bin

Это то, что я загружаю. Вот у меня, например, почему-то не работает ffodivxvdpau, а ffwm3vdpau вообще глючит. Всего прошивка CYPRESS поддерживает 4 кодека. 116/4 = 29Kb. Места для размещения вредоносного кода там достаточно.

Т.е. копеечкная прошивка от железки созданная ради того чтобы не нарушать лицензию ядра это пипец как страшно а вот единственная почти всегда неизменная программа работающая ВСЕГДА и не смотря на ЛЮБЫЕ операционные системы работающие поверх нее да еще и не контролируемая НИЧЕМ это вовсе не страшно? Ну ок.

И то страшно, и другое страшно. Просто прошивки я могу не загружать и работать в фреймбуфере, а с BIOS ничего самостоятельно поделать не смогу, увы.

И кроме того я не проверял… но что то мне подсказывает что само ядро linux не даст зловредить из firmware.

Подождем того, кто проверит. Для этого и нужны такие темы.

А если и даст то велькам ту hardened-gentoo и твои волосы будут мягкими и шелковистыми.

Стоит уже, но от прошивок и микрокода не спасет.

Только что заметил, что размер прошивки кратен двум.

Это прикол ядра или прошивок от radeon?

Только что заметил, что размер прошивки кратен двум.

и без -h?

так лучше

$ du --apparent-size /lib/firmware/radeon/*
6	/lib/firmware/radeon/REDWOOD_me.bin
5	/lib/firmware/radeon/REDWOOD_pfp.bin
3	/lib/firmware/radeon/REDWOOD_rlc.bin
24	/lib/firmware/radeon/REDWOOD_smc.bin
114	/lib/firmware/radeon/CYPRESS_uvd.bin

или так

du --apparent-size -B 1 /lib/firmware/radeon/*
115736	/lib/firmware/radeon/CYPRESS_uvd.bin
5504	/lib/firmware/radeon/REDWOOD_me.bin
4480	/lib/firmware/radeon/REDWOOD_pfp.bin
3072	/lib/firmware/radeon/REDWOOD_rlc.bin
24332	/lib/firmware/radeon/REDWOOD_smc.bin

кратно 4

Места для размещения вредоносного кода там достаточно.

А вопрос не в этом а в том куда конкретно загружается firmware и что ему можно в ядре linux.

Стоит уже, но от прошивок и микрокода не спасет.

Тогда смотри его настройки. Там много параноидальных галочек.