Есть, но пока еще не во всех чипсетах, а только в SoC. Это PSP, который является ядром ARM с TrustZone и используется для HVB, реализации программного TPM 2.0, ускорения криптографических операций, а в последних поколениях Falcon SoC он уже и память тренирует, и S3 resume выполняет, так что платформа теперь без PSP фактически неработоспособна. При этом его прошивка зашифрована и подписана ключем AMD, что там в ней происходит — не знает практически никто, в том числе и потому, что машин AMD на рынке кот наплакал, и заниматься их реверсом почти никому не интересно.
Про PSP я, кстати, уже писал, почитайте, если интересно.
Не доступна. Область эта для CPU выглядит как замапленная на несуществующее PCI-устройство, сплошные 0xFF, которые не получается переписать. Стартует ME значительно раньше процессора по power sequence, и вообще может сделать все свои темные дела до reset vector'а, так что никакие фиксы со стороны кода, выполняемого на CPU, не помогут.
Совместимы они только для чипсетов седьмой серии начиная со степпинга B3, поэтому просто так обновлять 7.x на 8.x не стоит — не всегда срабатывает. Если производитель уже обновил за вас — молодец, значит, сам чипсет и platform support code готовы работать с версиями 8.x, а если нет — рисковать не стоит.
Да я не спорю, только вот «кто будет контролировать контролеров»?
Мой опыт показывает, что административный способ решения проблем безопасности — далеко не самый лучший, если вам больше повезло — это здорово.
Не втыкать внешних устройств, не иметь поключенных к сети ПК в радиусе AirGap'а, а лучше и совсем не включать. От APT уровня StuxNet поможет только последнее.
Лучший способ — избегать использования систем с МЕ (и PSP), других хороших способов защититься от МЕ, имеющего доступ к внутренней шине DMI и собственный DMA-контролер с обходом IOMMU просто нет.
Уже не раз писал, но повторюсь: цель информационной безопасности не в закрытии уязвимостей, а в том, чтобы сделать получение несанкционированного доступа к информации дороже самой информации. Если у вас совершенно секретные данные — делайте себе процессоры сами, на своих фабриках и со своей архитектурой. Не имеете возможности или желания — придется доверять компаниям Intel и/или AMD, стратегическим партнерам АНБ. Можно еще надеяться на успех проектов вроде LowRISC/OpenRISC, но, как показывает случай Сноудена (сильно ускоривший внедрение повсеместного E2E-шифрования), пока в ME/PSP не найдут заяющую дыру, деньги в открытое железо никто вкладывать не будет и ситуация с ME сильно не изменится.
Цель проекта LibreBoot — полностью свободная прошивка без сторонних бинарных компонентов, поэтому с чипсетами новее 5 серии он не совместмим. Проект CoreBoot использует сторонние компоненты вроде ME firmware или VBIOS, поэтому на работоспособность ME практически не влияет. Я пишу «практически» потому, что для инициализации интерфейса HECI используются UEFI DXE-драйверы, которые в CereBoot нужно еще портировать, чтобы с ME можно было общаться из ОС.
Не будет оверклокинга и управления частотой пользователем (ICC), могут быть проблемы с воспроизведением защищенного DRM контента (PAVP), перестанут работать выполняемые МЕ Java-апплеты (DAL, они очень редки и в живой природе практически не встречаются), в общем, всего того, что использует интерфейс HECI. Есть еще некоторые другие, более серьезные, но NDA не позволяет говорить о них ничего конкретного.
Одно могу сказать — проблем с отключенным МЕ прилично и бороться с ними непросто, но пока это единственный способ иметь ReadOnly-прошивку, которая требуется банковской сфере, операторам игровых автоматов, промышленным автоматизаторами другим клиентам, которым требуется железная гарантия отсутсвия любых изменений в ПО системы.
Добавлю про RDTSC — эта инструкция может быть перехвачена гипервизором и возвращать что угодно. Более того, если снят бит TSD в регистре CR4, то для её использования нужны повышенные привелегии, и потому ваша программа, которая эту инструкцию использует, не будет работать правильно в QNX, которая ставит этот бит по умолчанию.
В качестве независимого от платформы и ОС источника времени (как точного, так и интервалов) могу посоветовать UEFI RT-сервис GetTime, но как вы до него из вашей конкретной ОС доберетесь — другой вопрос.
Опять не же согласен. Из моей практики самые неприятные для перезагрузки устройства — клиентские хреновины на FPGA. Продолжительность ресета у них непредсказуемая, а на сам сигнал они реагируют как хотят. Не успел проинициализироваться — отвалился от PCIe. В результате приходится городить разные костыли вплоть до POST-таймаутов и многоканальных вотчдогов, все для того, чтобы «перестало глючить».
Зато я видел пару раз, хоть и не на серверах. Чтобы выполнить перезагрузку, ядро должно знать, как это делается на конкретном железе, и иногда это знание его подводит в случае, если железо новое, странное или просто глючное.
Вот тут хорошо видно, как на x86 происходит перезагрузка: сначала пробуем ACPI Reset, не вышло — KB Reset, не получилось и это — EFI Reset (вышеупомянутый сервис), не вышло и это — CMOS Reset, затем PCI Reset, не случился и он — сбрасываем IDT и инициируем отладочное прерывание INT3, а если и это не помогло — пробуем все снова. Редкая нормальная система переживет такое не перезагрузившись, но я могу предстваить пару конфигураций, которые все-таки смогли бы. Вот поэтому Runtime-сервис и ввели, чтобы не угадывать, какой ресет у нас сегодня работает, а какой вместо ресета зависает намертво, как это происходит на BayTrail и KB Reset'ом иногда.
Может, никто не спорит. Сделан этот сервис в первую очередь для того, чтобы предоставить абстракцию от конкретного способа выполнить этот самый Reset, а то этих способов за 30 лет развития архитектуры x86 накопилось столько, что не знаешь, за какой хвататься, и какие еще работают (IO port 0xCF9), какие уже 10 лет устаревают (IO port 0x92), а какие наконец-то устарели совсем (IO port 0x64).
Добавлю, что на машинах с UEFI есть возможность вызвать перезагрузку вызовом gRT->ResetSystem(), который не зависит от ядра и может выполнить даже power cycle reset, при условии, что БП не завис намертво. Доступен сервис на любой системе и без IPMI, но как достучаться до UEFI RT Services из ОС — вопрос отдельный.
Я же так и написал, что это идея, хочешь используй eMMC в качестве хранилища прошивки, хочешь — продолжай использовать SPI. Да и не удивляюсь я ничему, выше уже писал, что на Bay Trail было почти то же самое. Вы меня как-то неправильно поняли, мне кажется.
Защищена область будет очень просто — начиная со стандарта eMMC 4.4 на них имеется специальный RPMB-раздел размером до 32 Мб, на котором можно хранить ключи шифрования и прочую чувствительную информацию, и два раздела Boot0 и Boot1 (оба до 32 Мб), запись на которые можно запретить до перезагрузки во время инициализации прошивки. В итоге ничего разруливать не нужно — контролер eMMC разрулит все за нас.
Идею адаптировали еще на Bay Trail, только там загрузка была двухстадийная и PEI все равно был только на флешке, а теперь вот удалось интегрировать контролер eMMC достаточно глубоко, чтобы грузится с него. Безопасность там обеспечат каким-нибудь аналогом BootGuard, при котором прошивку можно будет хранить хоть где — пока коллизии SHA256 не научились находить за полчаса, такой защиты хватит. Посмотрим, я не буду загадывать. Производители для индустрии у пользователя возможность добавить собственный код в прошивку не отбирали и не будут отбирать, а до всяких Asus'ов мне теперь уже дела почти нет, пусть хоть на голове танцуют.
Можно и 64 кб впихнуть, если стараться, но это все никому не нужно.
Сейчас вот в недавней презентации новой линейки Atom под кодовым именем Apollo Lake на слайде двинули интересную во всех отношениях идею — отказ от SPI-чипа для хранения прошивки в пользу EMMC. Там и автоматический WL, и регистр EXT_CSD, в котором результаты WL и прогноз живучести можно наблюдать, и разделы специальные под загрузчики с защитой от записи и тайминг-атак, да и вообще плюсы сплошные. С другой же стороны, получив возможность иметь в прошивке не 16 МБ, а 16Гб, у некоторых производителей от такого обилия моментально снесет крышу, и в прошивку засунут не просто 3D-моделей и заказ пиццы, а вообще целиковый эмулятор андроида (привет, AMI DuOS), какой-нибудь еще линукс для административных задач, и парочку своих велосипедов на паровой тяге размером в полгигабайта.
Я устал уже разным людям из индустрии говорить, что прошивки вообще и UEFI в частности «созданы, чтобы умирать», как PHP в свое время, и не нужно делать ОС общего назначения из UEFI Shell, там кишки наружу все и любое переполнение буфера — это компрометация всей системы. Все равно об стену горохом, мусора в прошивке с каждым годом все больше, а толку от нее все меньше.
Про PSP я, кстати, уже писал, почитайте, если интересно.
Мой опыт показывает, что административный способ решения проблем безопасности — далеко не самый лучший, если вам больше повезло — это здорово.
Уже не раз писал, но повторюсь: цель информационной безопасности не в закрытии уязвимостей, а в том, чтобы сделать получение несанкционированного доступа к информации дороже самой информации. Если у вас совершенно секретные данные — делайте себе процессоры сами, на своих фабриках и со своей архитектурой. Не имеете возможности или желания — придется доверять компаниям Intel и/или AMD, стратегическим партнерам АНБ. Можно еще надеяться на успех проектов вроде LowRISC/OpenRISC, но, как показывает случай Сноудена (сильно ускоривший внедрение повсеместного E2E-шифрования), пока в ME/PSP не найдут заяющую дыру, деньги в открытое железо никто вкладывать не будет и ситуация с ME сильно не изменится.
Одно могу сказать — проблем с отключенным МЕ прилично и бороться с ними непросто, но пока это единственный способ иметь ReadOnly-прошивку, которая требуется банковской сфере, операторам игровых автоматов, промышленным автоматизаторами другим клиентам, которым требуется железная гарантия отсутсвия любых изменений в ПО системы.
В качестве независимого от платформы и ОС источника времени (как точного, так и интервалов) могу посоветовать UEFI RT-сервис GetTime, но как вы до него из вашей конкретной ОС доберетесь — другой вопрос.
Вот тут хорошо видно, как на x86 происходит перезагрузка: сначала пробуем ACPI Reset, не вышло — KB Reset, не получилось и это — EFI Reset (вышеупомянутый сервис), не вышло и это — CMOS Reset, затем PCI Reset, не случился и он — сбрасываем IDT и инициируем отладочное прерывание INT3, а если и это не помогло — пробуем все снова. Редкая нормальная система переживет такое не перезагрузившись, но я могу предстваить пару конфигураций, которые все-таки смогли бы. Вот поэтому Runtime-сервис и ввели, чтобы не угадывать, какой ресет у нас сегодня работает, а какой вместо ресета зависает намертво, как это происходит на BayTrail и KB Reset'ом иногда.
Большое спасибо за материал, пригодится обязательно.
Защищена область будет очень просто — начиная со стандарта eMMC 4.4 на них имеется специальный RPMB-раздел размером до 32 Мб, на котором можно хранить ключи шифрования и прочую чувствительную информацию, и два раздела Boot0 и Boot1 (оба до 32 Мб), запись на которые можно запретить до перезагрузки во время инициализации прошивки. В итоге ничего разруливать не нужно — контролер eMMC разрулит все за нас.
Сейчас вот в недавней презентации новой линейки Atom под кодовым именем Apollo Lake на слайде двинули интересную во всех отношениях идею — отказ от SPI-чипа для хранения прошивки в пользу EMMC. Там и автоматический WL, и регистр EXT_CSD, в котором результаты WL и прогноз живучести можно наблюдать, и разделы специальные под загрузчики с защитой от записи и тайминг-атак, да и вообще плюсы сплошные. С другой же стороны, получив возможность иметь в прошивке не 16 МБ, а 16Гб, у некоторых производителей от такого обилия моментально снесет крышу, и в прошивку засунут не просто 3D-моделей и заказ пиццы, а вообще целиковый эмулятор андроида (привет, AMI DuOS), какой-нибудь еще линукс для административных задач, и парочку своих велосипедов на паровой тяге размером в полгигабайта.
Я устал уже разным людям из индустрии говорить, что прошивки вообще и UEFI в частности «созданы, чтобы умирать», как PHP в свое время, и не нужно делать ОС общего назначения из UEFI Shell, там кишки наружу все и любое переполнение буфера — это компрометация всей системы. Все равно об стену горохом, мусора в прошивке с каждым годом все больше, а толку от нее все меньше.