Защита от записи bios
Собственно, в самом BIOS такой настройки нет.
Как я понимаю, любой вирус может записать туда дерьмо и комп. включаться не будет. Собственно, так и произошло у жены, пришлось тратить время + $35 на ремонт. Причем вирус то еще может быть на диске, по этому сразу лучше переустановку Windows сделать?
Почему не сделали защиту?
Здравствуйте, Shmj, Вы писали:
S>Почему не сделали защиту?
По-моему, делали раньше защиту какую-то. Типа резервной копии БИОСа.
А еще галочки какие-то были, запрещающие перезапись.
Или я фантазирую?
Здравствуйте, Mihas, Вы писали:
M>По-моему, делали раньше защиту какую-то. Типа резервной копии БИОСа.
Не знаю, у жены и батарейку на минуту доставал и на кнопку сброса 10 секунд жал несколько раз -- ничего не помогло.
Ремонтники сказали что выпаяли микросхему и перепрошили.
M>А еще галочки какие-то были, запрещающие перезапись.
Зависит от редакции. Вот у меня сейчас посмотрел в ноутбуке -- нету никакой защиты.
Здравствуйте, Shmj, Вы писали:
S>Собственно, в самом BIOS такой настройки нет.
S>Как я понимаю, любой вирус может записать туда дерьмо и комп. включаться не будет. Собственно, так и произошло у жены, пришлось тратить время + $35 на ремонт. Причем вирус то еще может быть на диске, по этому сразу лучше переустановку Windows сделать?
S>Почему не сделали защиту?
Стандартная фича и интеловских чипсетов, и AMDʼшных — на старте системы защиты нет, но перед загрузкой ОС ставится флажок в чипсете, который запрещает запись в BIOS, и этот флаг можно снять только выключением питания или аппаратным ресетом.
После этого "любой вирус" уже не проходит. Если этот флаг ставится — защита достаточна.
Видимо, авторы твоего лаптопа просто потеряли эту установку.
Здравствуйте, netch80, Вы писали:
N>Видимо, авторы твоего лаптопа просто потеряли эту установку.
А как же тогда перепрошить биос?
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, netch80, Вы писали:
N>>Видимо, авторы твоего лаптопа просто потеряли эту установку.
S>А как же тогда перепрошить биос?
Ну вирус же как-то прошил, по твоим словам? Значит, в BIOS нет включения защиты перед стартом ОС.
Здравствуйте, netch80, Вы писали:
N>Ну вирус же как-то прошил, по твоим словам? Значит, в BIOS нет включения защиты перед стартом ОС.
Вот когда вы скачиваете прошивку для BIOS с сайта производителя -- как вы ее устанавливаете? В Windows режиме?
У меня в Windows режиме через спец. прогу.
Вирус не в моем ноуте а у жены прошел. И не факт что вирус, просто как то биос ипоганился. Вряд ли сам.
S>Вирус не в моем ноуте а у жены прошел. И не факт что вирус, просто как то биос ипоганился. Вряд ли сам.
вполне мог и сам
Здравствуйте, Shmj, Вы писали:
S>Собственно, в самом BIOS такой настройки нет.
S>Как я понимаю, любой вирус может записать туда дерьмо и комп. включаться не будет. Собственно, так и произошло у жены, пришлось тратить время + $35 на ремонт. Причем вирус то еще может быть на диске, по этому сразу лучше переустановку Windows сделать?
S>Почему не сделали защиту?
Здравствуйте, Shmj, Вы писали:
N>>Ну вирус же как-то прошил, по твоим словам? Значит, в BIOS нет включения защиты перед стартом ОС.
S>Вот когда вы скачиваете прошивку для BIOS с сайта производителя -- как вы ее устанавливаете? В Windows режиме?
S>У меня в Windows режиме через спец. прогу.
Последний раз, когда я это делал, был пункт в меню самого BIOS, который находил файл на воткнутой флэшке. Но это не лаптоп, а десктоп (материнку уже не помню, что-то из периода IvyBridge).
Спец. программа это для более ранних платформ.
S>Вирус не в моем ноуте а у жены прошел. И не факт что вирус, просто как то биос ипоганился. Вряд ли сам.
Вполне мог и сам.
Здравствуйте, Shmj, Вы писали:
S>А как же тогда перепрошить биос?
Как написал выше netch80, если в чипсете выставлен специальный флажок, то при попытке перезаписи образа BIOS генерируется специальное прерывание и процессор переключается в system management mode (SMM). Обработчик этого прерывания должен проверить аутентичность новой прошивки и разрешить запись в BIOS, если прошивка прошла проверку и запретить в противном случае (в случае вируса). Поэтому, если этот флажок выставлен вы можете обновить BIOS.
Здравствуйте, PM, Вы писали:
PM>Win.CIH проснулся
Ага, тоже его вспомнил. Но ни одной поврежденной им BIOS я не видел. Только диски.
Кстати, а как тогда с защитой BIOS решалось? Я слышал, на материнской плате перемычку ставили, и если нужно было перепрошить — снимали.
Здравствуйте, Privalov, Вы писали:
PM>>Win.CIH проснулся
P>Ага, тоже его вспомнил. Но ни одной поврежденной им BIOS я не видел. Только диски.
В основном ходили страшные истории, что 26-го апреля компьютер при включении превращается в груду железа. Один из однокурсников вроде бы пострадал, а может просто содержимое ПЗУ испортилось в апреле, как у топикстартера
P>Кстати, а как тогда с защитой BIOS решалось? Я слышал, на материнской плате перемычку ставили, и если нужно было перепрошить — снимали.
Да, кажется была перемычкам названием типа Flash write protect. Ещё сама микросхема BIOS обычно вставлялась в гнездо, так что её можно легко было вытащить для перепрошивки.
Здравствуйте, PM, Вы писали:
PM>В основном ходили страшные истории, что 26-го апреля компьютер при включении превращается в груду железа. Один из однокурсников вроде бы пострадал, а может просто содержимое ПЗУ испортилось в апреле, как у топикстартера
Битых ПЗУ и груд железа я не видел. А вот жесткие диски примерно в эти дни летели пачками.
На всех дисках, которые я видел, были убиты 2048 (или 4096? Вот же память стала. ) первых физических секторов.
PM>Да, кажется была перемычкам названием типа Flash write protect. Ещё сама микросхема BIOS обычно вставлялась в гнездо, так что её можно легко было вытащить для перепрошивки.
Да, тогда еще появилась куча рецептов для "горячей перепрошивки". Что-то типа: поддеть нитку под микросхему, загрузиться, вынуть ПЗУ, вставить другую. Или как-то так.
Здравствуйте, Privalov, Вы писали:
P>Да, тогда еще появилась куча рецептов для "горячей перепрошивки". Что-то типа: поддеть нитку под микросхему, загрузиться, вынуть ПЗУ, вставить другую. Или как-то так.
Собственноручно перепрошил одному страдальцу прошивку именно таким способом. Давно это было.
Здравствуйте, Eugene Radius, Вы писали:
S>>А как же тогда перепрошить биос?
ER>Как написал выше netch80, если в чипсете выставлен специальный флажок, то при попытке перезаписи образа BIOS генерируется специальное прерывание и процессор переключается в system management mode (SMM). Обработчик этого прерывания должен проверить аутентичность новой прошивки и разрешить запись в BIOS, если прошивка прошла проверку и запретить в противном случае (в случае вируса). Поэтому, если этот флажок выставлен вы можете обновить BIOS.
Когда семерку крякаешь, надо модифицированную прошивку залить с какими-то ключами. Скачиваешь оригинальную прошивку, тулзу, тулза эту прошивку модифицирует, потом минут 10 подбирает какую-то контрольную сумму и всё, биос её принимает как родную. Причём судя по инструкциям работает для 99% пользователей. Так что фикция все эти проверки.
Здравствуйте, vsb, Вы писали:
vsb>Когда семерку крякаешь, надо модифицированную прошивку залить с какими-то ключами. Скачиваешь оригинальную прошивку, тулзу, тулза эту прошивку модифицирует, потом минут 10 подбирает какую-то контрольную сумму и всё, биос её принимает как родную. Причём судя по инструкциям работает для 99% пользователей. Так что фикция все эти проверки.
К сожалению, и такое случается .. Выше описано как это должно работать в теории. На правктике это зачастую происходит иначе.
Здравствуйте, vsb, Вы писали:
vsb>Когда семерку крякаешь, надо модифицированную прошивку залить с какими-то ключами.
Зачем? uloader без всяких прошивок справляется, даже в виртуалке.
Здравствуйте, Ops, Вы писали:
vsb>>Когда семерку крякаешь, надо модифицированную прошивку залить с какими-то ключами.
Ops>Зачем? uloader без всяких прошивок справляется, даже в виртуалке.
Чтобы без всяких лоадеров. С OEM-ключом она работает точно так же, как на заводском ноутбуке и никогда не поломается. Можно и с лоадером, конечно. Я не люблю как-то обходить защиты, если можно просто использовать предусмотренные производителем способы.
Здравствуйте, landerhigh, Вы писали:
L>Собственноручно перепрошил одному страдальцу прошивку именно таким способом. Давно это было.
+1, была проблема с блоком питания (но сразу это было не заметить), микросхема биоса время от времени стиралась окончательно поборолось заменой БП , было это больше 10 лет назад.
Привет, форумчанам. Сразу перейду к делу. Проблема в следующем: имеется материнская плата foxconn 915A03-G-8KS, необходимо перепрошить bios (Текущая версия - 425F1P38 102 804, Phoenix Award) с помощью флеши. Но тут несколько ньюансов: прошивальщик afu860a.exe отказывается прошивать, выдавая: flash rom is write-protected. Имеются три слота джамперов - 1) называется INTR двухконтактный, которая что-то делает при загрузке системы (в bios это enabled/disabled свойства Case Open Warning); 2) Clear CMOS Jumper: CLS_CMOS трехконтактный имеет положение 1-2 (состояние Clear, сбрасывает настройки CMOS) и 2-3 (режим Normal, сохраняет текущее сотояние CMOS, является default); 3) BIOS TBL Jumper трехконтактный, используется для защиты загрузочного блока Table Boot Block, имеет подобные состояния с джампером CMOS: enable (состояние 2-3, default) и disable (состояние 1-2). Более подробный мануал есть на английском языке. Не могу понять как выставить эти джампера, чтобы было возможно прошить bios (т.е. снять блокировку write-protected). Еще есть подозрение, что защита установлена на аппаратном уровне (скорее всего так и есть). Есть также данные Flash Type: SST 49LF004A/B /3.3 V For Grantsdale 6A79DFK9C-00 10/28/2004 - то, что выдал прошивальщик. Надеюсь на помощь профессионалов. Можно ли обойтись без аппаратного вмешательства? Если нет/да, то что нужно для этого? Получится ли вообще как-то прошить мать? Заранее спасибо!
BIOS TBL Jumper - Disable
В BIOS Setup - раздел BIOS Features, SuperBIOS Protect - Disable
А кому счас легко.
Спасибо. Все решилось немного проще, защита от записи умная оказалась. Я пытался прошить материнскую плату более позднего выпуска с немного другим номером bios'ом от более старой модели, поэтому и срабатывала защита. Просто я позже нашел bios к собственной матери не на сайте производителя (неизвестно почему) и прошил им. Теперь в порядке все. Тему можно считать закрытой. Еще раз спасибо
Какие существуют опции безопасности в BIOS и как защитить биос от перезаписи(допустим мы купили пк настроили биос, и больще нехотим чтобы кто что-то там изменил, прошил его или чегото добавил(файл))?
Существуют ли какие-нибудь ограничения при установки ОЗУ памяти?
Доброго времени суток хотел бы узнать. Существуют ли какие-нибудь ограничения при установки ОЗУ.
Какие шрифты используются в BIOS
Доброго времени суток подскажите пожалуйста какие шрифты используются в BIOS и где их взять? Я.
Какие действия вы принимаете перед и после перепрошивки BIOS?
Какие действия вы принимаете перед и после перепрошивки BIOS на новую версию? Если никаких не.
Не совсем понятно, что имеется ввиду. Что бы защитить настройки, достаточно поставить пароль на вход в BIOS (это в самом BIOS'е и делается). Что бы защитить BIOS от перепрошивки, нужно правильно выставить джампер на материнской плате. что бы узнать какой именно, смотри инструкцию к материнке.
в данной теме я хотел обобщить все то что может защитить биос, думаю всем кто зайдет в этот раздел это будет интересно.
защита от перезаписи загрузочного сектора(Boot Sector Virus Protection). стоит ли использовать?
BIOS Flash BIOS Protection (Функция Flash защиты данных)
Опции: Enable, Disable
Данная функция предназначена для защиты BIOS от случайного повреждения пользователями или компьютерными вирусами. Когда она включена, данные, содержащиеся в BIOS, не смогут быть изменены при попытке обновить BIOS при помощи утилиты Flash. Для того, чтобы обновить BIOS, Вам нужно отключить функцию Flash защиты данных BIOS.Вы должны оставить эту функцию всегда включенной. Единственная ситуация, в которой следует отключать данную функцию - это обновление данных BIOS. После обновления данных BIOS, Вы должны немедленно включить ее вновь, чтобы защитить BIOS от вирусов.
BIOS Features Setup Virus Warning / Anti-Virus Protection (Предупреждение о вирусах / защита от вирусов)
Опции: Enabled, Disabled, ChipAway
Когда опция Virus Warning включена, BIOS выдаст предупреждение каждый раз при попытке обращения к загрузочному сектору или к таблице разделов (область в главной загрузочной записи (mbr), которая используется компьютером для определения доступа к диску). Лучше, по возможности, оставить эту опцию включенной. Таким образом только защищается загрузочный сектор и таблица разделов, а не весь винчестер.
Однако, эта опция может стать причиной проблем при инсталляции определенного программного обеспечения. Хорошим примером является обычная процедура инсталляции Win95/98. Когда эта опция включена, она становится причиной отказа при инсталляции Win95/98. Выключите ее перед инсталляцией подобного программного обеспечения.
В итоге, эта опция бесполезна для винчестеров, которые управляются внешними контроллерами (external controllers) с их собственным BIOS. Загрузочные вирусы минуют системный BIOS и пропишутся на такие винчестеры напрямую. Например, SCSI контроллеры и UltraDMA 66 контроллеры.
Некоторые материнские платы могут иметь свой собственный механизм защиты (ChipAway) в составе BIOS. Если вы его включаете, то обеспечивается дополнительная антивирусная защита системы, так как она сможет определять загрузочные вирусы до того как у них появится возможность заразить boot sector на винчестере. Опять же, эта опция бесполезна для винчестеров которые управляются отдельными контроллерами с их собственным BIOS.
Security Setup (Функция защищенной настройки)
Опции: System, Setup
Эта функция будет работать, только если Вы установите пароль через PASSWORD SETTING (установку пароля) на основном окне BIOS.
Выбор опции System настроит BIOS на запрос пароля при каждой загрузке системы.
При выборе опции Setup, пароль потребуется только при попытке доступа к настройкам BIOS. Эта опция полезна для системных администраторов или перепродавцов компьютеров, которым необходимо отгородить начинающих пользователей от копания в настройках BIOS.
Когда-то давно, в начале 2014 года, я назвал состояние безопасности большинства реализаций UEFI "полумифическим". С тех пор минуло полтора года, дело осторожно двигается с мертвой точки, но до сих пор очень многие производители ПК для конечного пользователя не обращают на эту самую безопасность почти никакого внимания — «пипл хавает».
В этой статье речь пойдет о модели угроз и векторах атаки на UEFI, а также о защитах от перезаписи содержимого микросхемы BIOS — самой разрушительной по возможным последствиям атаки.
Если вам интересно, как устроена защита UEFI и какие именно уязвимости в ней так и остаются неисправленными на большинстве современных систем — добро пожаловать под кат.
Часть нулевая. Введение
Модель угроз
Прежде чем говорить о защите и уязвимостях, поговорим немного о модели угроз.
Ни одна защита не может защитить от всего сразу. К примеру, защиту прошивки от поражающего действия ядерного взрыва или от сбоев при работе в открытом космосе, я в этой статье рассматривать не буду, хотя с удовольствием почитал бы подобную статью от специалистов в соответствующей области.
Уровни доступа
Определим для атакующего несколько уровней доступа и посмотрим, что и насколько успешно «среднестатистическая» реализация UEFI может противопоставить ему:
— атакующий первого уровня имеет физический доступ к системе, способен загружать любые ОС, изменять настройки UEFI, прошивать свой код UEFI вместо оригинального на программаторе, переставлять джамперы на мат. плате, замыкать выводы микросхем и т.п.
— атакующий второго уровня имеет физический доступ к системе, но программатора у него нет.
— атакующий третьего уровня имеет удаленный доступ к системе в режиме администратора.
Остальные случаи рассматривать не будем, т.к. от более могущественного атакующего, способного менять сидящие на шарах чипы, в UEFI защищаться практически нечем, а более слабых, без прав администратора, остановит ОС.
Векторы атаки
Теперь определим основные векторы и последствия успешно совершенной атаки, в порядке уменьшения опасности:
1. Хранилище основной прошивки (в 95% современных систем — 1-2 микросхемы NOR-flash с интерфейсом SPI )
Суть атаки — вставляем свой код в прошивку, удаляем части имеющегося, воруем, убиваем, молчим про гусей.
Последствия атаки варьируются от получения полного контроля над прошивкой, аппаратурой и ОС в лучшем случае, до DoS в худшем. Физический атакующий может устроить DoS в любом случае (с размаху отверткой в плату — вот тебе и DoS), поэтому подробнее на DoS для атакующих первого и второго уровней останавливаться не буду.
2. Код в SMM
Суть — получаем доступ к особо привилегированному режиму процессора, из которого нам доступна на чтение и запись вся физическая память и много другого вкусного.
Последствия — в лучшем случае доступ к хранилищу прошивки, и далее смотри пункт 1, в худшем — обход механизмов защиты ОС и гипервизора (которые, впрочем, можно было обойти и на уровне ОС, но из SMM это может быть намного проще).
3. Хранилище прошивки PCI-устройств
Суть — вставляем свой код в прошивку какого-либо PCI-устройства (она же Option ROM), к примеру, сетевой карты или контролера Thunderbolt, UEFI выполняет этот код при инициализации устройства, . профит.
Последствия — в лучшем случае смотри пункт 1, в худшем — почти то же самое, только стартуем значительно позже, и потому некоторые вещи уже настроены и заблокированы.
4. Переменные в NVRAM
Суть — получаем возможность изменять настройки UEFI, в том числе скрытые.
Последствия — в лучшем случае можно поотключать все защиты и сразу перейти к пункту 1, в худшем — снова DoS (пишем мусор в NVRAM, перезагружаемся, смотрим, что получилось).
5. SecureBoot
Суть — получаем возможность загрузить любую нужную ОС, в том числе UEFI Shell.
Последствия — в лучшем случае получается загрузить UEFI Shell и сразу оказаться в пункте 4, в худшем — заменить стандартный загрузчик ОС на модифицированный, закрепившись таким образом в ОС, пока бдительный пользователь не включит SecureBoot обратно.
Часть первая. Защиты от записи в хранилище основной прошивки
1. Аппаратная верификация прошивки или её части перед выполнением любого кода
2. Хранилище только для чтения с аппаратным переключателем
3. PR -регистры чипсета
Если аппаратно микросхему SPI защитить от записи не получилось, можно защитить ее силами чипсета. Все современные чипсеты имеют как минимум 4 регистра PR, предназначенных для защиты от чтения и/или записи блока физической памяти, а т.к. микросхема SPI всегда отображается на «дно» первых 4 Гб физической памяти (т.е. последний байт микросхемы SPI всегда находится по физическому адресу 0xFFFFFFFF), но можно защитить всю прошивку или ее часть.
Защита подобного рода тоже не обходится без проблем:
— ее нужно правильно реализовать, не забыв, что при перезагрузке значения регистров тоже сбрасываются, и их нужно восстанавливать.
— нужно не забыть установить (и восстановить после перезагрузки) lock на их конфигурацию, иначе вредоносный код их может банально сбросить.
— защита не может быть отключена, т.е. обновление прошивки из ОС без перезагрузки становится невозможным.
— и, конечно, NVRAM и другие RW-области защитить таким способом не получится.
В отличие от предыдущего пункта, систем с PR'ами на рынке море, и почти на всех защита реализована неграмотно или неполно.
4.1. SMM_BWP и SpiRomProtect
4.2. Intel BIOS Guard, в девичестве PFAT
5. BLE и BIOS_WE
6. Отсутствующая
Хрестоматийный пример «пирожка без никто». Некоторые производители материнских плат для десктопов, не будем показывать пальцем, до сих пор не защищают прошивку от перезаписи вообще. Ваша система — вы и заморачивайтесь, никакой иллюзии безопасности мы вам не даем, только голый BIOS, только хардкор. Вести себя таким образом с каждым днем становится труднее, ведь с одной стороны давит Intel с рекомендациями, а с другой — Microsoft с HSTI , но пока справляются. Безумству храбрых, и все такое.
Заключение
С защитами от прошивки более или менее разобрались, в следующей части поговорим об SMM и атаках на него.
Буду рад любым вопросам и комментариям. Спасибо за внимание.
Продолжаем говорить о безопасности UEFI, на этот раз речь пойдет об атаках на NVRAM и защите от них.
Неплохая, казалось бы, идея о том, что на микросхеме SPI можно хранить настройки практически вечно, не полагаясь на ненадежную и зависящую от батарейного питания CMOS SRAM, сыграла с разработчиками UEFI весьма злую шутку, теперь NVRAM с каждой новой версией стандарта обрастает все большим количеством костылей и подпорок, и конца этому процессу не видно. Если вам интересно, что именно пытаются подпереть костылем — эта статья для вас.
По традиции, всех, кто еще по каким-то причинам не читал первые три части — рекомендую начать с них, остальных с нетерпением жду под катом.
Часть четвертая. NVRAM
Идея на минус миллион
Честно признаться, я не знаю, кому именно в голову пришла идея переноса хранилища настроек из CMOS SRAM, где оно находилось испокон веков, на основную микросхему, но на сегодняшний момент можно констатировать, что это было той еще медвежьей услугой и производителям железа, и разработчиком прошивок, и конечным пользователям. Видимо, у Intel были на то какие-то свои причины, и потому интерфейс к NVRAM, в лице четверки Runtime-сервисов GetVariable / GetNextVariableName / QueryVariableInfo / SetVariable, стал частью самого первого опубликованного Intel (которая до организации UEFI Forum работала над ним практически единолично) стандарта EFI 1.10, прародителя всех нынешних реализаций UEFI.
Как устроен NVRAM
Атаки на NVRAM
Господа забывчивые 2
Через край
UEFI-загрузчик наносит ответный удар
Эта атака тоже весьма не новая, о ней еще в 2013 году был отличный пост тов. Falseclock. Суть атаки в том, что загрузчик (в качестве которого можно использовать хоть GRUB, хоть UEFI Shell, хоть вообще любое UEFI-приложение) имеет возможность выполнить произвольный код до возникновения события ExitBS, т.е. ранние стадии загрузчика имеют полный доступ к BS-переменным, в том числе и к Setup. Если производитель платформы не позаботился о запрете записи в эту переменную после того, как временное окно для вызова BIOS Setup закончилось (я видел такую защиту ровно на одной промышленной плате, больше ее нет нигде), то загрузчик (или пользователь, если у загрузчика есть шелл) может читать и изменять содержимое переменной Setup, в пятый раз писать про опасность этого уже не стану. Предлагаемая защита от таких безобразничающих загрузчиков — SecureBoot, но с ключами по умолчанию предлагается слепо доверять Microsoft (которая клятвенно обещала IBV никогда не подписывать загрузчики с шеллом), а у тех любителей открытых ОС, у которых в прошивке по умолчанию ключи не только MS, но и Canonical, защищаться от этой атаки буквально нечем — свежайший билд GRUB2 с шеллом и прочими плюшками, подписанный ключом Canonical, можно скачать из прямо репозиториев Ubuntu.
В заключении к прошлой части я упоминал, что пароль на BIOS — от честных людей. Поясняю: защищает он, чаще всего, от несанкционированного доступа к настройкам, причем только к тем, что доступны из интерфейса BIOS Setup. При помощи подходящей утилиты для доступа к NVRAM (Read Universal), парсера UEFI-образов (UEFITool, PhoenixTool, uefi-firmware-parser) и парсера IFR (Universal IFR Extractor) можно организовать себе доступ ко всем настройкам, в том числе и скрытым, в обход пароля, а потом еще и сбросить этот самый пароль, когда через «дырку в заборе» в BIOS Setup копаться надоест.
Социалисты-удалисты
Напоследок, самая безобидная NVRAM-related атака, которую может совершить на ваш ничего не подозревающий BIOS штатная Linux'овая утилита efibootmgr. В зависимости от фазы луны и интенсивности космических лучей, иногда при очередном обновлении ядра у нее получается не только добавить очередную переменную BootXXXX, но и удалить после этого несколько соседних, а если лучи в этот раз особенно высокоэнергитические — то и вообще все. После этого процентов примерно 30 реализаций UEFI авторства Phoenix или Insyde впадают в полный ступор — еще бы, фаза BDS закончилась, а загружаться больше не с чего. При этом все возможности выйти из ступора, вроде BIOS Setup, тоже были среди тех самых BootXXXX, и пользователь вынужден либо воспользоваться подсистемой Crisis Recovery (это если он может в RTFM) или нести систему в сервис. За последние пару лет лично сталкивался с этой атакой четырежды на трех принципиально разных системах. Стабильность, как говорится, признак мастерства.
Лучшая защита
Может прозвучать парадоксально, но лучшая защита от всех возможных проблем с NVRAM разом — удаление из нее NV, т.е. перенос всех лежащих на микросхеме SPI переменных в RAM и установка защиты от записи в область с ними при помощи PR-регистров сразу после BIOS Setup (если делать до — настройки перестанут сохранятся). Единственная современная ОС, которая хоть как-то пользуется записью в NVRAM — MacOS X, но у них там свой лунапарк без SMM и SecureBoot, так что про них разговор отдельный. Windows и Linux великолепно переживают тот факт, что переменные NV+RT больше не сохраняются, проблемы могут быть только у инсталяторов (пишем свои загрузчики в BootXXXX, а они не сохраняются, печаль) и какого-то очень специфического софта (которому кровь из носа такие переменные нужны, но я ни разу такого софта не видел). Ни на обычную работу с ОС, ни даже на обновление прошивки (или ее отдельных компонентов) при помощи механизма Capsule Update, несохраняемая NVRAM не влияет практически никак. Поневоле задумаешься, а нужна ли она вообще была с самого начала…
Заключение
Цикл понемногу подходит к концу, осталось рассказать про пару исторических атак на SecureBoot, про опасность неподписанных Option ROM'ов, и про выдающихся джентельменов (и леди), благодаря которым и была обнаружена большая часть описываемых проблем. Еще на пару частей хватит.
Спасибо читателям за внимание, удачных вам прошивок, и помните — NVRAM нужно беречь смолоду.
Читайте также: