В действительности, все не так, как на самом деле.
BIOS - это собирательное название прошивок x86 систем в том виде, в котором их начала выпускать IBM, т.е. таких, которые стартовали и работали в 16-битном режиме исполнения, имели текстовый или псевдографический интерфейс BIOS Setup, и предоставляли операционной системе интерфейс BIOS Interrupt Call, основанный на программных прерываниях. По мере развития железа и перехода на 32, а затем и 64-битные процессоры 16-битная прошивка стала серьезной обузой, как и устаревший и несовместимый с новыми устройствами интерфейс BIOS IC, и от них начали понемногу избавляться в пользу комбинации из трехфазового Platform Interface (32-битной Pre-EFI Initialization, где происходит тренировка памяти, чтобы перестать исполнять код с SPI flash, 32\64-битной Driver Execution Environment, где происходит вся остальная инициализация железа, и 32\64-битной Boot Device Selection, которая рисует графический Setup, запускает Option ROMы, находит на известных ей ФС загрузчик ОС и передает на него управление). При этом BDS (совместно с DXE) и реализует тот самый Unified Extensible Firmware Interface, который загрузчик ОС затем использует вместо устаревшего BIOS Interrupt Call. Тем не менее, последний все еще поддерживается на многих системах при помощи механизма Compatibility Support Module, который позволяет UEFI-совместимой прошивке публиковать не только свой нативный (32\64-битный) UEFI, но и оставленный для обратной совместимости 16-битный BIOS IC, и сделано это при помощи довольно хитрых трамплинов в старый режим и обратно. Запускается CSM частично в D XE, частично в BDS, а работает только в BDS (потому что загрузчики ОС работают только там).
Таким образом, из "BIOS запускает UEFI", и "UEFI запускает BIOS" - это бессмысленные выражения. На старых компьютерах 16-битный BIOS имел 16-битный интерфейс IC, и никакого UEFI там не было еще. На новых компьютерах 32-битный PEI запускает 32\64-битный DXE, который запускает 32\64-битный BDS, который имеет либо только 32\64-битный UEFI, либо еще и 16-битный CSM, который эмулирует старый 16-битный IC в достаточной степени, чтобы старые загрузчики запускались.
BIOS IC и UEFI - не единственные интерфейсы между прошивкой и ОС на x86, как и BIOS и PI не единственные способы добраться до них. Вместо BIOS и PI можно использовать coreboot, вместо DXE/BDS/IC/UEFI - напрямую запускать ядро Linux или любой другой ОС. Интерфейс UEFI тоже не обязательно публикуется DXE и BDS, его могут публиковать и другие загрузчики, например, uBoot или TianoCore payload для coreboot.
Короче: BIOS - это собирательное название 16-битного всего, что работало на старых х86-машинах до ОС. UEFI - это интерфейс между прошивкой и ОС, и ничего больше. Прошивка же сама по себе называется "UEFI-совместимой", если на публикует вышеупомянутый интерфейс.
Дисклеймер: кода чужого не видел, утечек никаких не качал, пересказываю людей из твиттера, цитировать меня не надо, пожалуйста.
Поправлю немного, утечка произошла не у Intel, а у LCFC, подразделения Lenovo по выпуску линеек для обычных пользователей (Yoga и подобных). Вот хороший пост про это все.
ThinkPad'ы на этом заводе не делают, и их прошивки разрабатываются другой командой.
Внутри утечки не только референсный код Intel для Alder Lake, но и очень много кода платформы Insyde H2O, практически весь код, специфичный для продуктов LCFC, свежие версии разных внутренних утилит Lenovo, несколько типов закрытых ключей, и т.п.
Очередной сильный удар по репутации Lenovo, но им не привыкать, отряхнутся и дальше пойдут.
Intel перестал выпускать десктопные платы довольно давно, а всякие NUCи и прочее отдано на аутсорс AMI, и базируется на AMI AptioV, одной из самых дырявых платформ для х86-прошивок из используемых.
MS делает десктопные компьютеры и ноутбуки довольно давно, и тоже начинали с покупки лицензий у IBV, но года 4 уже делают прошивки сами на основе EDK2, и получается у них весьма неплохо, особенно после старта проекта Secured-core PC.
К сожалению, нормальных производителей компьютеров на х86-процессорах, с точки зрения безопасности прошивок, остается все меньше с каждым годом. Apple ушел с этого рынка, HP испортился (HPE еще вроде держится, но даже там сделали свой SureStart поверх обычного EC и называют это "решением"...), Lenovo как никогда до топов не дотягивала, так и сейчас не дотягивает, а производители второго эшелона вроде Asus/Gigabyte/MSI никогда безопасностью прошивок и не интересовались.
В итоге относительно нормальные x86-машины с относительно безопасными прошивками делают теперь только MS (и, может быть, Dell, но MS лучше все равно, потому что используют свои собственные наработки из Project Mu, а не непонятный код от IBV), и потому, кроме какого-нибудь последнего Surface Laptop Go 2 for Business, покупать решительно нечего.
Потогонка у них это "работа", а нормальная работа вида "головой, а не 20 часов в сутки" - это "уход". Уважаемые авторы, пожалуйте, не распространяйте этот ублюдочный термин, проплаченный очередными PR-специалистами на зарплате. Никакого ухода там нет и не было, и то, что люди наконец-то в массе начинают догадываться, что "то везет - на том и едут" - это благо.
Только не Secure Boot, а просто EFI boot, потому что первое - это про то, что собранный загрузчик подписан, и его подпись EFI-совместимая прошивка проверяет до того, как передаст управление на его точку входа.
Не совсем понятно, зачем тут ассемблер, кроме как "захотелось вот на ассемблере", потому что все, что тут на ассемблере написано - это переопределения типов данных из С, части структур из Extended Firmware Interface тоже из С, и вызов функций с интерфейсом MS x64 ABI.
Выучите лучше С, намного легче станет писать что-то сложнее хелловорлдов, а ассемблер оставьте для задач, которые на С либо решаются плохо (мужики из coreboot'а в свое время ROMCC не от хорошей жизни написали), либо не решаются совсем. Ссылку на EDK2 и TianoCore уже сверху давали.
Приятно, когда по теме что-то пишут на русском, но для специалиста в статье нет ничего нового и\или интересного, к сожалению.
наибольшую опасность сегодня представляют уязвимости в режиме SMM и подсистеме Intel ME
Не соглашусь. Наибольшую реальную опасность, на мой взгяд, представляют:
— отключенный или неверно настроенный UEFI SecureBoot, который по прежнему никак не могут включить по умолчанию по разным причинам. Т.к. технологию проектировали и в спешке, и при активном противостоянии OSS-сообщества, результат получится «ни жив, ни мертв», т.е. в теории у нас есть безопасная загрузка какая-то, а на практике UEFI CA доверять нельзя совсем (им за 10 лет подписали слишком много уязвимого), работающего механизма отзыва подписей нет (а тот, что есть в виде dbx и dbt страдает от комбинаторного взрыва), работающего механизма отзыва сертификатов нет (все попытки решить вопрос через Audit Mode и Deployment Mode можно считать провалившимися), придумывать что-то новое ни UEFI Forum, ни остальные не торопятся.
— отключенный, или неверно настроенный, или тривиально отключаемый условный BootGuard (т.е. все скопом технологии защиты от модификации прошивки на SPI NOR и\или предотвращения запуска неавторизованного модифицированного кода). Проблема неработоспособности статического корня доверия стоит у MS настолько остро, что они требуют наличия TPM 2.0 для Windows 11, и стремятся всеми силами выкинуть прошивку из цепочки доверия, и я их прекрасно понимаю.
— поистине огромное количество уязвимостей в драйверах, взаимодействующих с переменными NVRAM, вызванное плохим дизайном интерфейса GetVariable и SetVariable.
— практическая незащищенность подавляющего большинства прошивок от DMA-атак, которые за последние ~7 лет превратились из «нужен специалист с ФПГА за 5 килобаксов и куча кастомного кода» в «нужен донгл за 30 баксов и PCILeech с гитхаба».
Самое неприятное, что хочется отметить, это отсутствие и прогресса в безопасности UEFI относительно ее состояния от 2015 года, когда я про нее писал серию статей, и интереса вендоров к этому прогрессу. Годы идут, а мы решаем те же самые проблемы теми же самыми методами, игнорируя десятилетия усилий безопасников и системных программистов, занятых развитием современных ОС. Нельзя сказать, что никто вообще ничего не делает, но все, что делается — делается двумя с половиной вендорами для себя же, а независимого аудита этих «решений» либо не проводится совсем, либо его результаты сразу же засекречиваются по соглашению сторон.
Короче, с точки зрения реальной безопасности прошивок для Wintel PC — «мы в жопе, Баттхед».
Давайте я немного с другой стороны баррикад добавлю от лица простых (и непростых) инженеров, с которыми эти самые EPMы работают в известной фруктовой компании:
— Хороший EPM отличается от плохого в основном тем, что хороший ничего не забывает, никому не прощает, и действительно несет ответственность за свой продукт или фичу, а не только играет в «горячую картошку» с другими командами или своими же инженерами.
— Хорошему EPMу можно сказать «вот этот кусок работы другой команды нужен нам очень сильно, и желательно еще позавчера, нужна твоя помощь», и он действительно займется продвижением этой работы, а не ограничится «ну, я поговорил там, они сделают когда-нибудь, точно говорю».
— Одна из задач хорошего EPMа в том, чтобы снижать количество организационной работы у инженеров, т.е. он\она не таскает всю команду по встречам ради встреч, обсуждениям ради обсуждений, не обещает Program Office'у золотые горы с доставкой каждый вторник, и не пытается заниматься директивным управлением в обход работающей корпоративной иерархии. Т.е. надо очень хорошо понимать, что эксперту Васе вы не начальник, и пытаться ему приказывать не следует.
Самое смешное, что мы над этим драйвером с говорящим именем уже успели посмеяться и в 2020 году, и раньше еще, но никому, кроме ребят из ESET, не пришло тогда в голову отреверсить этот драйвер, просто посмеялись и дальше пошли работу работать. Вывод: иногда надо верить говорящим именам, и если на заборе написано известное слово из трех букв, то за ним могут быть не только дрова.
Anyway, in LenovoVideoInitDxe.efi it reads the battery status from the EC (register 0x38, which we came across in part 2 when decoding the ACPI tables, as well as register 0xd1 which has some additional battery status flags). Depending on certain bits in those registers, it may print one or other message.
Хорошая статья, только лучше было бы сделать дамп оригинальной прошивки, и модифицировать уже его, так получится перенести все индивидуальные данные, даже не зная, где они хранятся. Еще у других ноутбуков HP бывают случаи защиты тома DXE от модификации, но эта защита успешно обходится (1, 2, 3), если на ноутбуке не включен BootGuard.
BIY уникальна тем, что там быстро появляются не только просто правила, но и мета-правила (т.е. правила, действующие на сами правила, TEXT IS FLOAT), и даже пара-правила (т.е. правила, действующие вне текущего уровня, LEVEL IS YOU). Пусть это и не про «алгоритмы», но и «массирует» те же аналитические отделы мозга, что и решение задач про алгоритмы.
Думаю, что оставшаяся без Directly Responsible Individual часть проекта обязательно сломается скорее раньше, чем позже, и вместо одного дорого умника понадобится пять, чтобы либо оперативно разобраться, починить, снова назначить DRI, и реанимировать эту часть, либо ударным трудом переписать, чтобы все снова заработало хоть как то.
Видел несколько успешных проектов с размазанным владением, но в них всегда был «дежурный DRI на сегодня», и было их там не шестеро средних, а трое сильных, которые сообща владели дюжиной проектов разного размера, и могли перебрасывать и свои силы, и силы своих ассистентов уровней поменьше с тех мест, где уже нормально, на те, где все еще все в огне и мы в аду.
Проблема автобусного фактора вокруг единицы у очень многих ключевых сотрудников, от которого страдают и работодатель, и сами ключевые сотрудники — она понятная, и решается в основном заваливанием этих сотрудников плюшками (чтобы не уходили к конкурентам), и стратегическими длинными отпусками в тот момент, когда ключевые сотрудники начинают подгорать (чтобы не уезжали в Монголию пасти скот), но вот такие вот решения намного лучше работают на практике, чем попытки размазать реальное владение, которое неизбежно приводит к многократно опробованному и повторенному «общее — значит ничьё».
Хакинтош и UEFI SecureBoot — это не про то несколько, и я точно не призываю закрыть всю загрузку наглухо и никого не впускать и не выпускать, потому что это другая крайность, и я сам ее не люблю так же сильно, как и описанную в этой статье «гуляй-рванину».
Тем не менее, многолетний практически опыт подсказывает, что любые технологии обеспечения безопасности, которые отключить проще, чем настроить, будут при первых сложностях с их настройкой или проблемах, вызванных неверной настройкой, отключены навсегда, зачастую прямо на заводе. А если они еще и по-умолчанию отключены — никто даже не пойдет их включать или тестировать, «нам тут работать надо, а не херней страдать». Это потом уже любой хакер Вася за 15 минут делает себе ботнет из 100500 машин, и идет ими майнить монеро или ддосить своего соседа Петю, но производителя это все не начинает волновать никак — его устройства уже на рынке, деньги он уже получил, а дальше все эти проблемы — это проблемы Васи и Пети.
Именно поэтому любые подобного рода технологии нормально заработают только тогда, когда: а) они будут включены по умолчанию, б) пользоваться ими будет намного проще, чем отключить совсем. Именно так получилось сделать и на T2, на Apple Silicon, и я считаю последнюю итерацию своим самым большим достижением в карьере на данным момент — несложно настраиваемый SecureBoot, позволяющий загружать любой пользовательский код (после проверки пароля и доказательства физического присутствия), и при этом не отключаемый принципиально, и доставленный на миллионы машин простых пользователей, которые массово на него не жалуются. А UEFI SecureBoot как отключали, так и продолжат отключать при любом чихе, а потом страдать от загрузочных вирусов и перехватчиков паролей.
Не, это не намеренно, это просто никто даже не пытался ничего включать и настраивать, потому что это и дорогое время инженера, и возможные сложности с обновлениями, и вероятность неверной настройки и последующего отзыва оборудования.
На самом деле, только когда производитель достаточно именитый, чтобы уязвимости в его устройствах начали портить ему имидж и продажи, вот только тогда этот самый производитель начинает заставлять своих инженеров что-то делать кроме «отключил и не трогаешь», искать на рынке специалистов по безопасности, деньги им платить, вот это все. Что говорить, если даже крупные производители десктопных плат (Asus, Asrock, MSI и Gigabyte) на безопасность своих прошивок и софта кладут свои огромные таёжные приборы, а уж китайским суньхуньвчаям это все до фонаря и подавно…
Там выше написали уже, но в долине таких зарплат у действительно хороших мидлов и сеньеров давно уже нет, потому что цены на жилье такие, что 110к на семью из трех человек в Сан Франциско — это порог бедности.
Сходите на levels.fyi и посмотрите на total compensation, там меньше 200к нет практически ни у кого уже, а серьезные товарищи с опытом могут рассчитывать на примерно от 200к базы + 100к акциями до 300к базы + 1м акциями, и даже выше, в зависимости от специальности, ниши, умения себя продать и желания играть в big FAANG switcheroo, т.е. менять работу каждые пару лет с повышением текущей зарплаты на 20-40% каждый раз. Тем, кто в switcheroo играть не хочет, может повезти с акциями, которые у FAANGов за последние 4 года выросли в ~10 раз, и потому те, кто их продавать не торопились (базы на все хватало), сейчас уже либо все долларовые миллионеры, либо успешно платят ипотеки за дома на Гавайях.
Комментарии лгут, и компилятор их игнорирует. Код нужно так писать, чтобы комментарии были нужны исключительно для объяснения архитектурных моментов, которые из непосредственно кода реконструировать сложно из за разницы в уровне абстракции. Все остальное должно быть написано так, чтобы поняли и человек, и машина, и статический анализатор очень помогает в том, чтобы прояснить моменты, которые для человека очевидны в одну сторону, а для машины — в другую, вон как с упомянутой выше разницей между memset и memset_s, с as-if rule, и прочими вещами, про которые ребята из СиПроВер постоянно статьи пишут. Писать же человеку одно, а машине другое — гарантировать себе проблемы с тем, что теперь непонятно, чему верить, что на самом деле имел в виду автор, и зачем он это имел в виду.
В действительности, все не так, как на самом деле.
BIOS - это собирательное название прошивок x86 систем в том виде, в котором их начала выпускать IBM, т.е. таких, которые стартовали и работали в 16-битном режиме исполнения, имели текстовый или псевдографический интерфейс BIOS Setup, и предоставляли операционной системе интерфейс BIOS Interrupt Call, основанный на программных прерываниях. По мере развития железа и перехода на 32, а затем и 64-битные процессоры 16-битная прошивка стала серьезной обузой, как и устаревший и несовместимый с новыми устройствами интерфейс BIOS IC, и от них начали понемногу избавляться в пользу комбинации из трехфазового Platform Interface (32-битной Pre-EFI Initialization, где происходит тренировка памяти, чтобы перестать исполнять код с SPI flash, 32\64-битной Driver Execution Environment, где происходит вся остальная инициализация железа, и 32\64-битной Boot Device Selection, которая рисует графический Setup, запускает Option ROMы, находит на известных ей ФС загрузчик ОС и передает на него управление). При этом BDS (совместно с DXE) и реализует тот самый Unified Extensible Firmware Interface, который загрузчик ОС затем использует вместо устаревшего BIOS Interrupt Call. Тем не менее, последний все еще поддерживается на многих системах при помощи механизма Compatibility Support Module, который позволяет UEFI-совместимой прошивке публиковать не только свой нативный (32\64-битный) UEFI, но и оставленный для обратной совместимости 16-битный BIOS IC, и сделано это при помощи довольно хитрых трамплинов в старый режим и обратно. Запускается CSM частично в D
XE, частично в BDS, а работает только в BDS (потому что загрузчики ОС работают только там).
Таким образом, из "BIOS запускает UEFI", и "UEFI запускает BIOS" - это бессмысленные выражения. На старых компьютерах 16-битный BIOS имел 16-битный интерфейс IC, и никакого UEFI там не было еще. На новых компьютерах 32-битный PEI запускает 32\64-битный DXE, который запускает 32\64-битный BDS, который имеет либо только 32\64-битный UEFI, либо еще и 16-битный CSM, который эмулирует старый 16-битный IC в достаточной степени, чтобы старые загрузчики запускались.
BIOS IC и UEFI - не единственные интерфейсы между прошивкой и ОС на x86, как и BIOS и PI не единственные способы добраться до них. Вместо BIOS и PI можно использовать coreboot, вместо DXE/BDS/IC/UEFI - напрямую запускать ядро Linux или любой другой ОС. Интерфейс UEFI тоже не обязательно публикуется DXE и BDS, его могут публиковать и другие загрузчики, например, uBoot или TianoCore payload для coreboot.
Короче: BIOS - это собирательное название 16-битного всего, что работало на старых х86-машинах до ОС. UEFI - это интерфейс между прошивкой и ОС, и ничего больше. Прошивка же сама по себе называется "UEFI-совместимой", если на публикует вышеупомянутый интерфейс.
coreboot уже работает на Alder Lake, пока что только на одной плате, ребята из Dasharo недавно демонстрировали на Open Source Firmware Conference.
С полноценной нейтрализацией через me_cleaner пока непонятно, но поддержку отключения HAP-битом для Alder Lake уже скоро добавят.
Дисклеймер: кода чужого не видел, утечек никаких не качал, пересказываю людей из твиттера, цитировать меня не надо, пожалуйста.
Поправлю немного, утечка произошла не у Intel, а у LCFC, подразделения Lenovo по выпуску линеек для обычных пользователей (Yoga и подобных). Вот хороший пост про это все.
ThinkPad'ы на этом заводе не делают, и их прошивки разрабатываются другой командой.
Внутри утечки не только референсный код Intel для Alder Lake, но и очень много кода платформы Insyde H2O, практически весь код, специфичный для продуктов LCFC, свежие версии разных внутренних утилит Lenovo, несколько типов закрытых ключей, и т.п.
Очередной сильный удар по репутации Lenovo, но им не привыкать, отряхнутся и дальше пойдут.
Intel перестал выпускать десктопные платы довольно давно, а всякие NUCи и прочее отдано на аутсорс AMI, и базируется на AMI AptioV, одной из самых дырявых платформ для х86-прошивок из используемых.
MS делает десктопные компьютеры и ноутбуки довольно давно, и тоже начинали с покупки лицензий у IBV, но года 4 уже делают прошивки сами на основе EDK2, и получается у них весьма неплохо, особенно после старта проекта Secured-core PC.
К сожалению, нормальных производителей компьютеров на х86-процессорах, с точки зрения безопасности прошивок, остается все меньше с каждым годом. Apple ушел с этого рынка, HP испортился (HPE еще вроде держится, но даже там сделали свой SureStart поверх обычного EC и называют это "решением"...), Lenovo как никогда до топов не дотягивала, так и сейчас не дотягивает, а производители второго эшелона вроде Asus/Gigabyte/MSI никогда безопасностью прошивок и не интересовались.
В итоге относительно нормальные x86-машины с относительно безопасными прошивками делают теперь только MS (и, может быть, Dell, но MS лучше все равно, потому что используют свои собственные наработки из Project Mu, а не непонятный код от IBV), и потому, кроме какого-нибудь последнего Surface Laptop Go 2 for Business, покупать решительно нечего.
Потогонка у них это "работа", а нормальная работа вида "головой, а не 20 часов в сутки" - это "уход". Уважаемые авторы, пожалуйте, не распространяйте этот ублюдочный термин, проплаченный очередными PR-специалистами на зарплате. Никакого ухода там нет и не было, и то, что люди наконец-то в массе начинают догадываться, что "то везет - на том и едут" - это благо.
Только не Secure Boot, а просто EFI boot, потому что первое - это про то, что собранный загрузчик подписан, и его подпись EFI-совместимая прошивка проверяет до того, как передаст управление на его точку входа.
Не совсем понятно, зачем тут ассемблер, кроме как "захотелось вот на ассемблере", потому что все, что тут на ассемблере написано - это переопределения типов данных из С, части структур из Extended Firmware Interface тоже из С, и вызов функций с интерфейсом MS x64 ABI.
Выучите лучше С, намного легче станет писать что-то сложнее хелловорлдов, а ассемблер оставьте для задач, которые на С либо решаются плохо (мужики из coreboot'а в свое время ROMCC не от хорошей жизни написали), либо не решаются совсем. Ссылку на EDK2 и TianoCore уже сверху давали.
Поставил бы вам плюс за перевод, если бы вы указали, что а) это перевод, б) оригинальная статья выпущена в 2011 году.
https://invisiblethingslab.com/resources/2011/Attacking_Intel_TXT_via_SINIT_hijacking.pdf
Не соглашусь. Наибольшую реальную опасность, на мой взгяд, представляют:
— отключенный или неверно настроенный UEFI SecureBoot, который по прежнему никак не могут включить по умолчанию по разным причинам. Т.к. технологию проектировали и в спешке, и при активном противостоянии OSS-сообщества, результат получится «ни жив, ни мертв», т.е. в теории у нас есть безопасная загрузка какая-то, а на практике UEFI CA доверять нельзя совсем (им за 10 лет подписали слишком много уязвимого), работающего механизма отзыва подписей нет (а тот, что есть в виде dbx и dbt страдает от комбинаторного взрыва), работающего механизма отзыва сертификатов нет (все попытки решить вопрос через Audit Mode и Deployment Mode можно считать провалившимися), придумывать что-то новое ни UEFI Forum, ни остальные не торопятся.
— отключенный, или неверно настроенный, или тривиально отключаемый условный BootGuard (т.е. все скопом технологии защиты от модификации прошивки на SPI NOR и\или предотвращения запуска неавторизованного модифицированного кода). Проблема неработоспособности статического корня доверия стоит у MS настолько остро, что они требуют наличия TPM 2.0 для Windows 11, и стремятся всеми силами выкинуть прошивку из цепочки доверия, и я их прекрасно понимаю.
— поистине огромное количество уязвимостей в драйверах, взаимодействующих с переменными NVRAM, вызванное плохим дизайном интерфейса GetVariable и SetVariable.
— практическая незащищенность подавляющего большинства прошивок от DMA-атак, которые за последние ~7 лет превратились из «нужен специалист с ФПГА за 5 килобаксов и куча кастомного кода» в «нужен донгл за 30 баксов и PCILeech с гитхаба».
Самое неприятное, что хочется отметить, это отсутствие и прогресса в безопасности UEFI относительно ее состояния от 2015 года, когда я про нее писал серию статей, и интереса вендоров к этому прогрессу. Годы идут, а мы решаем те же самые проблемы теми же самыми методами, игнорируя десятилетия усилий безопасников и системных программистов, занятых развитием современных ОС. Нельзя сказать, что никто вообще ничего не делает, но все, что делается — делается двумя с половиной вендорами для себя же, а независимого аудита этих «решений» либо не проводится совсем, либо его результаты сразу же засекречиваются по соглашению сторон.
Короче, с точки зрения реальной безопасности прошивок для Wintel PC — «мы в жопе, Баттхед».
— Хороший EPM отличается от плохого в основном тем, что хороший ничего не забывает, никому не прощает, и действительно несет ответственность за свой продукт или фичу, а не только играет в «горячую картошку» с другими командами или своими же инженерами.
— Хорошему EPMу можно сказать «вот этот кусок работы другой команды нужен нам очень сильно, и желательно еще позавчера, нужна твоя помощь», и он действительно займется продвижением этой работы, а не ограничится «ну, я поговорил там, они сделают когда-нибудь, точно говорю».
— Одна из задач хорошего EPMа в том, чтобы снижать количество организационной работы у инженеров, т.е. он\она не таскает всю команду по встречам ради встреч, обсуждениям ради обсуждений, не обещает Program Office'у золотые горы с доставкой каждый вторник, и не пытается заниматься директивным управлением в обход работающей корпоративной иерархии. Т.е. надо очень хорошо понимать, что эксперту Васе вы не начальник, и пытаться ему приказывать не следует.
Годы идут, у Lenovo не меняется ничего.
Самое смешное, что мы над этим драйвером с говорящим именем уже успели посмеяться и в 2020 году, и раньше еще, но никому, кроме ребят из ESET, не пришло тогда в голову отреверсить этот драйвер, просто посмеялись и дальше пошли работу работать. Вывод: иногда надо верить говорящим именам, и если на заборе написано известное слово из трех букв, то за ним могут быть не только дрова.
Видел несколько успешных проектов с размазанным владением, но в них всегда был «дежурный DRI на сегодня», и было их там не шестеро средних, а трое сильных, которые сообща владели дюжиной проектов разного размера, и могли перебрасывать и свои силы, и силы своих ассистентов уровней поменьше с тех мест, где уже нормально, на те, где все еще все в огне и мы в аду.
Проблема автобусного фактора вокруг единицы у очень многих ключевых сотрудников, от которого страдают и работодатель, и сами ключевые сотрудники — она понятная, и решается в основном заваливанием этих сотрудников плюшками (чтобы не уходили к конкурентам), и стратегическими длинными отпусками в тот момент, когда ключевые сотрудники начинают подгорать (чтобы не уезжали в Монголию пасти скот), но вот такие вот решения намного лучше работают на практике, чем попытки размазать реальное владение, которое неизбежно приводит к многократно опробованному и повторенному «общее — значит ничьё».
Тем не менее, многолетний практически опыт подсказывает, что любые технологии обеспечения безопасности, которые отключить проще, чем настроить, будут при первых сложностях с их настройкой или проблемах, вызванных неверной настройкой, отключены навсегда, зачастую прямо на заводе. А если они еще и по-умолчанию отключены — никто даже не пойдет их включать или тестировать, «нам тут работать надо, а не херней страдать». Это потом уже любой хакер Вася за 15 минут делает себе ботнет из 100500 машин, и идет ими майнить монеро или ддосить своего соседа Петю, но производителя это все не начинает волновать никак — его устройства уже на рынке, деньги он уже получил, а дальше все эти проблемы — это проблемы Васи и Пети.
Именно поэтому любые подобного рода технологии нормально заработают только тогда, когда: а) они будут включены по умолчанию, б) пользоваться ими будет намного проще, чем отключить совсем. Именно так получилось сделать и на T2, на Apple Silicon, и я считаю последнюю итерацию своим самым большим достижением в карьере на данным момент — несложно настраиваемый SecureBoot, позволяющий загружать любой пользовательский код (после проверки пароля и доказательства физического присутствия), и при этом не отключаемый принципиально, и доставленный на миллионы машин простых пользователей, которые массово на него не жалуются. А UEFI SecureBoot как отключали, так и продолжат отключать при любом чихе, а потом страдать от загрузочных вирусов и перехватчиков паролей.
На самом деле, только когда производитель достаточно именитый, чтобы уязвимости в его устройствах начали портить ему имидж и продажи, вот только тогда этот самый производитель начинает заставлять своих инженеров что-то делать кроме «отключил и не трогаешь», искать на рынке специалистов по безопасности, деньги им платить, вот это все. Что говорить, если даже крупные производители десктопных плат (Asus, Asrock, MSI и Gigabyte) на безопасность своих прошивок и софта кладут свои огромные таёжные приборы, а уж китайским суньхуньвчаям это все до фонаря и подавно…
Сходите на levels.fyi и посмотрите на total compensation, там меньше 200к нет практически ни у кого уже, а серьезные товарищи с опытом могут рассчитывать на примерно от 200к базы + 100к акциями до 300к базы + 1м акциями, и даже выше, в зависимости от специальности, ниши, умения себя продать и желания играть в big FAANG switcheroo, т.е. менять работу каждые пару лет с повышением текущей зарплаты на 20-40% каждый раз. Тем, кто в switcheroo играть не хочет, может повезти с акциями, которые у FAANGов за последние 4 года выросли в ~10 раз, и потому те, кто их продавать не торопились (базы на все хватало), сейчас уже либо все долларовые миллионеры, либо успешно платят ипотеки за дома на Гавайях.