The OpenNET Project / Index page

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



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

Оглавление

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

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


113. "Выполнение rm -rf / может привести к неработоспособности UEF..."  +16 +/
Сообщение от CodeRush (?), 01-Фев-16, 13:16 
Раз уж меня сюда позвали, выскажусь и по этой проблеме. Для начала, systemd тут вообще не при чем (т.е. дополнительно ненавидеть Поттеринга не нужно), и с ядром тут тоже все хорошо (решение Мэтью Гаррет - воркэраунд вокруг настоящей проблемы, и если MSI её не исправят, то применять его надо бы только на этом ноутбуке, а не мешать вообще всем удалять то, что им нужно).
Сама проблема звучит так: "удаление некоторых переменных NVRAM приводит к остановке выполнения фазы DXE на некоторых ноутбуках MSI". Это действительно проблема, причина - в недостатке тестирования этого сценария (вполне, кстати, легитимного, и выполняемого в 20 строк на С в любой UEFI-совместимой ОС), а недостаток этот - он от сокращения времени разработки прошивки и прочих "оптимизаций Time-To-Market".
На самом деле, проблема эта не специфична для MSI, и страдают ей подавляющее большинство реализаций от практически всех IBV, плюс сам производитель железа может добавить свои драйверы, которые зависают от того, что нужных им переменных не оказалось, и не протестировать этот момент.
Решение: конкретный баг у MSI - найти и исправить, тест на этот случай - добавить в следующие версии FWTS, BITS и LUV, довести до производителей его необходимость через UEFI Forum. Пока реализации все еще сломаны - пользоваться воркэраундом Гаррета.
Если вам интересно мое мнение, я тоже против доступа в NVRAM на запись из ОС, по нескольким причинам. Во-первых, те немногие вещи, для которых этот доступ нужен утилите efibootmgr, должны решаться самой прошивкой (добавление/удаление/поиск новых UEFI-загрузчиков, изменение порядка загрузки), как это делается у AMI в данный момент, настройку SecureBoot тоже можно выполнить из Setup или, в крайнем случае, из UEFI Shell. Во-вторых, в случае RO NVRAM я могу поставить RO и на его регион, защитив все содержимое SPI-чипа от записи на аппаратном (ладно, почти аппаратном) уровне, подробности рассказывал в своем докладе на ZeroNights 2015, (вот слайды, если интересно:  github.com/NikolajSchlej/ZeroNights2015/blob/master/FixItYourself_Schlej.pdf)
Решать эту проблему тоже нужно не на уровне ядра определенной ОС, т.к. руту вы все равно ничего запретить не сможете, а вызвать SetVariable можно и без всяких псевдо-ФС, нужен только доступ к /dev/mem. Решать её надо либо эмуляцией NVRAM, либо изменением стандарта UEFI. К сожалению, первое воспринимается как костыль, нужный только фанатам безопасности, а второе - весьма непросто будет продавить, но я не перестаю надеяться именно на этот исход. За 10 лет правильно NVRAM на SPI-чипе так никто реализовать не смог - может быть, дело не в людях, а проблемы в консерватории?..
Ответить | Правка | Наверх | Cообщить модератору

123. "Выполнение rm -rf / может привести к неработоспособности UEF..."  +2 +/
Сообщение от Michael Shigorinemail (ok), 01-Фев-16, 13:27 
Спасибо за рассказ, хорошо бы им дополнить новость, если не против.

> Во-первых, те немногие вещи, для которых этот доступ нужен утилите efibootmgr,
> должны решаться самой прошивкой (добавление/удаление/поиск новых UEFI-загрузчиков,
> изменение порядка загрузки)

Конкретно тут явный перегиб -- и на BIOS доводилось крутить nvramtool'ом в оптовых количествах.

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

128. "Выполнение rm -rf / может привести к неработоспособности UEF..."  +/
Сообщение от CodeRush (?), 01-Фев-16, 13:37 
Без проблем, конечно.
С моей точки зрения, если нужно что-то крутить из внутренностей прошивки - для этого специально предназначен UEFI Shell, из него есть доступ ко всем протоколам, ко всем драйверам еще не выгруженным, к BootServices, и вообще ко всему "мясу и кишкам" прошивки. При этом загрузиться в него можно только пройдя правильно настроенный SecureBoot, а не воспользовавшись очередным LPE.
Обновление прошивки уже перенесли в безопасное pre-boot окружение, т.к. защитить его нормально оказалось практически невозможно, теперь туда же нужно переносить и настройку.  У автора блога firmwaresecurity.com Ли Фишера была недавно мысль о функции ExitRuntimeServices, после которой от UEFI оставались бы одни SMM-обработчики и ACPI-таблицы. Я считаю, что такой режим был бы полезным, и продвигать его однозначно стоит, даже ценой отказа от доступ к NVRAM и функции GetTime, но это мое мнение, и навязать его UEFI Forum'у я, понятно, не могу.
Ответить | Правка | Наверх | Cообщить модератору

140. "Выполнение rm -rf / может привести к неработоспособности UEF..."  +/
Сообщение от Аноним (-), 01-Фев-16, 14:30 
> С моей точки зрения, если нужно что-то крутить из внутренностей прошивки - для этого специально предназначен UEFI Shell

Ну и как тогда например менять параметры загрузки на удаленной машине ? Никак ?

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

146. "Выполнение rm -rf / может привести к неработоспособности UEF..."  +/
Сообщение от CodeRush (?), 01-Фев-16, 14:45 
А какие именно параметры предполагается менять? Если порядок загрузки - используйте GRUB или любой другой EFI-бутлоадер с конфигурацией, если опции ядра - тем более. Если вам нужны более серьезные модификации - пользуйтесь IPMI или AMT для удаленного управления из BIOS Setup. Загрузчик новой системы, которая устанавливалась по сети через PXE или UEFI HTTP Boot, подхватит и добавит в список загрузочных устройств диспетчер BDS, если её загрузчик положить на ESP в указанную в документации директорию (http://uefi.org/registry).
Ответить | Правка | Наверх | Cообщить модератору

141. "Выполнение rm -rf / может привести к неработоспособности UEF..."  +/
Сообщение от Crazy Alex (ok), 01-Фев-16, 14:37 
Как мнение пользователя/программиста/в прошлом админа - чем меньше специализированных сред - тем лучше. Я хочу при решении задач иметь привычный набор инструментов - от скриптов до доступа из сети, причём всё это - стандартным для моей инфраструктуры образом. В этом плане идея закрыть к чему-либо доступ из ОС мне не нравится совершенно.

Но вот сделать этот доступ нетривиальным, чтобы исключить случайности - дело другое. В данном случае я вообще не понимаю, зачем эту FS монтировать без явной нужды, хоть в RO, хоть в RW.

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

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ообщить модератору

354. "Выполнение rm -rf / может привести к неработоспособности UEF..."  –1 +/
Сообщение от XoRe (ok), 03-Фев-16, 17:39 
А если просто ввести sysctl параметр, что-то типа a.b.c.rw = 1?
По умолчанию, естественно, сделать rw = 0.
Если кому нужно обновить что-то, у них будет простой способ:
sysctl a.b.c.rw = 1
update
sysctl a.b.c.rw = 0
И все.
Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

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

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




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

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