Она не обязательна юридически, но включается в договоры аренды помещений повсеместно, и удалять ее оттуда ради вас никто не будет. Стоит такая страховка обычно совсем недорого, меньше 10 евро в месяц, поэтому она есть практически у всех.
которая всего лишь в течении десятка лет обеспечивала работу интеловского бэкдора IME.
Опять не в лотерею, а в карты, и не выиграл, а проиграл.
Minix используется только на МЕ10+, дебютировавший на платформе Skylake, так что десяток лет — это на самом деле два с небольшим, т.е. ее официальный анонс состоялся 5 августа 2015 года. До этого использовалась ОСРВ ThreadX.
Во-вторых, термин «бэкдор» для Management Engine — слишком сильный. Софт намного дешевле железа, поэтому на МЕ и повесили столько всего с момента его появления в сетевых картах. Да, теперь МЕ занимается чем попало от загрузки микрокода из FIT до эмуляции устройства TPM 2.0 и поддержки шифрованного А\В канала для HDMI, но это все исключительно потому, что в железе все эти вещи было бы сделать тупо вдесятеро дороже, а процессоры для ПК должны стоить дешево, иначе конкуренты сожрут. Думаете АМД себе в Ryzen добавили PSP от хорошей жизни, или просто потому, что софт дешев, а железо дорого? Вот то то и оно.
Фанатам открытости и свободы посоветую изначально открытые архитектуры вроде RISC-V и OpenPOWER, ибо на x86 и ARM ни того, ни другого уже давно нет.
Грубая оценка по опыту работы в другой большой компании похожего уровня.
Из всего вышеперечисленного только Chrome уже написан, и браться его переписывать на Go с нуля нет никакого смысла, все остальное — почему нет? Для хардкорной математики все равно будут использованы готовые библиотеки на С или Фортране (FFI у языка есть, сопряжение хоть и не без проблем, но работает), а для основной grunt work язык Go вполне подходит. Они на нем теперь даже initramfs пишут, так что я не удивлюсь, если напишут и что-нибудь из ML (AI все же слишком сильный термин, на мой взгляд).
Автор не понимает целей и задач Гугла при разработке этого языка, поэтому сетует на то, что Go — это такой «С для дураков», а надо было вместо него внедрять что другое, с нативным ООП, с шаблонами, с выводом типов. D, например, или Rust, или вообще ЯФП какой-нибудь.
Так вот, примерно 90% задач гугла вполне решается на этом самом «С для дураков» без использования кодогенерации, рефлексии, шаблонов, ООП и чего либо еще, и самое главное, что в итоге написанный разработчиками любого уровня код на Go смогут понять любые другие разработчики, даже если они в компании работают сутки и пришли сразу после ВУЗа.
Более того, при уходе всех оригинальных разработчиков из команды проект не придется выбрасывать весь, потому что в нем никто не может разобраться, а получится передать другой команде обычных программистов, и они смогут подхватить его в относительно короткие сроки.
Простота поддержки, простота отладки и поиска ошибок, доступность даже для новичков, и минимальные шансы выстрелить себе в ногу — вот что нужно компаниям уровня Гугла для большей части их кода. А оставшуюся меньшую часть можно писать на чем угодно, хоть на ассемблере, если есть такая необходимость.
Дима, Марк, Макс, спасибо вам огромное от всего сообщества и меня лично за эти таблицы, за бит HAP, и за то, что заставили Intel наконец заняться безопасностью своей прошивки, имеющей слишком много привилегий.
Это все очень гладко на бумаге, но позволить себе подобное могут только те, у кого проекты либо очень маленькие, либо очень дорогие, либо на них сидит сотня человек и можно бросить десяток на доводку предупреждений многочисленных компиляторов.
В реальности же абсолютное большинство проектов собирается для одной единственной ОС, одним единственным семейством компиляторов, без warnings-as-errors и прочего, и там от внедрения статического анализа (хоть какого-нибудь, не обязательно конкретно PVS-Studio) польза весьма существенная и доступна она практически сразу.
Про предупреждения компиляторов: ну вот пока еще не один не смог предупредить меня, что у меня две функции имеют одинаковое тело, хотя задумывались разными, что у меня результат вызова функции не влияет на проверяемое значение, что у меня в условии продолжения цикла for используется оператор, в смысле &&, а это так не работает на самом деле, что у меня оптимизатор может удалить цикл ожидания на MMIO-регистре, потому что он не помечен как volatile, и вызов memset для затирания данных на стеке тоже может удалить, потому что он не влияет на наблюдаемое поведение.
Понятно, что добрую половину всего вот этого можно получить, разобравшись с миллионом опций своего компилятора, но тут фишка в том, что сама по себе компиляция при этом с большой вероятностью сломается в стольких местах, что никто по доброй воле эти хитрые предупреждения больше никогда не включит.
Внедрение хорошего статического анализатора туда, где его никогда не было, а код при этом писали на обычном C/C++ (а не на MISRA C с последующей верификацией) обычные люди (не Boeing/Airbus/NASA), за обычные деньги и при постоянного горящих сроках — оно сразу позволяет найти кучу ошибок, просто потому что на танцы с опциями компилятора ни у кого времени нет и никогда не будет.
Можно сделать EFI-снапшоты, если очень сильно хотеть, для этого /boot надо будет сделать не прямо на ESP, а рядом, и на ESP положить shim.efi и драйвер LVM/btrfs/что-там-у-вас-снапшоты-умеет. Если вот этих двоих обновлять при каждом обновлении ядра не понадобится, то будет почти хорошо. Я, конечно, против добавления дополнительных драйверов ФС на критический путь, но если пользователь страшно хочет снапшотов — будут ему снапшоты.
Там почти не о чем писать, к сожалению, потому что любое EFI-приложение может выступать в качестве загрузчика, а написание простейшего EFI-приложения на Хабре уже не разосвещалось, и в тех примерах достаточно заменить в inf-файле DXE_DRIVER на UEFI_APPLICATION, и у вас получится нужный вам загрузчик.
Вы слишком сильно распространяете свой собственный опыт на всю индустрию, мне кажется. «Не нужно мне — значит не нужно никому». Если вы буткитов не видели — это не значит, что их не бывает, а про шифровальщики вроде ExPetr/NotPetya, которые и возможны то исключительно потому, что большинство машин продолжает с удовольствием загружать все подряд из MBR, слышали почти все.
Потому что память у AMD теперь тренирует PSP своей подписанной и зашифрованной прошивкой, а документация рассказывает, как ему mailbox заполнить и где находится бит, на котором надо ждать, пока тренировка закончится.
Так было, только очень-очень давно. Нынешние прошивки переходят в 32-битный реальный режим с плоской памятью практически сразу с ресет-вектора, а в 64-битный — либо в начале фазы DXE, либо перед OS resume vector, то просто потому, что в PEI очень своеобразная вычислительная среда, и там большую часть времени приходится экономить место в L2 cache, поэтому 32-битный режим там все еще используется.
Давайте я поясню, зачем нужен SecureBoot — он позволяет (при правильной реализации) гарантировать, что прошивка передаст управление только подписанному доверенным сертификатом коду, что в свою очередь гарантирует, что а) без вашего ведома ничего лишнего на вашей системе не запустится и б) если загрузчик ОС каким-то образом будет изменен — его подпись нарушится, система не загрузится, и вы неминуемо это заметите.
Тот факт, что по умолчанию UEFI-совместимые прошивки доверяют сертификатам Microsoft CA и UEFI CA — это сделано не для того, чтобы ограничить свободу простого пользователя, а для того, чтобы можно было включить SecureBoot на большинстве устройств и пользователь не заметил бы этого. Да, приходится доверять MS по умолчанию, но когда на 95% процентах продаваемых систем используется Windows — это вполне резонно.
Если вы не хотите доверять MS — ваше право, на абсолютном большинстве плат (точнее, вообще на всех, кроме телефонов с Windows Mobile и планшетов с Windows RT, которые не являются general-purpose hardware) SecureBoot можно перевести в режим Setup, добавить свои сертификаты список доверенных и удалить предустановленные по умолчанию сертификаты MS и производителя платы.
В конце концов, если вам действительно не нужна безопасная загрузка, и вы согласны следить за целостностью загрузчика самостоятельно, SecureBoot можно отключить на любой системе, которая поддерживает режим Setup, просто удалив Platform Key, в таком режиме система загрузит все, что угодно.
Теперь про то, зачем следить за целостностью загрузчика: дело в том, что security history любых современных операционных систем, написанных на С — это сплошная череда локальных повышений привилегий и удаленных исполнений кода, и каждая пара RCE+LPE дает злоумышленнику доступ к вашему загрузчику, который он затем может модифицировать и закрепиться в системе так, что практически никакими средствами уровня ОС получившееся заражение буткитом невозможно ни обнаружить, ни вылечить. История загрузочных вирусов, шифровальщиков и прочих остальных — давняя и славная, а SecureBoot решает проблему с ними раз и насовсем.
В принципе — ничего не мешает, только тяжело это все. Можно запустить гипервизор вместо загрузчика и дальше там уже рулить как угодно, не трогая саму прошивку — это и отлаживать проще, и результат тот же практически, если на всякие вещи вроде редиректа SMI из ВМ наружу и совместного использования NVRAM не думать пока.
Фиг с ним, в принципе, его можно на виртуальной машине запустить, если очень хотеть, только вот непонятно, есть ли для OpenPOWER хоть какие-нибудь приличные ВМ даже за деньги, на которых можно было бы запустить (пусть даже с бубном) всю большую тройку. Ну и там может получиться примерно как с OpenBSD — безопасность Джо обеспечивается в основном его неуловимостью, даже без учета того, что на стоимость рабочей станции с Линуксом на борту можно купить неплохой автомобиль или месяц отдыхать на далеких островах.
Выбора у нас толком нет, потому что приличных RISC-V в кремнии в соседний магазин еще не завезли, а у остальных там те же примерно яйца, вид сбоку. Я, вообще говоря, очень рад, что эти проблемы с МЕ вскрылись сейчас, а не еще через 10 лет, потому что их так намного быстрее починят (или сделают вид, что починили). Пока прошивку никто не атаковал — сидели 20 лет с голым задом и дальше бы сидели, а теперь вон за три года сколько всего… Очень жду подобного развития событий и с МЕ и прочими периферийными контролерами, которые никогда никто не трогал, и не в курсе, насколько там все у всех сломано.
Если они его могут завести так, чтобы он у них работал и жрать не просил — я двумя руками за, пусть расцветают сто цветов, и вот это все.
Просто я когда-то давно уже участвовал краем уха в запуске коребута на нескольких платах congatec (даже в комментариях про это уже писал, ЕМНИП), и могу сказать, что чуть что не так — и ты один в этом мире, иди в IRC и надейся, что тебе там помогут, а не пошлют заткнуться и хакать. Пока за коребутом не встанет большая корпорация и не начнет продавать для него поддержку и нанимать разработчиков на зарплату — из 0.01% затея не вылезет. А т.к. даже Гугл, активно использовавший в прошлом коребут на хромобуках, уже медленно но верно съезжает на вендорский PEI + свой рантайм на go, то дальше этот процент будет, скорее всего, только уменьшатся, пока отличный, в общем то, проект не заглохнет совсем.
Не-не-не, Девид Блейн, это зависит от конкретной прошивки. У AMI, к примеру, тип загрузки управляется отдельно, а состояние CSM — отдельно, причем некоторые экземпляры даже не показывают строчку с CSM On/Off пока пользователь принудительно не отключит вручную все, для чего CSM может быть нужен.
«Нет, я не хочу легаси-загрузку, не хочу ВидеоБИОСы, не хочу легаси рейд, не хочу легаси загрузку по сети, да отключите это ведро уже, собаки злые!»
Опять не в лотерею, а в карты, и не выиграл, а проиграл.
Minix используется только на МЕ10+, дебютировавший на платформе Skylake, так что десяток лет — это на самом деле два с небольшим, т.е. ее официальный анонс состоялся 5 августа 2015 года. До этого использовалась ОСРВ ThreadX.
Во-вторых, термин «бэкдор» для Management Engine — слишком сильный. Софт намного дешевле железа, поэтому на МЕ и повесили столько всего с момента его появления в сетевых картах. Да, теперь МЕ занимается чем попало от загрузки микрокода из FIT до эмуляции устройства TPM 2.0 и поддержки шифрованного А\В канала для HDMI, но это все исключительно потому, что в железе все эти вещи было бы сделать тупо вдесятеро дороже, а процессоры для ПК должны стоить дешево, иначе конкуренты сожрут. Думаете АМД себе в Ryzen добавили PSP от хорошей жизни, или просто потому, что софт дешев, а железо дорого? Вот то то и оно.
Фанатам открытости и свободы посоветую изначально открытые архитектуры вроде RISC-V и OpenPOWER, ибо на x86 и ARM ни того, ни другого уже давно нет.
Из всего вышеперечисленного только Chrome уже написан, и браться его переписывать на Go с нуля нет никакого смысла, все остальное — почему нет? Для хардкорной математики все равно будут использованы готовые библиотеки на С или Фортране (FFI у языка есть, сопряжение хоть и не без проблем, но работает), а для основной grunt work язык Go вполне подходит. Они на нем теперь даже initramfs пишут, так что я не удивлюсь, если напишут и что-нибудь из ML (AI все же слишком сильный термин, на мой взгляд).
Так вот, примерно 90% задач гугла вполне решается на этом самом «С для дураков» без использования кодогенерации, рефлексии, шаблонов, ООП и чего либо еще, и самое главное, что в итоге написанный разработчиками любого уровня код на Go смогут понять любые другие разработчики, даже если они в компании работают сутки и пришли сразу после ВУЗа.
Более того, при уходе всех оригинальных разработчиков из команды проект не придется выбрасывать весь, потому что в нем никто не может разобраться, а получится передать другой команде обычных программистов, и они смогут подхватить его в относительно короткие сроки.
Простота поддержки, простота отладки и поиска ошибок, доступность даже для новичков, и минимальные шансы выстрелить себе в ногу — вот что нужно компаниям уровня Гугла для большей части их кода. А оставшуюся меньшую часть можно писать на чем угодно, хоть на ассемблере, если есть такая необходимость.
В реальности же абсолютное большинство проектов собирается для одной единственной ОС, одним единственным семейством компиляторов, без warnings-as-errors и прочего, и там от внедрения статического анализа (хоть какого-нибудь, не обязательно конкретно PVS-Studio) польза весьма существенная и доступна она практически сразу.
Про предупреждения компиляторов: ну вот пока еще не один не смог предупредить меня, что у меня две функции имеют одинаковое тело, хотя задумывались разными, что у меня результат вызова функции не влияет на проверяемое значение, что у меня в условии продолжения цикла for используется оператор, в смысле &&, а это так не работает на самом деле, что у меня оптимизатор может удалить цикл ожидания на MMIO-регистре, потому что он не помечен как volatile, и вызов memset для затирания данных на стеке тоже может удалить, потому что он не влияет на наблюдаемое поведение.
Понятно, что добрую половину всего вот этого можно получить, разобравшись с миллионом опций своего компилятора, но тут фишка в том, что сама по себе компиляция при этом с большой вероятностью сломается в стольких местах, что никто по доброй воле эти хитрые предупреждения больше никогда не включит.
Внедрение хорошего статического анализатора туда, где его никогда не было, а код при этом писали на обычном C/C++ (а не на MISRA C с последующей верификацией) обычные люди (не Boeing/Airbus/NASA), за обычные деньги и при постоянного горящих сроках — оно сразу позволяет найти кучу ошибок, просто потому что на танцы с опциями компилятора ни у кого времени нет и никогда не будет.
Мужики, у вас версия для MacOS планируется хоть когда-нибудь? Там не должно быть слишком уж больших отличий от версии для Linux, по идее.
Можно сделать EFI-снапшоты, если очень сильно хотеть, для этого /boot надо будет сделать не прямо на ESP, а рядом, и на ESP положить shim.efi и драйвер LVM/btrfs/что-там-у-вас-снапшоты-умеет. Если вот этих двоих обновлять при каждом обновлении ядра не понадобится, то будет почти хорошо. Я, конечно, против добавления дополнительных драйверов ФС на критический путь, но если пользователь страшно хочет снапшотов — будут ему снапшоты.
Там почти не о чем писать, к сожалению, потому что любое EFI-приложение может выступать в качестве загрузчика, а написание простейшего EFI-приложения на Хабре уже не раз освещалось, и в тех примерах достаточно заменить в inf-файле DXE_DRIVER на UEFI_APPLICATION, и у вас получится нужный вам загрузчик.
Тот факт, что по умолчанию UEFI-совместимые прошивки доверяют сертификатам Microsoft CA и UEFI CA — это сделано не для того, чтобы ограничить свободу простого пользователя, а для того, чтобы можно было включить SecureBoot на большинстве устройств и пользователь не заметил бы этого. Да, приходится доверять MS по умолчанию, но когда на 95% процентах продаваемых систем используется Windows — это вполне резонно.
Если вы не хотите доверять MS — ваше право, на абсолютном большинстве плат (точнее, вообще на всех, кроме телефонов с Windows Mobile и планшетов с Windows RT, которые не являются general-purpose hardware) SecureBoot можно перевести в режим Setup, добавить свои сертификаты список доверенных и удалить предустановленные по умолчанию сертификаты MS и производителя платы.
В конце концов, если вам действительно не нужна безопасная загрузка, и вы согласны следить за целостностью загрузчика самостоятельно, SecureBoot можно отключить на любой системе, которая поддерживает режим Setup, просто удалив Platform Key, в таком режиме система загрузит все, что угодно.
Теперь про то, зачем следить за целостностью загрузчика: дело в том, что security history любых современных операционных систем, написанных на С — это сплошная череда локальных повышений привилегий и удаленных исполнений кода, и каждая пара RCE+LPE дает злоумышленнику доступ к вашему загрузчику, который он затем может модифицировать и закрепиться в системе так, что практически никакими средствами уровня ОС получившееся заражение буткитом невозможно ни обнаружить, ни вылечить. История загрузочных вирусов, шифровальщиков и прочих остальных — давняя и славная, а SecureBoot решает проблему с ними раз и насовсем.
Просто я когда-то давно уже участвовал краем уха в запуске коребута на нескольких платах congatec (даже в комментариях про это уже писал, ЕМНИП), и могу сказать, что чуть что не так — и ты один в этом мире, иди в IRC и надейся, что тебе там помогут, а не пошлют заткнуться и хакать. Пока за коребутом не встанет большая корпорация и не начнет продавать для него поддержку и нанимать разработчиков на зарплату — из 0.01% затея не вылезет. А т.к. даже Гугл, активно использовавший в прошлом коребут на хромобуках, уже медленно но верно съезжает на вендорский PEI + свой рантайм на go, то дальше этот процент будет, скорее всего, только уменьшатся, пока отличный, в общем то, проект не заглохнет совсем.
Другие вендоры иногда обзывают настройку CSM выбором ОС, т.е. Win7/other — включен, Win8+ — выключен, например.
«Нет, я не хочу легаси-загрузку, не хочу ВидеоБИОСы, не хочу легаси рейд, не хочу легаси загрузку по сети, да отключите это ведро уже, собаки злые!»