The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

Оглавление

Выполнение rm -rf / может привести к неработоспособности UEF..., opennews (??), 01-Фев-16, (0) [смотреть все]

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


157. "Выполнение rm -rf / может привести к неработоспособности UEF..."  +/
Сообщение от CodeRush (?), 01-Фев-16, 14:59 
Моя задача, как разработчика прошивок - не только правильно инициализировать и передать ОС все установленные на плате железяки, но и сделать так, чтобы никакой дальнейший код мою прошивку сломать не мог, будь он запущен в ОС от рута или от черта лысого. С одной стороны, это связано с тем, что восстановление зачастую долгое и дорогое, а простые вроде бы решения ("поставьте второй чип") - они при массовом производстве стоят самые настоящие миллионы долларов, а сейчас нужно экономить на всем, иначе у тебя ничего не купят. С другой стороны, прошивка на данный момент является либо корнем доверия в системе, либо одним из звеньев цепи доверия, начинающейся с железа (BootGuard, PSP HWVB, вот это все). Потому мне нужно как-то защитить эту самую прошивку от разрушительных и/или вредоносных изменений, а лучший способ это сделать - хранить её на устройстве, которое просто нельзя смонтировать в RW из ОС. Я понимаю, что для пользователя это создает дополнительные трудности, но в конкретно этом случае security/convenience trade-off я выбираю сторону security, вот такая у меня профдеформация.
Ответить | Правка | Наверх | Cообщить модератору

158. "Выполнение rm -rf / может привести к неработоспособности..."  +4 +/
Сообщение от arisu (ok), 01-Фев-16, 15:02 
маленький нюанс тут, правда, в том, что это называется не «секурити», а «анальное огораживание».
Ответить | Правка | Наверх | Cообщить модератору

161. "Выполнение rm -rf / может привести к неработоспособности..."  +/
Сообщение от CodeRush (?), 01-Фев-16, 15:10 
Альтернативу предложите для нынешних платформ?
Открыть прошивку целиком не позволят сами производители чипов, слишком много документации придется выводить из под NDA. Получить нужные сведения реверс-инженирингом либо очень долго (3-4 поколения продуктов успевает смениться), либо вообще невозможно (на новых APU AMD инициализацию памяти выполняет встроенный криптопроцессор из своей TrustZone, а его прошивка подписана и зашифрована, удачи в реверсе). Пока у нас закрытое железо - открытых прошивок к нему не будет, и исключение libreboot только подтверждает наличие правила. Я смотрю с надеждой на OpenRISC и другие инициативы, но сейчас - лучше анальное огораживание, чем дефиле с голой жопой, уж простите.
Ответить | Правка | Наверх | Cообщить модератору

165. "Выполнение rm -rf / может привести к неработоспособности..."  +1 +/
Сообщение от arisu (ok), 01-Фев-16, 15:17 
> Альтернативу предложите для нынешних платформ?

конечно. но она очень не понравится производителям — что и было описано в скипнутой части поста. но лично для меня это не причина врать, называя «огораживание» «секурностью».

Ответить | Правка | Наверх | Cообщить модератору

167. "Выполнение rm -rf / может привести к неработоспособности..."  +/
Сообщение от CodeRush (?), 01-Фев-16, 15:27 
Ну пусть будет "огораживание", хоть горшком назови, только в печь не станови. На системах с Intel BootGuard, настроенным на максимальное огораживание, вообще нельзя изменить ни одно байта в любом месте, кроме региона для NVRAM - они подписаны, а хеш ключа зашит в однократно-записываемую память чипсета. Хочешь экспериментов - меняй чипсет на чистый, если у тебя СнК - то и всю СнК. Вот это огораживание, тут я ничего сказать не могу, но я так на своих системах постараюсь не делать до последнего, т.к. вот это уже сильно ограничивает свободу пользователя. От порчи же прошивки софтом (а не пользователем с физическим доступом, способным загрузить UEFI Shell) я защищался и буду защищаться, хоть как это называйте.
Ответить | Правка | Наверх | Cообщить модератору

184. "Выполнение rm -rf / может привести к неработоспособности..."  +/
Сообщение от Аноним (-), 01-Фев-16, 17:30 
Скажите пожалуйста, прошивки чего вы разрабатываете (ну чтоб случайно не купить) ?
Ответить | Правка | Наверх | Cообщить модератору

186. "Выполнение rm -rf / может привести к неработоспособности..."  +/
Сообщение от Crazy Alex (ok), 01-Фев-16, 17:34 
Присоединяюсь к вопросу.
Ответить | Правка | Наверх | Cообщить модератору

192. "Выполнение rm -rf / может привести к неработоспособности..."  +/
Сообщение от CodeRush (?), 01-Фев-16, 17:53 
Случайно вы их все равно не купите, это промышленные платы congatec в форм-факторе COM-Express и QSeven.
Ответить | Правка | Наверх | Cообщить модератору

370. "Выполнение rm -rf / может привести к неработоспособности..."  +/
Сообщение от Иван (??), 16-Янв-18, 21:47 
> Альтернативу предложите для нынешних платформ?

Джампер ro/rw? И пусть владелец сам решает, разрешать писать в NVRAM из ОС или нет с риском сложного востановления.

Ответить | Правка | К родителю #161 | Наверх | Cообщить модератору

190. "Выполнение rm -rf / может привести к неработоспособности UEF..."  +/
Сообщение от Crazy Alex (ok), 01-Фев-16, 17:46 
Позиция ясна. У меня она несколько другая:

1) если путём нетривиальных манипуляций владелец свою железку таки угробил - это его вина и его проблемы. Будь то "левая" смазка в шуруповёрте, стёртая с процессора термопаста или залитая левая прошивка - случай явно не гарантийный. Конечно, если при такой ситуации будет какая-то возможность сбросить устройство в дефолты, это плюс - но, вообще говоря, не обязательно.

2) "защита" прошивки от нетривиальных действий рута, запущенного на этом же устройстве (то есть после прохождения всех верификаций на этапе запуска системы) - это не "дополнительные трудности", а нечто совершенно неприемлемое. Это не security, а банальное ограничение прав якобы владельца устройства.

Ответить | Правка | К родителю #157 | Наверх | Cообщить модератору

193. "Выполнение rm -rf / может привести к неработоспособности UEF..."  +/
Сообщение от CodeRush (?), 01-Фев-16, 18:04 
> 1) если путём нетривиальных манипуляций владелец свою железку таки угробил - это
> его вина и его проблемы. Будь то "левая" смазка в шуруповёрте,
> стёртая с процессора термопаста или залитая левая прошивка - случай явно
> не гарантийный. Конечно, если при такой ситуации будет какая-то возможность сбросить
> устройство в дефолты, это плюс - но, вообще говоря, не обязательно.

Тем не менее, системы с какой-то защитой, даже если она по факту или не работает, или не работает как надо, продаются значительно веселее, чем без совсем без нее, поэтому сейчас их делает каждый IBV, и у всех практически она не работает как надо. Маркетинг - он такой.

> 2) "защита" прошивки от нетривиальных действий рута, запущенного на этом же устройстве
> (то есть после прохождения всех верификаций на этапе запуска системы) -
> это не "дополнительные трудности", а нечто совершенно неприемлемое. Это не security,
> а банальное ограничение прав якобы владельца устройства.

Не согласен. Если вы действительно владелец устройства, у вас есть физический доступ, т.е. джампер для вас переставить - проблемы не составляет. Защита от изменения прошивки ограничивает не пользователя, а вредоносный код, получивший у этого пользователя рута каким-либо образом. В Linux за год находят 3-5 локальных повышений привилегий, и еще 1-2 удаленных выполнения кода, т.е. вероятность атаки на прошивку от рута ниже того порога, после которого нужна защита от такого рода атак. Проблема в том, что кроме Linux у нас сейчас используются некоторые другие ОС одной известной компании, в которой получить рута легче, а разрушительные последствия - такие же. Тем более, что с внедрением UEFI сложность разработки вредоносного кода для прошивки уменьшилась даже не на порядок, а еще сильнее, и если не защищать её сейчас - потом будет уже поздно. Не нравится - не покупайте, я не заставляю, у Gigabyte и EVGA нет вообще никаких защит до сих пор, все платы шьются flashrom'ом из любой ОС. Coreboot есть для тех, кто реализациям UEFI не доверяет, опять же. Хотите сидеть с открытой прошивкой - у вас есть такая возможность, только вот мы не хотим, и клиенты наши тоже.

Ответить | Правка | Наверх | Cообщить модератору

236. "Выполнение rm -rf / может привести к неработоспособности UEF..."  +/
Сообщение от vi (ok), 01-Фев-16, 21:28 
Две Ваши фразы (возможно, "вырванные" из контекста).
> С одной стороны, это связано с тем, что восстановление зачастую долгое и дорогое, а простые вроде бы решения ("поставьте второй чип") - они при массовом производстве стоят самые настоящие миллионы долларов, а сейчас нужно экономить на всем, иначе у тебя ничего не купят.
> Тем не менее, системы с какой-то защитой, даже если она по факту или не работает, или не работает как надо, продаются значительно веселее, чем без совсем без нее, поэтому сейчас их делает каждый IBV, и у всех практически она не работает как надо. Маркетинг - он такой.

Поясните? Хотя, необязательно.


>[оверквотинг удален]
> изменения прошивки ограничивает не пользователя, а вредоносный код, получивший у этого
> пользователя рута каким-либо образом. В Linux за год находят 3-5 локальных
> повышений привилегий, и еще 1-2 удаленных выполнения кода, т.е. вероятность атаки
> на прошивку от рута ниже того порога, после которого нужна защита
> от такого рода атак. Проблема в том, что кроме Linux у
> нас сейчас используются некоторые другие ОС одной известной компании, в которой
> получить рута легче, а разрушительные последствия - такие же. Тем более,
> что с внедрением UEFI сложность разработки вредоносного кода для прошивки уменьшилась
> даже не на порядок, а еще сильнее, и если не защищать
> её сейчас - потом будет уже поздно.

С чем боролись, ... ;)

> Не нравится - не
> покупайте, я не заставляю, у Gigabyte и EVGA нет вообще никаких
> защит до сих пор, все платы шьются flashrom'ом из любой ОС.
> Coreboot есть для тех, кто реализациям UEFI не доверяет, опять же.
> Хотите сидеть с открытой прошивкой - у вас есть такая возможность,
> только вот мы не хотим, и клиенты наши тоже.

И да, перемычки сейчас "немодно" (немаркитоидно, так сказать ;) Ибо позволяют железке служить немного дольше, чем заложено производителем (хотя, на сегодняшний момент есть и другие методы создать потребителю так сказать постоянный зуд в одном месте :(

Ответить | Правка | Наверх | Cообщить модератору

241. "Выполнение rm -rf / может привести к неработоспособности UEF..."  +/
Сообщение от CodeRush (?), 01-Фев-16, 22:02 
> Поясните? Хотя, необязательно.

Поясняю. Есть несколько методов восстановления прошивки, но все они делятся на два больших класса - работающие, но дорогие, и бесплатные, но работающие через раз. Я о том, что первыми почти никто не пользуется по причине экономии средств, а вот вторые реализованы почти у всех, но срабатывают правильно они довольно редко.

> И да, перемычки сейчас "немодно" (немаркитоидно, так сказать ;) Ибо позволяют железке
> служить немного дольше, чем заложено производителем (хотя, на сегодняшний момент есть
> и другие методы создать потребителю так сказать постоянный зуд в одном
> месте :(

Дело не в маркетоидности, а в той самой NVRAM, которой вынь да полож доступ на запись в произвольный момент времени. Плюс в том же чипе свои настройки хранят Management Engine, Ethernet-контролер, Embedded Controller и остальные, причем первые два тоже могут осуществлять запись в случайный момент времени - как тут делать RO в таких условиях?
По поводу срока службы - верьте во что хотите, я никакого ухудшения качества материнских плат не вижу, и железо у обычных пользователей успевает устареть из за прогресса ПО (если это считать прогрессом, но это уже другой вопрос), а в промышленности работает по 10 лет и не жужжит.

Ответить | Правка | Наверх | Cообщить модератору

242. "Выполнение rm -rf / может привести к неработоспособности UEF..."  +/
Сообщение от vi (ok), 01-Фев-16, 22:17 
>> Поясните? Хотя, необязательно.
> Поясняю. Есть несколько методов восстановления прошивки, но все они делятся на два
> больших класса - работающие, но дорогие, и бесплатные, но работающие через
> раз. Я о том, что первыми почти никто не пользуется по
> причине экономии средств, а вот вторые реализованы почти у всех, но
> срабатывают правильно они довольно редко.

Все равно, за все заплатит потребитель!

>[оверквотинг удален]
> Дело не в маркетоидности, а в той самой NVRAM, которой вынь да
> полож доступ на запись в произвольный момент времени. Плюс в том
> же чипе свои настройки хранят Management Engine, Ethernet-контролер, Embedded Controller
> и остальные, причем первые два тоже могут осуществлять запись в случайный
> момент времени - как тут делать RO в таких условиях?
> По поводу срока службы - верьте во что хотите, я никакого ухудшения
> качества материнских плат не вижу, и железо у обычных пользователей успевает
> устареть из за прогресса ПО (если это считать прогрессом, но это
> уже другой вопрос), а в промышленности работает по 10 лет и
> не жужжит.

OverlayFS

Ответить | Правка | Наверх | Cообщить модератору

258. "Выполнение rm -rf / может привести к неработоспособности UEF..."  +/
Сообщение от Michael Shigorinemail (ok), 02-Фев-16, 00:31 
> OverlayFS

В чипе?

Ответить | Правка | Наверх | Cообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру