Центральные процессоры (CPU) не могут ничего сделать, пока им не скажут, что делать. Возникает очевидная проблема — как вообще заставить CPU что-то делать? Во многих CPU эта задача решается при помощи вектора сброса — жёстко прописанного в CPU адреса, из которого нужно начинать считывать команды при подаче питания. Адрес, на который указывает вектор сброса, обычно представляет собой какую-нибудь ROM или флэш-память, которую CPU может считать, даже если никакое другое оборудование ещё не сконфигурировано. Это позволяет производителю системы создавать код, который будет исполнен сразу же после включения питания, сконфигурирует всё остальное оборудование и постепенно переведёт систему в состояние, при котором она сможет выполнять пользовательский код.
Конкретная реализация вектора сброса в системах x86 со временем менялась, но, по сути, это всегда были 16 байтов ниже верхушки адресного пространства, то есть 0xffff0 на 20-битном 8086, 0xfffff0 на 24-битном 80286 и 0xfffffff0 на 32-битном 80386. По стандарту в системах x86 ОЗУ начинается с адреса 0, поэтому верхушку адресного пространства можно использовать для размещения вектора сброса с минимальной вероятностью конфликта с ОЗУ.
Однако самое примечательное в x86 здесь то, что когда он начинает выполнять код из вектора сброса, он всё ещё находится в режиме реальной адресации (real mode). Real mode x86 — это рудимент гораздо более ранней компьютерной эпохи. Адреса не абсолютны (то есть, когда ты обращаешься к 32-битному адресу, то хранишь весь адрес в 32-битном регистре или регистре большего размера), это 16-битные смещения, прибавляемые к значению, хранящемуся в «сегментном регистре». Для кода, данных и стека существуют собственные сегментные регистры, поэтому 16-битный адрес может относиться к разным реальным адресам в зависимости от того, как он интерпретируется: переход на 16-битный адрес приведёт к тому, что этот адрес прибавляется к сегментному регистру кода, а считывание из 16-битного адреса приведёт к тому, что адрес будет прибавлен к сегментному регистру данных, и так далее. Всё это нужно для сохранения совместимости со старыми чипами, вплоть до того, что даже 64-битные x86 запускаются в real mode с сегментами и всем остальным (и тоже начинают исполнение с 0xfffffff0, а не с 0xfffffffffffffff0 — 64-битный режим не поддерживает real mode, поэтому 64-битный физический адрес невозможно выразить при помощи сегментных регистров, и мы всё равно начинаем сразу ниже 4 ГБ, даже несмотря на то, что доступно гораздо большее адресное пространство).
Ну да ладно, это знают все. В современных системах UEFI-прошивка, запускаемая из вектора сброса, перепрограммирует CPU во вразумительный режим (то есть без всей этой фигни с сегментацией), выполняет различные действия, например конфигурирует контроллер памяти, чтобы можно было получить доступ к ОЗУ (при этом процессе кэш CPU используется как ОЗУ, потому что программирование контроллера памяти — довольно сложная задача, ведь нужно хранить больше информации о состоянии, чем поместится в регистрах, то есть необходимо ОЗУ, но у нас нет ОЗУ, пока не заработает контроллер памяти; к счастью, у CPU есть много собственных мегабайтов ОЗУ, так что можно вздохнуть с облегчением). Это довольно криво, но таковы последствия хорошо понятных легаси-решений.
Впрочем… на самом деле, всё не так. Современный Intel x86 запускается иначе. Всё гораздо страннее. Да, кажется, что именно так всё и происходит, но за кулисами выполняется множество других действий. Давайте поговорим о безопасности запуска. Принцип любого вида верифицируемого запуска (например, UEFI Secure Boot) в том, что подпись на следующем компоненте цепочки запуска валидируется до исполнения компонента. Но что верифицирует первый компонент цепочки запуска? Нельзя просто попросить BIOS проверить саму себя — если нападающий сможет заменить BIOS, то его версия BIOS просто соврёт о том, что это сделано. Intel решила эту проблему с помощью Boot Guard.
Но прежде чем мы доберёмся до Boot Guard, нам нужно обеспечить работу CPU в максимально свободном от багов состоянии. Поэтому при своём запуске CPU исследует флэш-память системы и ищет заголовок, указывающий на обновления микрокода CPU. В комплекте CPU компании Intel есть встроенный микрокод, но часто он старый и забагованный, поэтому прошивка системы может решить включить копию, которая достаточно новая, чтобы надёжно работать. Образ микрокода копируется из флэш-памяти, проверяется подпись и новый микрокод начинает работать. Это справедливо и с использованием Boot Guard, и без него. Однако в случае Boot Guard перед переходом к вектору сброса микрокод в CPU считывает из флэш-памяти Authenticated Code Module (ACM) и проверяет его подпись с прописанным Intel ключом. Если они совпадают, он начинает исполнять ACM. Здесь следует помнить, что CPU не может просто верифицировать ACM, а затем исполнить его непосредственно из флэш-памяти: если бы он сделал это, то флэш-память могла бы распознать это, передавать для верификации подлинный ACM, а затем передать CPU другие команды при их повторном считывании для исполнения (уязвимость Time of Check vs Time of Use, или TOCTOU). То есть перед верификацией и исполнением ACM его нужно скопировать в CPU, то есть нам необходима ОЗУ, то есть CPU уже нужно знать, как сконфигурировать свой кэш, чтобы можно было использовать его в качестве ОЗУ.
Ну да ладно. Теперь мы загрузили и верифицировали ACM, после чего его можно спокойно исполнить. ACM выполняет разные вещи, но самое важное с точки зрения Boot Guard заключается в том, что он считывает набор фьюзов с однократной записью на чипсете материнской платы, представляющий собой SHA256 публичного ключа. Затем он считывает первый блок прошивки (Initial Boot Block, или IBB) в ОЗУ (точнее, как говорилось выше, в кэш) и парсит его. В нём есть блок, содержащий публичный ключ — он хэширует этот ключ и верифицирует, что он соответствует SHA256 из фьюзов. Затем он использует этот ключ для валидации подписи на IBB. Если всё правильно, он исполняет IBB, и всё начинает выглядеть как красивая простая модель, о которой мы говорили выше.
Только не кажется ли вам, что весь этот код чрезвычайно сложно реализовать в real mode? И да, выполнение всех этих расчётов современной криптографии только с 16-битными регистрами было бы очень мучительной задачей. Поэтому всё происходит не так. Всё это происходит в абсолютно вразумительном 32-битном режиме, а после этого CPU на самом деле переключается в ужасную конфигурацию, чтобы сохранить совместимость с 80386, выпущенным в 1986 году. «Хорошая» новость в том, что хотя бы прошивка может определить, что CPU уже конфигурировал кэш как ОЗУ и может не делать этого самостоятельно.
Здесь я пропускаю несколько этапов — на самом деле ACM выполняет и другие задачи: проверяет прошивку в TPM и настраивает TXT для тех, кому нужен DRTM, но если вкратце, то CPU переводит себя в состояние, в котором он работает как современный CPU, а затем намеренно снова отключает кучу удобной функциональности, прежде чем начать исполнять прошивку. Также я опускаю тот факт, что весь этот процесс запускается только после того, как разрешит Management Engine, а это означает, что мы ждём, пока полностью независимый x86 запустит всю ОС, прежде чем CPU хотя бы начнёт притворяться, что исполняет прошивку системы.
Разумеется, как говорилось выше, в современных системах прошивка потом перепрограммирует CPU во что-то более вразумительное, поэтому разработчикам ОС больше не нужно об этом волноваться [1][2]. Это значит, что мы перескакивали между несколькими состояниями только из-за вероятности того, что кто-то захочет запустить легаси-BIOS, а затем загрузить DOS на CPU, в котором на пять порядков больше транзисторов, чем в 8086.
Почему мой x86 не может пробудиться с уже имеющимся у него protected mode.
[1] Только при resume ACPI мы пропустим основную часть кода настройки прошивки, поэтому нам придётся работать с CPU в чёртовом 16-битном режиме, потому что suspend/resume — это, по сути, чрезвычайно долгий цикл перезапуска
[2] А, да, и ведь скорее всего, у вашего CPU несколько ядер: и плохие новости, связанные с состоянием, заключаются в том, что большинство ядер при запуске ОС прошивка не запускает, поэтому они будут находится в 16-битном real mode, даже если запускаемый CPU уже находится в 64-битном protected mode; немного иная кошмарная ситуация возникает, если вы использовали TXT. Точнее, так было раньше, но в ACPI 6.4 (выпущенном в 2021 году) есть механизм, позволяющий ОС просить прошивку разбудить CPU так, что это будет невидимо для ОС, но в таком случае прошивке всё равно придётся выполнять множество сложных задач.
Комментарии (48)
Sun-ami
20.04.2023 08:32+7Интересно, а кто-нибудь пробовал использовать устаревшие процессоры для десктопных ПК в качестве микроконтроллеров для DIY-проектов? Ведь на вторичном рынке можно купить такие процессоры по совершенно копеечным ценам, при этом они гораздо мощнее микроконтроллеров, и имеют много ОЗУ. К примеру, Athlon X2 3200+ 2 GHz можно купить всего за 1 доллар, при этом у него 640 кбайт ОЗУ, и 2 ядра. Проблему высокого потребления энергии и тепловыделения можно решить снижением частоты и напряжения питания. Думаю, можно добиться работы без радиатора, и подключения всего нескольких десятков выводов, что позволит обойтись 2..4-слойной платой.
vfreeeman
20.04.2023 08:32+9Скорее всего реализовать обвеску будет намного дороже 1 доллара. Начиная с сокета, ПЗУ (или где будет храниться исполняемый код?), USB-интерфейс для прошивки. Как отлаживать?
Sun-ami
20.04.2023 08:32Сокет не нужен — Athlon можно просто запаять, у него есть подходящие ножки. SPI-ПЗУ стоят копейки, вопрос, как их подключить. Отлаживать можно на частично на десктопе, частично через UART-консоль.
jar_ohty
20.04.2023 08:32+11Ну, одним процессором там не обойдется. У процессора нет внешних устройств. Никаких вам GPIO, USART, SPI и т.п. У него, если повезет, есть контроллер памяти, к которому подключается ОЗУ, и у него есть шина, специфичная для данного конкретного семейства. И еще есть куча питаний и куча вспомогательных, но нужных для запуска сигналов. Чтобы со всем этим работать, нужен еще чипсет - набор системных контроллеров (северный и южный мосты плюс всякая обвязка, в более поздних - единый однокристальный хаб), откуда уже появляется набор "общеупотребительных" шин, интерфейсы для накопителей и периферии, интерфейс для флешки биоса и мультиконтроллера, некоторое количество GPIO и "служебных" интерфейсов (SPI, I2C, SMB, JTAG). Так вот, без чипсета к процессору даже флешку подключить некуда. Это вам не Z80 и даже не 68000, где в принципе нужную обвязку можно было на россыпи логики сколхозить. Так что использование в качестве МК старого "Атлона" в обязательном порядке тянет в конструкцию материнскую плату под него. То, что в народе зовется "мамоконтроллер".
Samodelkin333
20.04.2023 08:32+1Согласен, получается геморрой с двумя Р и одной ОЙ. Это не 386 или 286 (?) DNM Vortex. Z80 или 68k проще, но малоинтересны на этот момент. Если честно я не спец по этой теме.
Sun-ami
20.04.2023 08:32+1Можно попытаться подключить вместо северного моста дешевый микроконтроллер со всей нужной периферией, вроде STM32G030C, или STM32F030C. А на процессоре реализовать, к примеру, локальное распознавание речи при помощи небольшой нейросети. Ведь Athlon X2 3200+, к примеру, поддерживает SSE3. Наличие нескольких напряжений питания — это плюс, это позволяет легче подключить его к другим микросхемам, ведь напряжению питания интерфейсов не нужно быть очень низким вместе с питанием ядер для того, чтобы процессор не сильно много потреблял и не сильно нагревался. Для питания процессора, наверное, можно использовать стабилизатор с неисправной материнской платы — они тоже очень дёшевы, и на материнских платах обычно выходит из строя южный мост.
jar_ohty
20.04.2023 08:32Эээээ, вы собираетесь подключать STM32F030C к каналу HyperTransport с тактовой частотой 1 ГГц?
Sun-ami
20.04.2023 08:32HyperTransport по стандарту может работать и на частоте 200 МГц. А если снизить базовую тактовую частоту процессора в 6,5 раз, то эти 200 МГц превратятся в 30 Мгц — тут STM32F030C уже может справиться, если постараться.
corvair
20.04.2023 08:32+1использование в качестве МК старого "Атлона" в обязательном порядке тянет в конструкцию материнскую плату под него.
Короче, в любом случае приходим к обычному настольному ПК на базе этого старого "Атлона" и наша самоделка становится периферией к нему, вот вам и использование устаревшего ЦП в качестве "микроконтроллера" :).
engine9
20.04.2023 08:32Энтузиасты делают на основе старых десктопных плат контроллеры для станков с ЧПУ.
Dimsml
20.04.2023 08:32+1Ну, одно время десктопные процессоры можно было найти в виде контроллера в каком-нибудь девайсе, те же ядра Motorola 68K были популярны в виде микроконтроллеров, да и клоны от 86 до Pentium выпускались какой-нибудь кампанией с Тайваня, вот вам например кухонный девайс на клоне то ли 486, то ли Первопня:
https://www.youtube.com/watch?v=BdSJgoP2a88
Да и вообще старые процессоры можно хоть на breadboard развести:
https://www.youtube.com/watch?v=wSiDSdHS2QQ
Если вы имеете в виду современное десктопное железо, то я думаю там будет очень много геморроя, как описано в статье, где микроконтроллер конфигурирует микропроцессор чтобы тот запустил сам себя в нужном режиме. Я как-то смотрел описание того, чем занят мультиконтроллер в ноутбуке, и у него есть своя внутренняя прошивка и без неё ничего не заработает. Короче, мрак.
sepuka
20.04.2023 08:32+2Как разработчик такой электроники и параллельно делатель своих DIY проектов кратко могу сказать, что скорее отрежу себе руку. Да, массовые CPU хорошо оптимизированы для разводки на минимальном количестве слоёв. В граммах это означает, что такая плата разводится примерно вдвое быстрее, чем аналогичное по сложности решение на FPGA, потому что во время оптимизации чипа кто-то когда-то делал несколько итераций тестовых плат, где задачей было вместо 24 слоёв ограничиться 6 и добиться того, чтобы почти все интерфейсы можно было вывести только на TOP/BOTTOM, т.е. в пределе вроде БЫ могло БЫ хватить 4 слоя. В реальности есть ещё питание и signal integrity, реалистично развестись на 6-8 слоях. По цене изготовления такие платы, конечно, подешевели на порядки, но не так сильно, чтобы войти в категорию DIY. Реалистичный сценарий -- вставить в родную мамку и накатить любимую ОС. Для DIY задач, которые теоретически могут потребовать такие решения, есть SOC модули, для них достаточно развести только свою плату для интерфейсов. Вот там да, достаточно часто хватает 4 слоёв.
Axino
20.04.2023 08:32И для материнских плат нижнего ценового сегмента поколения Core2 4 слоев хватало, как ни странно. При достаточно сложной системе питания и интерфейсов памяти и PCIe.
При таком использовании, кмк, сразу есть ещё две проблемы: такие процессоры могли не быть приспособлены к работе с внешними IO без обязательного комплекта периферии и детальную документацию на разработку печатных плат тоже практически не достать.
Sun-ami
20.04.2023 08:32Проблемы с signal integrity возникнут, если интерфейсы будут работать на штатных частотах. Но ведь скорее всего частоты интерфейсов тоже можно снизить до десятков мегагерц, и тогда на 4 слоях должно работать.
sepuka
20.04.2023 08:32+1В таком случае напаркуа Athlon X2 3200+?
Sun-ami
20.04.2023 08:32Я уже написал выше — например, чтобы распознавать речь при помощи нейросети. Для того, чтобы передать процессору голос, параллельной шины и десятков мегагерц вполне достаточно. А ядра будут работать, скажем, на 500 МГц, что вместе с SSE3 и быстрой памятью даст хорошую производительность на такой задаче.
HardWrMan
20.04.2023 08:32+4Напомнило проект из 00х:
К сожалению, 10+ лет назад не удалось связаться с автором, который делал этот проект как студенческую лабораторную. Однако, энтузиастами форума NedoPC удалось "восстановить" примерную, вероятную но теоретически рабочую схему данного устройства:
Прошивку на него достать, конечно, нет возможности.
Наверное, 486 самый мощный процессор из всей линейки, которую радиолюбитель сможет запустить в любительском проекте с минимальной обвязкой.
DBalashov
20.04.2023 08:32+3Сейчас проще брать raspberry (и десятки других аналогов) вместо вот такой "минимальной" обвязки.
HardWrMan
20.04.2023 08:32+1Всё дело лишь в том, что является ли малинка "устаревшим процессором для десктопных ПК" который предполагается использовать "в качестве микроконтроллеров для DIY-проектов".
Zenj
20.04.2023 08:32Кажется, последние версии АРВИД были на 80286...
HardWrMan
20.04.2023 08:32Вам действительно кажется. Хоть все версии АРВИД были строго для шины ISA16, но последняя модель выпущена в 1995 году, а согласно вики ПО существует для операционных систем DOS и Windows вплоть до Windows XP SP3, а также Linux, FreeBSD и OS/2. Сам лично видел как чел работал с ним на AMD K5 под Windows 95.
nikolz
20.04.2023 08:32Мечтать не вредно, но бесполезно. Этот процессор на eBay стоит в 34 раза дороже.
Sun-ami
20.04.2023 08:32А на OLX — меньше доллара https://www.olx.ua/d/obyavlenie/protsessor-amd-athlon-x2-3200-soket-am2-IDQyose.html
nikolz
20.04.2023 08:32ссылка битая.
Sun-ami
20.04.2023 08:32У меня в Германии открывается
nikolz
20.04.2023 08:32А сколько в Германии стоит сокет для этого процессора? И во сколько Вам обойдется плата и монтаж на нее сокета либо процессора?
Затем встанет вопрос о софте и IDE
В итоге проще взять SoC за 10 баксов, который по BLE может годами работать от батарейки, чем что-то городить на этом барахле.
Sun-ami
20.04.2023 08:32+1Я уже писал выше, что сокет не нужен — процессор можно запаять обычным паяльником, и плата нужна не такая сложная как материнка десктопа — потому что частоты можно использовать гораздо более низкие, и не много выводов.
follow_me8
20.04.2023 08:32А что будет если провести атаку MITM на SHA256 публичного ключа и подменить сам ключ в IBB ? позволит ли это загрузить скомпрометированную прошивку ?
104u
20.04.2023 08:32А как вы себе это представляете, если всё так, как описано? Если хэш ключа действительно намертво прибит к чипсету, то остаётся только брать паяльник, а после этого смысл этой атаки неясен
follow_me8
20.04.2023 08:32то есть , смысл в атаке TOCTOU , от которой защищаются есть , хотя там нужно выпаять флешку и поставить эмулятор флеш памяти , а атака MITM бесмысленна ?
104u
20.04.2023 08:32Возможно, я неверно вас понял. Что мы добиваемся, подменив ключ? Загружаем левый образ в secure boot? Но если у нас уже есть физический доступ к компу, не проще ли, к примеру, встроить какую-нибудь вирусню в uefi? Чипсет и проц, насколько помню, общаются через pci-e (поправьте, если не так), то есть нужно найти эти дороги, перерезать, между чипсетом и процом поставить другой контроллер, который в определённый момент подменит ключ, всё так? Идея реальна, если дороги не в каком-нибудь 3-4 слое 8 слойной платы, но от такого типа атак никак не защититься, разве что затолкать чипсет/ключ в проц
Brak0del
20.04.2023 08:32+1то есть , смысл в атаке TOCTOU , от которой защищаются есть , хотя там нужно выпаять флешку и поставить эмулятор флеш памяти , а атака MITM бесмысленна ?
Для TOCTOU эмулятором флэш-памяти может быть простая ПЛИС с несложной прошивкой, которую может написать студент.
Для вашей первоначальной задумки с MITM нужно обойти не только фьюзы, но и криптографию. В других статьях пишут, что фьюзы располагаются внутри отдельного интеловского чипа (ME), прошивка которого подписана и в котором есть ключ. Т.е. как минимум в теории исходный интеловский чип и ME могут установить защищённый канал со взрослой криптографией и обменяться произвольной инфой.
104u
20.04.2023 08:32Про эмулятор флэш как с языка сняли
Кстати, по вашей же ссылке интересная инфа, что зловред, в теории, (если производитель оборудования такое допустил) может прописать свой собственный ключ, после чего фиг что загрузишь
follow_me8
20.04.2023 08:32Для MITM на PCIe может быть простая ПЛИС с несложной прошивкой, которую может написать студент, в этом нет ничего сложного
О победе над какой криптографии вы говорите ? сейчас вопрос о полном обходе этой криптографии , существующий ключ подменяется известным , но система его не примет, потому что его SHA256 не совпадает с тем что в чипсете, но имея ключ мы можем подсчитать SHA256 и подменить на корректную для нас на летуIntel ME это подсистема в чипсете , и не имеет значения кто хранит фьюзы до тех пор пока их нужно передавать в процессор для сравнения.
По поводу проблемы с 8-10-16 слойными платами , возможен вариант как реализуют сейчас китайцы процессоры "мутанты", когда они делают из текстолита переходник в десктопный сокет поверх которого сокет мобильный к которому припаивают процессор. Такого рода переходник можно сделать сразу с плис на борту с питанием и даже разъемом для отладки
104u
20.04.2023 08:32Полагаю, автор предыдущего комментария имел в виду это
Intel ME boot ROM is implicitly trusted as the root.
ME ROM with proper fuses blown verifies ME firmware with Intel's key
ME firmware passes security policy and OEM key to Intel CPU
CPU boot ROM is implicitly trusted and it verifies the ACM with Intel's key
ACM verifies IBB with OEM key from ME firmware
Intel ME boot ROM is implicitly trusted as the root
При таком раскладе подмена ключа действительно ничего не даст, поскольку ключ в чипсете зашифрован OEM ключом, находящимся в ME (который я не понял, на каком этапе и кто зашивает)
И для чего, в итоге, мы проводим такую атаку? Можно и к выводам ОЗУ подключиться, можно к sata, pci-e, смысл-то какой? Левую флешку (которая на самом деле микроконтроллер) можно припаять, так что никто не заметит подвоха, а что с этим бутербродом?
P,S, наверное, ключ чипсета шифруют тоже приватным ключом, а расшифровывают публичным, но это не точно. Надо звать экспертов
follow_me8
20.04.2023 08:32Смысл очень большой , в Intel CPU есть так называемый security enclave который позволяет выполнять защищённый код с проприетарными данными которые можно было бы утащить или ключи шифрования проприетарного контента , которые полагаются на то что вы не сможете достать декодированный поток из CPU
по поводу кто кого загружает - то там загрузка туда-сюда бросает
ещё любопытное чтиво на тему зачем взламывать компьютер к которому у вас есть физический доступ
https://habr.com/ru/companies/pt/articles/430132/
и104u
20.04.2023 08:32Почитал про эти enclave, вероятно, я опять не понял, что вы имеете в виду, но ведь если вся память и код шифрованы в этом режиме, что поменяет подмена ключа?
Статьи интересные, тем, кто смог такое провернуть — отдельный респект, всё смогли взломать даже без паяльника
follow_me8
20.04.2023 08:32Вы опять смотрите со стороны грубой силы , подмена ключа позволит коду выдать себя за авторизованный на самом низком уровне цепочки доверия, что впоследствии позволит внедрить свой код внутрь анклава , который уже оттуда будет сливать ценные данные
104u
20.04.2023 08:32Но ведь энклавы, вроде бы, изолированы друг от друга? С другой стороны, прочитал и про случаи, где удавалось вытаскивать данные через какие-то уязвимости. А в чём будет разница между вредоносным анклавом, который создан через ОС и тем, что создан через ME? (вроде как для ME нет никаких привилегий в анклавах, или же нет?)
P.S. Зря я полез в эту тему, надо было разобраться сначала
thevlad
20.04.2023 08:32Так прошивка, ME модуля где хранится? В той же spi-флэшке, так же как и вся не тривиальная криптография которая на этом модуле выполняется. Раньше насколько я помню, проблема подмены была в том, что таблицы Хафмана для декодирования были прошиты прямо в железке ME.
104u
20.04.2023 08:32Ага, вы правы, я уже совсем запутался в этой системе, где какие ключи, прошивки, и кто, что и когда делает. Сейчас перечитал всё ещё раз — теперь понятно вроде
CodeRush
20.04.2023 08:32Соседняя статья про плюс-минус то же самое (кучно пошло в этот раз): https://habr.com/ru/articles/730240/
Про MITM - посмотрите вот эту презентацию, она как раз про MITM-атаку через эмулятор SPI-флеша и про то, что именно BootGuard сломать не вышло - его писали люди, которые в курсе, а вот все, что было сразу за ним - сломалось без проблем.
amberovsky
20.04.2023 08:32Возникает вопрос - зачем современному десктопному CPU режим совместимости не то, чтобы с x86, а даже с реальным режимом x86?
HardWrMan
20.04.2023 08:32Легаси же. Вы всё ещё способны загрузить на него DOS.
amberovsky
20.04.2023 08:32Зачем это на десктопе? Чтобы запустить fdisk с дискетки?
HardWrMan
20.04.2023 08:32Представьте себе да. Была же попытка сбросить легаси в IA-64 в серверном сегменте,. Однако всё равно всё скатилось до AMD64 (EM64T), который легаси это подхватил. Наверное, рыночек порешал.
hedger
https://binarydebt.wordpress.com/2018/10/06/how-does-an-x86-processor-boot/ - детальная статья о x86 загрузке на относительно устаревших процессорах, с тонкостями от проекта coreboot. Более подробно рассказано о этапах инициализации памяти, кэша и передаче управления между ними.