А вот тут уже не смешно, на самом деле. Именно так работает ACPI-таблица WPBT, поддержка которой добавлена заботливыми IBV еще в 2012 году. Т.е. устанавливаете вы на новенький сервер очередную Windows Server, и она у вас при первой загрузке достает из прошивки подготовленные производителем код и выполняет его. Самостоятельно и незаметно. Так что смеяться над китайскими прошивками с бэкдором нужно только после того, как удостоверились, что именно такая вам не досталась.
А почему SMARC 1.1, если не секрет? Сам по себе стандарт уже на грани устаревания, со дня на день выйдет SMARC 2.0, а для процессора такого размера плату можно сделать и на QSeven, и на COM-Express Type10/Type6 Compact.
Только не сам UEFI, а его shell. Диспетчер BDS позволяет запускать пользовательские приложения вместо загрузчиков, все остальное — это уже сам UEFI Shell реализует, от UEFI там только сервисы и прямой доступ к еще не выгруженным драйверам и протоколам.
Только она теперь и представлена, по больше части. Исключения крайне редки — хромобуки с coreboot, да машины Apple с EFI 1.10, все остальное — UEFI 2.1+ начиная с систем на чипсете P67.
Если коротко, то да, но только если производитель вашей платформы предоставляет соответсвующий драйвер. В произвольной реализации UEFI — скорее всего нет.
Тот самый случай, когда "не в лотерею, а в карты, и не выиграл, а проиграл."
Неопределенное поведение там не в смысле стандарта, а в смысле "непонятно, что будет, иногда работает, иногда нет".
Наблюдается такое поведение не у бинарных, а у текстовых файлов.
The ftell function obtains the current value of the file position indicator for the stream pointed to by stream. For a binary stream, the value is the number of characters from the beginning of the file. For a text stream, its file position indicator contains unspecified information, usable by the fseek function for returning the file position indicator for the stream to its position at the time of the ftell call; the difference between two such return values is not necessarily a meaningful measure of the number of characters written or read.
И не получит уже, скорее всего. Консорциум распущен в 2009, на смену пытаются прикрутить RT Ethernet, т.к. вышло очень дорого, а некоторые устройства, прекрасно смотревшиеся на бумаге и имевшие прототипы в авиации (Bus Guardian, например), так и не были реализованы, т.к. это оказалось слишком дорого.
Магия там, как раз, вполне себе белая, только вот с тех пор лучше не стало, к сожалению. С проблемой с UCS2 добрые люди вроде defuz уже помогли, осталось найти достаточно времени, чтобы сесть и написать какой-нибудь минимально полезный DXE-драйвер на Rust, не увлекшись при этом переписыванием чего-нибудь адски сложного, вроде драйвера для PCIe или USB. Статью уже обещал, теперь не отвертеться. :)
Процессор транслирует опкоды x86 в свое внутрее представление, и только затем исполняет. Карта памяти нужна, скорее всего, для кеширования определенных часто исполняющихся последовательностей, чтобы не выполнять трансляцию каждый раз и выиграть немного в производительности.
На самом деле, все современные x86-процессоры, кроме, возможно, Intel Quark, работают таким же образом, только кэш имеют внутренний, а сама трансляция выполняется их микрокодом.
Молодцы, конечно, только вот uefi-firmware-parser, который там под капотом — пока еще не очень хорош в деле разбора разных экзотических вариантов, но мы с Тедди постараемся это допилить понемногу.
Посмотрите слайды с моей презентации на ZeroNights, там я как раз исследовал типичный Acer. Они такие все, и производитель вообще не реагирует ни на инциденты, ни на сообщения об уязвимостях.
Если вам интересно качество прошивок и безопасность pre-boot окружения — выбирайте между Dell и HP.
Все остальное, в том числе и Apple — в разной степени дырявое, где-то меньше (Lenovo), где-то больше (ASUS, MSI, Apple), где-то совсем дуршлаг (Acer). При одинаковом бюджете я бы взял для работы хорошую машину Dell.
Вставки — это хорошо, но решение MS не поддерживать ключевое слово __asm в 64-битном режиме компиляции в MSVC и требования совместимости отучили от вставок и разработчиков, поэтому сейчас я весь код на ассемблере выношу в отдельные файлы .asm/.s и вызываю как обыкновенные функции с соглашением MS x64.
LLVM — ничего страшного, если вставки работают правильно, то их хватит.
Про стек — я так и думал, и меня такой ответ вполне устраивает. Большое спасибо.
Без стека можно писать на ассемблере, используя для хранения переменных регистры, а для передачи управления — ближние и дальние переходы. На С писать по настоящему без стека нельзя, конечно, но можно минимизировать его использование, тоже передавая параметры через регистры и заменяя вызовы через call на переходы, ядро PEI и некоторые ранние модули так и работают. Конечно, это уже не совсем C, но я готов и на «не совсем Rust», была бы возможность. Если нет — тоже не беда, весь этот кусок можно писать как раньше, кода там совсем немного.
Торжественно обещаю Хабру попробовать написать DXE-драйвер на Rust, несмотря на пару неудачных попыток ранее. Язык выглядит действительно вкусно для написания компонентов прошивки, не являющихся критически важными, но при этом имеющими большую и запутанную кодовую базу, к примеру — драйверов PCIe и USB, которым по 5 лет уже, а баги в них до сих пор вылезают постоянно, и конца этому процессу не видно.
К знатокам такой вопрос: можно писать на Rust без стека? А без кучи? А есть у вас все содержимое памяти — read-only, кроме стека (так происходит, если исполнять PEI-модули прямо из SPI-чипа, не копируя в оперативную память, которой пока еще нет, а стек выделять из кэша второго уровня в Non-Eviction Mode)? На С — можно, если можно и на Rust — на нем можно будет написать UEFI-совместимую прошивку, минимально разбавив ассемблером. Если нет — значит, только некоторые ее компоненты.
По поводу работы без отладчика — половина реального процесса BIOS development / board bring-up проходит без отладчика, т.к. подключение текстового вывода в UART, не говоря уже об отладке на уровне исходного кода, сильно замедляет загрузку и сбивает все тайминги. Иногда это вполне терпимо, но в других случаях — совершенно неприемлимо. Если вмешиваться в процесс загрузки релизной прошивки нельзя, а отлаживать её надо, единственным доступным средством является включение декодирования порта CPU IO 0x80 на LPC или PCI и сбор последовательности POST-кодов.
Делать fseek на результат ftell можно в любом случае, а вот на SEEK_END — уже UB, У вас же получается, что там UB во всех случаях.
На самом деле, все современные x86-процессоры, кроме, возможно, Intel Quark, работают таким же образом, только кэш имеют внутренний, а сама трансляция выполняется их микрокодом.
Все остальное, в том числе и Apple — в разной степени дырявое, где-то меньше (Lenovo), где-то больше (ASUS, MSI, Apple), где-то совсем дуршлаг (Acer). При одинаковом бюджете я бы взял для работы хорошую машину Dell.
LLVM — ничего страшного, если вставки работают правильно, то их хватит.
Про стек — я так и думал, и меня такой ответ вполне устраивает. Большое спасибо.
К знатокам такой вопрос: можно писать на Rust без стека? А без кучи? А есть у вас все содержимое памяти — read-only, кроме стека (так происходит, если исполнять PEI-модули прямо из SPI-чипа, не копируя в оперативную память, которой пока еще нет, а стек выделять из кэша второго уровня в Non-Eviction Mode)? На С — можно, если можно и на Rust — на нем можно будет написать UEFI-совместимую прошивку, минимально разбавив ассемблером. Если нет — значит, только некоторые ее компоненты.