Напротив, шанс получить вот такое станет меньше, потому что TPM будет на критическом пути и тестировать взаимодействие с ним (в том числе сброс и проверку физического присутствия) станут лучше.
Крипточипы, кроме новых проблем, приносят и новые возможности: действительно безопасную загрузку (т.е. буткиты уже не зашифруют вам диск целиком), безопасную биометрическую идентификацию без риска утечки данных, безопасное хранилище критических данных вроде кредитных карт, полнодисковое шифрование, которому никакой дополнительный софт не нужен, и т.п.
Если вам ничего этого не нужно — отлично, на рынке пока еще достаточно вендоров, у которых никаких крипточипов нет и не предвидится, если вам такие по душе — голосуйте за них рублем.
Кроме того, есть и вендоры, которые изначально нацелены на продвинутого пользователя и передают ему всю безопасность в руки, System76 или Raptor CS, например.
Но так ведь всегда было с любым железом любых производителей, которые поддержку Linux из коробки не декларируют (а Apple, на моей памяти, не декларировала таковую никогда).
Добавлю от себя к этому списку:
— написаной на языке, на котором критический для безопасности платформы код писать практически невозможно, потому что это требует нечеловеческой концентрации внимания.
— разрабатываемой кучей плохо связанных друг с другом вендоров, половина из которых вообще не выпускает никаких продуктов для конечного пользователя, а другая не имеет никакого понятия о том, как разрабатывать ПО (потому что они разрабатывают железо и продают его же), и не имеет штатных специалистов по безопасности вообще.
— сляпаной в спешке из копипасты и говнокода, т.к. практически все разработчики прошивок имеют крайне строгие дедлайны (привязанные к выходу новых процессоров, которые, внезапно, выпускает совсем другая компания, которой на ОЕМов наплевать) и потому вынуждены выпускать то, что получилось. При этом процессоры (одинаковые по сути, но разные по маркировке) выходят каждые 6-9 месяцев, и обновлять продукты ОЕМы вынуждены в том же цикле, т.е. на разработку и отладку прошивок банально нет времени, какая уж тут безопасность…
— имеющей древние неисправленные уязвимости, потому что цена ошибок при обновлении очень высока (сломанное железо, возврат по гарантии, недовольные пользователи) и сами обновления дороги (тестирование долгое и дорогое, повторная сертификация долгая жутко и дорогая до невозможности), обновления выпускаются либо очень поздно, либо вообще никогда, т.е. любые проблемы безопасности остаются неисправленными на реальном железе практически вечно.
Можно добавить еще десяток, но я опасаюсь за свои НДА…
Улучшения безопасности SMM и нормальная цепочка доверия от железа будут полезны любой ОС, которая поддерживает UEFI SecureBoot. Поддержу TPM2 для DRTM и TXT (и его аналогов от AMD и Qualcomm) нужно будет добавить либо в ядро, либо в один из загрузчиков (Google работает над этим в данный момент), чтобы получилось использовать и их.
По сути, MS вынужден был заставить своих ОЕМов починить известные проблемы безопасности своих прошивок, организовать относительно нормальную цепочку доверия, следить за обнаруженными уязвимостями и исправлять их по мере сил. Вот это — очень ценно само по себе, даже если вместо Windows используется иная ОС.
Отличная инициатива, поддерживаю двумя руками, но пока что непонятно, насколько это все будет хорошо реализовано в реальном железе, а не в восторженных пресс-релизах.
Желание MS убрать прошивку из цепочки доверия понятно — они ее не контролируют толком, вендоров даже своих карманных (тем более тайваньских ОЕМов, которые выпускают львиную долю плат на рынке десктопов) не могут заставить реализовать все нужные им технологии защиты должным образом, но при этом вынуждены базировать свои весьма неплохие технологии защиты ядра через виртуализацию (которые они реализовали и отладили на Xbox 360 и Xbox One, вот отличный доклад Тони Чена) на очень непрочном фундаменте из говна и палок.
Конечному пользователю ОС это все не очень интересно, и ограничит его не очень сильно (кроме тех случаев, когда сам пользователь хочет патчить прошивку, аж кушать не может), зато потенциальному атакующему сильно усложнит жизнь (при условии, что в реализации не окажется чемодана багов, конечно).
DOS4/GW — это бесплатная ограниченная версия экстендера DOS/4G, которая поставлялась с набором компиляторов Watcom C/C++. Большая часть экстендеров для DOS реализовывало спецификацию DPMI 0.9 (некоторые поздние — 0.9 и 1.0), и по спецификации являлись DPMI host'ами, т.е. программами, предоставляющими интерфейс DPMI другим программам — клиентам (которые с его помощью получали доступ к защищенному режиму процессора, 32-битному режиму, плоской адресации памяти и другим плюшкам, недоступным изначально в основной ОС — DOS). На данный момент существует свободная и открытая альтернатива DOS4/G* — DOS/32A, если вам интересны подробности, можете почитать документацию к ней.
Именно поэтому управление питанием и частотами уже довольно давно выполняется софтом, а не железом, что у Intel (ICC стал частью ME с 7.х (Sandy Bridge+), PMC вынесли в отдельную от МЕ прошивку в 11.х (Skylake+), что у AMD (SMU, Piledriver+). VRM обычно не имеет своей полноценной прошивки, вместо этого он подключен к одной из системных шин вроде SMBUS, и управляется PMC/SMU напрямую.
Что означает магическая фраза «инициализация оборудования»?
После ресета или выключения питания все железо оказывается в начальном состоянии, в котором оно зачастую работать не может, и нуждается в дополнительной настройке прежде, чем его можно будет начать использовать. Вот эта настройка и называется инициализацией, т.е. приведением железа в его начальное рабочее состояние. Инициализация простого железа типа COM-порта укладывается в несколько строк на С, а вот железо посложнее, память оперативная, к примеру, или видеокарта — это уже совсем другой разговор и там иногда нужны десятки тысяч строк кода, чтобы железка заработала как задумано. Углубляться в эту тему можно бесконечно, и там целая отрасль знаний (platform bring-up) за этой простой фразой прячется.
Куда именно сохраняются и как именно применяются «настройки биоса» (путаница UI с собственно механизмом работы)?
Раньше сохранялись в CMOS SRAM, специальной энергозависимой памяти с батарейным питанием, но потом настроек стало достаточно, чтобы чипы SRAM такого объема стали слишком дорогими, и их заменили на SPI NOR (у которых 100к циклов перезаписи и с которых можно загружаться напрямую). Я уже писал про то, зачем нужна, и как устроена NVRAM вот тут.
БИОС именно из ПЗУ исполняется очень короткое время в самом начале, когда еще нет инициализированы ни оперативная память, ни L2 cache. Как только память доступна, прошивка копируется в нее и исполняется уже оттуда.
Как ОС выполняет 16-битный код: через трамплины, т.е. ОС вызывает прерывание (потому что 16-битный сейчас только старый интерфейс BIOS Interrupt Call), обработчик переводит процессор в 16 битный режим, выполняет 16-битный код БИОСа, затем возвращает режим в оригинальный, и передает управление вызывающему коду. Вся эта прыготня довольно медленная, и нужна исключительно системам, которые либо не умеют сами использовать оборудование (и потому полагаются на код БИОСа), либо не догадываются, что оборудования на самом деле нет (т.е. оно эмулируется БИОСом целиком).
Как ОС использует оборудование: качественные ОС ничему вообще не верят, и оборудование стараются переинициализировать самостоятельно, не надеясь на милость авторов БИОСа.
Что там с маппингом памяти и DMA?
А что с ними? В БИОСе была карта памяти e820, которую ОС нужно было использовать, чтобы не возникало конфликтов между памятью ОС и памятью БИОСа и устройств. В UEFI есть своя карта памяти, и нормальный аллокатор, успешно скрывающий большую часть управления памятью от разработчика UEFI-драйверов и загрузчиков. Про DMA там отдельная большая тема с IOMMU и Bus Mastering'ом, про которую нужно книгу писать, а не коммент.
Как именно процессор умудряется проснуться от сети (и от чего именно в сети)
Процессор просыпается не от сети, а от сигнала сетевого чипа (точнее, двух чипов, NIC и PHY, первый из которых спал ровно настолько, чтобы по прежнему следить за пакетами, а второй не спал вообще, а работал от дежурного напряжения). Wake-on-LAN — это специальный пакет с MAC-адресом, и если его прием настроен, то по его приходу NIC пошлет процессору сигнал по отдельной физической ноге.
Как биос умудряется доступиться до tftp при загрузке по сети?
Так же, как и любая другая ОС, у него либо в самой прошивке стек сетевых драйверов, либо весь стек вкомпилен внутрь PXE-загрузчика.
Если детали реально интересны, могу посоветовать литературу по firmware development и platform bring-up, а также чемодан даташитов на конкретное железо.
Значит, что-то все-таки делаете неправильно, или замыкаете не ту ногу, или делаете это слишком поздно. Посоветую отключить батарею, замкнуть, воткнуть зарядное, включить и загрузиться в UEFI Shell, все должно работать. Механизм этот чипсетный, и потому отключен быть не может (прошивка может отказаться стартовать с ним, но это другая история).
Все так делаете, только смотрите не туда немного.
Проверять надо той же утилитой MEInfo, только с параметром -FWSTS, если все сработало верно, то ME окажется отключенным, и дальше уже через Intel FPT можно шить и дескриптор, и регион МЕ. При этом все утилиты (в том числе MEInfo) продолжат рапортовать о том, МЕ защищен от записи, просто защита эта перестанет работать.
Thunderbolt, uh, does not expose PCIe lanes directly. Thunderbolt is an MPLS-like packet switching network that can encapsulate PCIe TLPs over a PHY and MAC without a spec, chips without documentation, and software with barely any support.
Раскрою немного мысль уважаемой WQ: Thunderbolt — это не PCIe, это хитрый способ получить доступ к нему. С точки зрения пользователя разницы немного, а вот в деталях разница колоссальная, к примеру, весь код hot plug и enumeration у ТБ свой собственный, и зачастую сделан настолько невыносимо отвратительно, что страшно становится.
SPISPY отличный проект, конечно, но пока что до коммерческих решений еще далеко довольно. Идея использовать DRAM для хранения прошивки интересная, но они с ним мучаются сейчас и в будущем продолжат мучаться дальше.
Тем временем, вот этому эмулятору скоро исполнится 10 лет, он отлично работает все эти годы в любых ОС (через эмуляцию USB Mass Storage), умеет логировать операции в файл на самом себе, и стоит не сказать, чтобы очень дорого.
Тем не менее, я очень рад, что появляются открытые аналоги профессиональных инструментов (пусть даже они сейчас на начальном этапе), потому что от этого выигрывают все.
Опять же, как будто кто-то ожидал что-то иное… Даешь всяким гражданам с горы доступ к ядру ОС — не удивляйся, что там теперь вакханалия, потому что граждане с горы решают свои собственные задачи максимально прямым и эффективным для них способом, а понять, что этот способ ломает всю модель безопасности — это надо быть специалистом по ней, и знать как эта самая модель выглядит, а специалисты эти — дорогие, и не хотят идти к китайским ОЕМам за миску риса.
Дорого это все очень, и продать потом очень трудно, потому что для обычного пользователя хватает «у нас точно все безопасное, мамой клянемся!» и «смотрите зато какая у нас RGB-подсветка моднючая!».
Непонятно, что именно непонятно.
Одного kernel virtual memory access хватит за глаза для поднятия привилегий до SYSTEM, если Virtualization-based security не включена. Запись в UEFI посредством MMIO access — это на сдачу уже.
Подписываешься на твиттер Дональда Трампа, и выставляешь все, что можно продать быстро, после очередного твита про тарифы и торговую войну. Вероятность успеть вовремя — довольно высокая, но таки да, математика предлагает страдать — значит надо страдать!
Если вам ничего этого не нужно — отлично, на рынке пока еще достаточно вендоров, у которых никаких крипточипов нет и не предвидится, если вам такие по душе — голосуйте за них рублем.
Кроме того, есть и вендоры, которые изначально нацелены на продвинутого пользователя и передают ему всю безопасность в руки, System76 или Raptor CS, например.
— написаной на языке, на котором критический для безопасности платформы код писать практически невозможно, потому что это требует нечеловеческой концентрации внимания.
— разрабатываемой кучей плохо связанных друг с другом вендоров, половина из которых вообще не выпускает никаких продуктов для конечного пользователя, а другая не имеет никакого понятия о том, как разрабатывать ПО (потому что они разрабатывают железо и продают его же), и не имеет штатных специалистов по безопасности вообще.
— сляпаной в спешке из копипасты и говнокода, т.к. практически все разработчики прошивок имеют крайне строгие дедлайны (привязанные к выходу новых процессоров, которые, внезапно, выпускает совсем другая компания, которой на ОЕМов наплевать) и потому вынуждены выпускать то, что получилось. При этом процессоры (одинаковые по сути, но разные по маркировке) выходят каждые 6-9 месяцев, и обновлять продукты ОЕМы вынуждены в том же цикле, т.е. на разработку и отладку прошивок банально нет времени, какая уж тут безопасность…
— имеющей древние неисправленные уязвимости, потому что цена ошибок при обновлении очень высока (сломанное железо, возврат по гарантии, недовольные пользователи) и сами обновления дороги (тестирование долгое и дорогое, повторная сертификация долгая жутко и дорогая до невозможности), обновления выпускаются либо очень поздно, либо вообще никогда, т.е. любые проблемы безопасности остаются неисправленными на реальном железе практически вечно.
Можно добавить еще десяток, но я опасаюсь за свои НДА…
По сути, MS вынужден был заставить своих ОЕМов починить известные проблемы безопасности своих прошивок, организовать относительно нормальную цепочку доверия, следить за обнаруженными уязвимостями и исправлять их по мере сил. Вот это — очень ценно само по себе, даже если вместо Windows используется иная ОС.
Желание MS убрать прошивку из цепочки доверия понятно — они ее не контролируют толком, вендоров даже своих карманных (тем более тайваньских ОЕМов, которые выпускают львиную долю плат на рынке десктопов) не могут заставить реализовать все нужные им технологии защиты должным образом, но при этом вынуждены базировать свои весьма неплохие технологии защиты ядра через виртуализацию (которые они реализовали и отладили на Xbox 360 и Xbox One, вот отличный доклад Тони Чена) на очень непрочном фундаменте из говна и палок.
Конечному пользователю ОС это все не очень интересно, и ограничит его не очень сильно (кроме тех случаев, когда сам пользователь хочет патчить прошивку, аж кушать не может), зато потенциальному атакующему сильно усложнит жизнь (при условии, что в реализации не окажется чемодана багов, конечно).
Раньше сохранялись в CMOS SRAM, специальной энергозависимой памяти с батарейным питанием, но потом настроек стало достаточно, чтобы чипы SRAM такого объема стали слишком дорогими, и их заменили на SPI NOR (у которых 100к циклов перезаписи и с которых можно загружаться напрямую). Я уже писал про то, зачем нужна, и как устроена NVRAM вот тут.
БИОС именно из ПЗУ исполняется очень короткое время в самом начале, когда еще нет инициализированы ни оперативная память, ни L2 cache. Как только память доступна, прошивка копируется в нее и исполняется уже оттуда.
Как ОС выполняет 16-битный код: через трамплины, т.е. ОС вызывает прерывание (потому что 16-битный сейчас только старый интерфейс BIOS Interrupt Call), обработчик переводит процессор в 16 битный режим, выполняет 16-битный код БИОСа, затем возвращает режим в оригинальный, и передает управление вызывающему коду. Вся эта прыготня довольно медленная, и нужна исключительно системам, которые либо не умеют сами использовать оборудование (и потому полагаются на код БИОСа), либо не догадываются, что оборудования на самом деле нет (т.е. оно эмулируется БИОСом целиком).
Как ОС использует оборудование: качественные ОС ничему вообще не верят, и оборудование стараются переинициализировать самостоятельно, не надеясь на милость авторов БИОСа.
А что с ними? В БИОСе была карта памяти e820, которую ОС нужно было использовать, чтобы не возникало конфликтов между памятью ОС и памятью БИОСа и устройств. В UEFI есть своя карта памяти, и нормальный аллокатор, успешно скрывающий большую часть управления памятью от разработчика UEFI-драйверов и загрузчиков. Про DMA там отдельная большая тема с IOMMU и Bus Mastering'ом, про которую нужно книгу писать, а не коммент.
Процессор просыпается не от сети, а от сигнала сетевого чипа (точнее, двух чипов, NIC и PHY, первый из которых спал ровно настолько, чтобы по прежнему следить за пакетами, а второй не спал вообще, а работал от дежурного напряжения). Wake-on-LAN — это специальный пакет с MAC-адресом, и если его прием настроен, то по его приходу NIC пошлет процессору сигнал по отдельной физической ноге.
Так же, как и любая другая ОС, у него либо в самой прошивке стек сетевых драйверов, либо весь стек вкомпилен внутрь PXE-загрузчика.
Если детали реально интересны, могу посоветовать литературу по firmware development и platform bring-up, а также чемодан даташитов на конкретное железо.
Проверять надо той же утилитой MEInfo, только с параметром -FWSTS, если все сработало верно, то ME окажется отключенным, и дальше уже через Intel FPT можно шить и дескриптор, и регион МЕ. При этом все утилиты (в том числе MEInfo) продолжат рапортовать о том, МЕ защищен от записи, просто защита эта перестанет работать.
Раскрою немного мысль уважаемой WQ: Thunderbolt — это не PCIe, это хитрый способ получить доступ к нему. С точки зрения пользователя разницы немного, а вот в деталях разница колоссальная, к примеру, весь код hot plug и enumeration у ТБ свой собственный, и зачастую сделан настолько невыносимо отвратительно, что страшно становится.
Тем временем, вот этому эмулятору скоро исполнится 10 лет, он отлично работает все эти годы в любых ОС (через эмуляцию USB Mass Storage), умеет логировать операции в файл на самом себе, и стоит не сказать, чтобы очень дорого.
Тем не менее, я очень рад, что появляются открытые аналоги профессиональных инструментов (пусть даже они сейчас на начальном этапе), потому что от этого выигрывают все.
Одного kernel virtual memory access хватит за глаза для поднятия привилегий до SYSTEM, если Virtualization-based security не включена. Запись в UEFI посредством MMIO access — это на сдачу уже.