Все, что не находится прямо на чипе, можно выпилить при наличии сильного желания, пары хороших специалистов и некоторого количества времени. В данном же случае для двухчиповых решений для избавления от МЕ придется разрабатывать собственный PCH, а для SoC — смиряться и получать удовольствие. В конце концов, можно купить сервер на Intel Xeon без iDRAC и iLO, а вот без ME — уже нет.
Принципиально — уровнем интеграции. Карту IPMI можно вынуть или отключить от питания, BMC выпаять с платы и выпатчить его инициализацию из прошивки, а здесь приходится либо мириться с тем, что МЕ есть и будет есть, либо платить Intel кучу денег за его отключение, которое все равно не совсем полное.
Integrated Clock Control (управление частотами и разгон)
Firmware TPM (программный TPM 2.0, появился недавно)
Protected Audio-Video Path (защита медиаконтента от перехвата во время просмотра, DRM в общем)
Dynamic Application Loader (загрузка и исполнение подписанных Intel Java-апплетов)
Все остальное — зависит от OEM, кто-то покупает еще модулей, а кто-то старается от DAL и PAVP избавиться.
Никакие возможности MEBx и удаленного администрирования декларируются недоступными для Consumer-вариантов ME, но что там по факту — знают 3,5 специалиста из Intel.
Отличная обзорная статья, спасибо.
Рад, что с 2009 года никаких серьезных уязвимостей в МЕ не нашли, спасибо SeCoE за это. С другой стороны, грустно, что приходится слепо доверять неизвестному коду, имеющему слишком большие привилегии и при этом наглухо закрытому даже от анализа.
Если вам не нравятся процессоры с подобными "подсистемами обеспечения безопасности" — у AMD еще есть десктопные процессоры без PSP, а вот последним ноутбучным было семейство eKabini, все более новые SoC серии Falcon — уже даже память через PSP тренируют и S3 resume им же делают, так что там теперь еще большее болото, чем с ME у Intel.
А вот тут уже не смешно, на самом деле. Именно так работает 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.
Все остальное — зависит от OEM, кто-то покупает еще модулей, а кто-то старается от DAL и PAVP избавиться.
Никакие возможности MEBx и удаленного администрирования декларируются недоступными для Consumer-вариантов ME, но что там по факту — знают 3,5 специалиста из Intel.
Рад, что с 2009 года никаких серьезных уязвимостей в МЕ не нашли, спасибо SeCoE за это. С другой стороны, грустно, что приходится слепо доверять неизвестному коду, имеющему слишком большие привилегии и при этом наглухо закрытому даже от анализа.
Если вам не нравятся процессоры с подобными "подсистемами обеспечения безопасности" — у AMD еще есть десктопные процессоры без PSP, а вот последним ноутбучным было семейство eKabini, все более новые SoC серии Falcon — уже даже память через PSP тренируют и S3 resume им же делают, так что там теперь еще большее болото, чем с ME у Intel.
Делать fseek на результат ftell можно в любом случае, а вот на SEEK_END — уже UB, У вас же получается, что там UB во всех случаях.
На самом деле, все современные x86-процессоры, кроме, возможно, Intel Quark, работают таким же образом, только кэш имеют внутренний, а сама трансляция выполняется их микрокодом.
Все остальное, в том числе и Apple — в разной степени дырявое, где-то меньше (Lenovo), где-то больше (ASUS, MSI, Apple), где-то совсем дуршлаг (Acer). При одинаковом бюджете я бы взял для работы хорошую машину Dell.