Обновить
312
0
Николай Шлей@CodeRush

Firmware Security Engineer

Отправить сообщение
Для безопасного использования внешних PCIe-устройств необходима поддержка, правильная настройка и использование IOMMU (у Intel он называется VT-d, поддерживается далеко не всеми процессорами, требуется для защиты от доступа к физической памяти ПК при помощи DMA, инициированного прошивкой внешнего PCIe-устройства) и SecureBoot (чтобы защитить систему от загрузки вредоносного Option ROM во время старта).
А теперь поднимите руки, у кого обе эти технологии хотя бы включены, я уже не говорю про правильно настроены…
Классная станция, дай ТНБ каждому ремонтнику такую.
Понятно, что настоящие джедаи умудряются проделать то же самое в гараже, используя строительный фен и помощь такой-то матери, но с хорошим инструментом и работать приятнее, и на выходе получается не 30% брака, а 0,3%.
Зря автор не упомянул конкурс P-H-C и его победителя — семейство алгоритмов Argon2.
С тех, что с используют протокол AHCI — без проблем, для прошивки это обычное SATA-устройство, для тех, что используют протокол NVMe нужен DXE-драйвер, который на новых матернских платах уже имеется, а на старые его можно попробовать добавить, но без гарантии положительного результата.
А потом вот эти же люди говорят, что у открытого сообщества нормальные программы не получаются.
Я веду открытый проект с 2013 года, один, на языке и технологиях приличной давности (C++/Qt4). Его не скачивают миллионы и он не нужен каждому хипстеру, но он решает свою задачу. В этом году я неспеша меняю в нем движок, т.к. за пару лет требования изменились, в следующем году буду дорабатывать UI, глядишь лет через 5 со старта проекта из него выйдет что-то путное. А вот эти «по открытому проекту в год» — это большо про «помотросил, и бросил», чем про решение задачи, мне кажется.
Прошивку на нем тоже починить будет практически невозможно в случае ее падения — там BootGuard с прошитым в чипсет ключом, и обе флешки для EC и UEFI — в корпусе TFBGA24, т.е. их просто так не снять и не прошить без специального оборудования.
У меня есть доступ к исходному коду этого модуля, но картины это не меняет, т.к. интерпретатор EBC на данный момент собирается только под три вышеупомянутых архитектуры, и для ARM и PowerPC просто не реализован еще.
1. Понятно, что писать можно и нетрудно, непонятно только, зачем. Мне тоже приходится писать на ассемблере там, где PIC не завезли (пользуясь случаем, шлю разработчикам архитектуры amd64 охапку лучей добра за RIP-относительную адресацию), но вот так брать и писать на нем программу для UEFI Shell — больше похоже на фанатизм, дух старой школы и вот это все. :)
2. EBC пока не реализован ни на каких архитетурах, кроме i386, amd64 и Itanium, да и компилятор дают только за деньги, так что толку от него крайне немного.
3. Спасибо.
Все это здорово, конечно, только зачем на ассемблере писать то, что можно написать на C в 10 строк? Ничего специфичного для архитектуры там нет, а для ARM и PPC программу уже не собрать.
Сталкивался, два дня терпел, надоело, вернулся на 8.1 на рабочем ПК, поставил Xubuntu на развлекательный ноутбук. Пусть ищут бетатестеров в другом месте.
Заявляют они это давно уже, а по факту даже «особы, приближенные к императору» не получили ни самих прошивок, ни софта для их обновления. Если в конце концов поддержка все-таки будет — отлично, но пока я бы на нее не надеялся.
Добавлю еще, что даже если сесть и исправить все у себя, завтра от IBV снова придет обновление с неисправленным, поэтому исправить у себя мало — нужно сообщить об ошибке «наверх», а это порой занимает больше времени, чем собственно разгребание предупреждений и исправление ошибок. К счастью, опыт показывает, что на сообщения об ошибках, найденных статическим анализатором, IBV реагируют быстро и правильно.
Приведу свою статистику, которую набрал, проверяя разные реализации UEFI, до которых есть или был доступ: на 1000 предупреждений около 50 — самые настоящие ошибки, причем некоторые классы предупреждений таковы, что практически сколько их — столько и ошибок (оператор запятая в условии, к примеру).
Остальное либо хитрые отладочные макросы, которые раскрываются в (BOOLEAN)(1 == 0) в релизном билде, либо преобразование типов у левого выражения вместо правого (наркомания, но работает), либо преобразования с потерей знака, либо сдвиг отрицательных чисел (UB, но работает), и тому подобное.
Да, нужно фильтровать вывод, но после того, как он отфильтрован, жить становится значительно легче, особенно если гонять анализатор не раз в год, а на каждом релизном билде (но на такое счастье мне пока денег не дают).
Плата какая-то непонятная: поставь на нее слот SODIMM DDR3L вместо убогого модуля на 1 Gb — и будет почти хорошо, а сейчас Windows 10 в списке поддерживаемых ОС выглядит как издевка.
Формы для комментариев вполне достаточно (и та на 90% сайтов не нужна и блокируется предназначенными для этого расширениями), а встраивать чятик в браузер — хорошая идея, но только в случае, если этот чатик можно будет отключить сразу и на совсем и никогда больше не видеть на сайтах, где никакая социальная фигня не нужна, но присуствует, т.к. это теперь модно, эту самую социальную фигню.
Нашел правильный перевод в этой публикации: расфазировка тактового сигнала.
Я не думаю, что там наберется на целую статью, поэтому отвечу тут.
Spread Spectrum Modulation — это снижение спектральной плотности сигнала генератора частоты путем «размазывания» её вокруг нужного значения. Нужно оно по идее для того, чтобы снизить уровень электромагнитного излучения от устройства, но на самом деле он приводит не к снижению, а к перераспределению энергии ЭМИ по другим частотам, т.е. по факту только нужен только для обмана тестовых стендов FCC, при этому он вызывает Clock Skew (я не знаю, как это перевести правильно, пусть будет сдвиг частоты) и потому мешает разгону и работе процессора на высоких частотах. В английской вики написано более подробно.

Про fTPM и отладку по USB — у Microsoft есть разные уровни сертификации систем на совместимость с разными технологиями Windows. Некоторые из них, вроде отладки по USB, конфликтуют с дизайном SoC и требованиями других компаний, поэтому для сертификации собирают специальный BIOS, нужным образом настроенный, проходят ее, после чего BIOS этот складывают на полку до следующей сертификации. Не буду показывать пальцем на тех, кто так делает, но посоветую просто взять и сравнить требования MS (гуглятся) и то, что реализовано (и включено/отключено в конфигурации по умолчанию) на сертифицированных системах — отличия находятся почти всегда.
Такое ощущение, что добрая половина пишуших про эту «проблему» специалистов — лицемеры чистой воды.
В чем виноваты программисты? В том, что успешно решили задачу пройти тестирование на соотвествие какой-то спецификации, которая несовместима ни с законами физики, ни со здравым смыслом, и писали которую менеджеры-экологи, а не инженеры-двигателисты? Чем это отличается от всем известной настройки Spread Spectrum Modulation в BIOS Setup, которую включают, чтобы пройти тестирование на ЭМ-безопасность, а потом выключают при нормальной работе? Чем это отличается от таких же настроек для fTPM и отладки по USB, которые нужны, в основном, только для получения наклейки Windows 10 Ready более красивого цвета?
Процесс тестирования нужно постоянно менять и развивать, иначе тестирование смогут и будут обходить вот такими решениям, как у VW.
Надеятся на чью-то честность там, где на кону стоят миллионы долларов — фантастическая глупость и наивность. Более того, я уверен, что и другие автопроизводители занимаются тем же самым уже лет 30-50, а VW банальнно решили валить.
У меня сейчас очень сдвинутое представление о том, что уже есть на рынке, а чего еще нет, т.к. большая часть железа попадает ко мне почти сразу после появления инженерных семплов. Т.е. сначала ты отлаживаешь какой-нибудь SoC полгода, и сыт им уже по горло, а потом вдруг выясняется, что его даже не представили официально еще. :)

Информация

В рейтинге
Не участвует
Дата рождения
Зарегистрирован
Активность

Специализация

Инженер встраиваемых систем, Системный инженер
Ведущий