Спасибо за статью, уважаемый Atakua. Сколько не работай с x86 на уровне «ниже уже железо», все равно узнаешь массу нового.
Если можно, напишите в следующий раз про состояния энергосбережения: C-State, P-State, NB/Mem P-State, T-State, EIST, CPPС, DPTF, вот это все. Понятно, что все есть в даташитах, но статья на русском будет полезна в любом случае.
Конечно. Все эти «permanently» — зачастую фикция. Anti-Cheft, вообще говоря, больше не поддерживается, и включать его я не рекомендую, а вот драйверы LoJack/Computrace лучше удалять не думая, т.к. никаким «permanently» там и близко не пахнет.
Только если в прошивке уже есть необходимые драйверы и не хватает только самого TPMа. Обычно в таком случае нужно припаять сам чип (SSOP-28, паяется руками без проблем) и пару SMD-резисторов и конденсаторов для его питания. Иногда еще придется найти strap-резисторы и поменять их так, чтобы драйверы TPM начали стартовать.
Это проблема ASUS и всех остальных вендоров, которые используют SecureBoot вместе с CSM. В итоге SecureBoot вообще ни от чего не защищает, а только приводит к таким вот неприятностям. И ладно, когда такое встречается на ноутбуках выпуска 2013 года с прошивками на базе EDK первой версии, в которых CSM просто так не отключить, но когда в ASUS специально меняют настройки по умалчанию так, чтобы скрестить ужа с ежом — виноваты только они, жаль только, что страдают в итоге пользователи.
Apple никаких инструментов для работы с МЕ из OSX не предоставляет, а больше и некому. Насколько я успел понять, у Apple есть доступ к исходному коду ME, и потому на их системах прошивка сильно обрезана и не публикует интерфейс HECI, а то и вообще отключается после начальной инициализации, но тестовой машины у меня нет, так что судить не берусь.
Есть, но пока еще не во всех чипсетах, а только в 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'ом иногда.
Если можно, напишите в следующий раз про состояния энергосбережения: C-State, P-State, NB/Mem P-State, T-State, EIST, CPPС, DPTF, вот это все. Понятно, что все есть в даташитах, но статья на русском будет полезна в любом случае.
Про 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'ом иногда.