KanuTaH дело говорит, пока на вендоры железа не начнут писать на Расте свои BSP, потребителей этих BSP, всяких OEM, ODM и IBV пересадить на него будет очень сложно, потому что сразу вылезут все проблемы с интеграцией (и реинтеграцией постоянной, потому что вендор обновляет свой код регулярно), о которых я тут и пишу.
Я не соглашусь с тем, что это проблема Раста, нет, это проблема косности и нежелания вендоров переходить на более качественный язык, но пока их все устраивает на С (а их все устаивает, они с ассемблера кое-как перелезли совсем недавно, меньше 15 лет назад), ничего со своей стороны они менять не станут — это дорого, а софтом они не торгуют (т.е. софт может быть любого качества, лишь бы работал хоть как-то).
От того, что инфраструктуры у С в принципе нет, ее каждый крупный проект и каждая крупная компания пишет самостоятельно и под свои задачи. В итоге, когда требуется интеграция Раста как еще одного ЯП в добавок к ассемблеру, С, ASL и VFR, начинаются сложности, потому что либо придется лишаться преимуществ cargo, либо придется как-то женить cargo и существующую инфраструктуру, чтобы не разломать обе. Это вот — целый проект на несколько месяцев само по себе, а всем некогда — задач полно, сроки подходят. Апдейты EDK2 — целое приключение, а тут нужно добавить целый новый ЯП…
Про стандарт: дело не в том, что он нигде не реализован весь (весь он и не нужен), а в том, что в компиляторе можно быть уверенным сколько-нибудь, особенно если у вас архитектура какая-нибудь непопулярная. Мне от этой уверенности не жарко и не холодно (потому что EFI использует последние версии clang, а не сертифицированный компилятор, отлитый в бронзе), но я знаю людей, которым нужен и стандарт, и сертифицированный компилятор, и которые без них никуда не перейдут.
вы описываете проблемы, которые возникнут при смешивании двух разных языков
Действительно, потому что уже писал, что если начинать писать с нуля — Раст нормальный уже сейчас, но с нуля прошивки сейчас мало кто пишет, начинают с существующей кодовой базы из BSP, EDK2 и набора собственного уже написанного кода, который весь переписывать никому не интересно — он работает уже сейчас.
Какие такие заголовочные файлы с typedef, которые (.h) в расте в принципе отсутствуют?
Почти все интерфейсы между модулями в EFI описаны в виде т.н. протоколов, которые по факту — С-структуры с указателями на функции. Выглядят они примерно вот так. Таких файлов в проекте — море разливаное, и нужен инструмент, который автоматически генерировал бы из них определения, понятные коду на Расте (потому что держать два источника этих определений — преступление, они тут же разойдутся). Смотрел полгода назад — утилиты такой не нашел, все конвертеры c2rust не могут прожевать typedef'ы, union'ы и битовые поля, а в коде прошивки их очень много.
Вся инфраструктура сыроватая, стандарта у языка нет, компилятор единственный и не сертифицированный.
Если прошивку прямо с нуля на нем разрабатывать — можно уже сейчас, если вот эти проблемы выше не блокируют, а вот если внедрять какие-то куски на Расте в уже существующую большую кодовую базу на С, то начинаются проблемы вроде невозможности использования заголовочных файлов с typedef, и неполной совместимости моделей памяти и владения (отчего половина glue-кода получается внутри unsafe-блоков), различия в подходах и т.п.
Короче — работы по внедрению много, а то, что результат в итоге получится сильно лучше, чем без такого внедрения — на воде вилами писано, поэтому бизнес пока что вставать в стройные ряды Rust Evangelism Task Force не спешит.
Сыровато пока, и разработчиков нет толком. Я стараюсь для себя больше на С и С++ не писать (за исключением поддержки уже написанных проектов), но на работе альтернативы С пока нет.
Доказывать нужно не отсутствие, а наличие. Тот факт, что для Линукса производитель железа не написал драйверов, а для Windows — написал, это не от того, что он хочет усложнить жизнь пользователям Линукса, а для того, чтобы у него на железе работала Windows.
Большей части производителей железа ультрафиолетов Линукс и все, что связано с ним, поэтому и мешать ему специально никто не будет — это дополнительные затраты, которые никогда не отобьются.
если эта технология скомпрометирована
А без этого она у вас скомпрометирована по умолчанию при тех же самых вводных (сложно и обнаружить заразу, и вывести ее). Более того, программатор помогает и там, и там, просто вам теперь прошивку не дают модифицировать.
Дело не в бородочах или корпорациях, дело в популярности той или иной ОС.
Популярность эта тоже взялась не из ниоткуда, и продолжается 20+ лет не из ничего. При этом у линукса как была доля меньше 1% на десктопах, так и остается, потому что пользователю вообще нет разницы, что у него за ОС, если она исполняет его задачи, а производителю железа поддержка каждой дополнительной ОС влетает в серьезную копеечку, которую нужно каким-то образом себе вернуть.
Никто из вендоров не будет думать о какой-либо другой ОС, у них задача сорвать куш, не более
Истинно так, задача ОЕМа — денег заработать своим акционерам, и потому он выбирает между увеличением издержек на поддержку Линукса и потенциальным увеличением прибыли от его любителей.
Андроид, технически это тоже ядро линукс с теми же бородачами (в т.ч из гугла)
Практически, Андроид — это не Линукс, хоть там и ядро от него. Там Гугл четко разделил систему на BSP и драйверы (которые, часто вместе с поддержкой, нужно покупать у производителя процессора и чипсета вместе с его железом), написанные вендором, и юзерспейс, написаный Гуглом. То, что этот юзерспейс раздают бесплатно под открытой лицензией означает только то, что любой китайский нонейм может брать и использовать его, но при этом у Гугла таки можно купить поддержку, получить собственного FAE, у них есть набор тестов для проверки совместимости и вот это все, отличающее продукт от поделки на коленке.
Что такое «в ущерб другим» в данном случае? Как именно предустановка ключа от Windows (за который OEM заплатил) мешает Линуксу? Что именно в BIOS «заточили на поддержку только Windows»?
ОЕМ «затачивает» свою машину под совместимость с Windows ровно потому, что на ней предустановлена Windows и будет установлена Windows с вероятностью больше 95%. Если у ОЕМа есть деньги и желание обеспечивать совместимость с Linux, FreeBSD, OpenBSD и прочими, чтобы обеспечить себе конкурентное преимущество в среде их пользователей — ему все карты в руки. Пока что этим занимаются только крупные корпорации, у мелких китайских ОЕМов денег на тестирование чего-то, кроме Windows, нет. В каком месте тут сговор и с кем — мне не ясно.
Ничего из перечисленного не работает и до передачи управления загрузчику (потому что в прошивке нет кода, выполняемого атакующим и способного на атаку по сторонним каналам, а если таковой есть — атакующий уже победил, и в таковой атаке нет смысла), и в SMM (потому что все ядра переходят в него и пока не перейдут, никакой код там не исполняется).
Ошибки в железе были и будут, потому что оно умопомрачительно сложное само по себе, но их наличие — не повод отказываться от защиты прошивки.
UPD: поискал, оказывается, на SMM таки можно наброситься через Spectre, но при неизвестных адресах и недоступности SMRAM даже на чтение это сродни поиску иголки в открытом космосе.
На вид — обыкновенный AMI Aptio 4, должен сбрасываться из BIOS Setup.
Если на самом деле отказывается, можно сбросить на программаторе без особых проблем, но мне слабо верится, что проблема вызвана повреждением именно NVRAM (а не ME FS, к примеру).
Технологии защиты низкого уровня позволяют защитить от вредоносных действий саму ОС, которая в свою очередь позволяет защитить данные пользователя. Работающая защита ядра и процессов ОС возможна только при условии, что все, что было выполнено до нее — не скомпрометировано, именно этого Microsoft и пытается добиться своими изменениями.
Про Линукс: задачи не дать его установить не ставилось и не стоит до сих пор, но и поддерживать его на каком-то рынке, кроме серверного, большей части производителей смысла нет, потому что с одной стороны у тебя комбинаторный взрыв при тестировании от обилия разных дистрибутивов и вариантов, а с другой — вместо понятной коммерческой компании, у которой можно купить поддержку, и которая при необходимости предоставит своих Field Application Engineer'ов, у вас в партнерах какие-то бородачи в мейлинг-листах, которые на половину вопросов отвечают «заткнитесь и хакайте», на другую половину не отвечают вообще, а присланные патчи разносят в пух и прах, ибо они сделаны не по их канону и гайдлайнам.
Вендорам при этом нужен не красивый код и одобрение Торвальдса лично, а железка работающая плюс-минус как-нибудь, зато выпущенная точно в срок, потому что десктопное железо — продукт очень низкомаржинальный, и не успевшие пару-тройку раз к day1 производители вылетают с рынка на раз.
Либо линуксоиды начинают делать свое железо, изначально все поддерживающее из коробки, либо за ними встает корпорация, которая наводит там унификацию и порядок, выдает документацию и тестовые наборы, продает поддержку и предоставляет FAE, либо позволить себе его смогут только крупные корпорации вроде Lenovo, Dell и HP, и только в очень узких рамках одного-двух самых популярных дистрибутивов новейшей на момент выпуска железок версии (и то исключительно потому, что корпорации эти могут ждать полгода, пока их карманные бородачи на зарплате не напишут им драйверы, угодные хозяевам балагана).
Напротив, шанс получить вот такое станет меньше, потому что TPM будет на критическом пути и тестировать взаимодействие с ним (в том числе сброс и проверку физического присутствия) станут лучше.
Крипточипы, кроме новых проблем, приносят и новые возможности: действительно безопасную загрузку (т.е. буткиты уже не зашифруют вам диск целиком), безопасную биометрическую идентификацию без риска утечки данных, безопасное хранилище критических данных вроде кредитных карт, полнодисковое шифрование, которому никакой дополнительный софт не нужен, и т.п.
Если вам ничего этого не нужно — отлично, на рынке пока еще достаточно вендоров, у которых никаких крипточипов нет и не предвидится, если вам такие по душе — голосуйте за них рублем.
Кроме того, есть и вендоры, которые изначально нацелены на продвинутого пользователя и передают ему всю безопасность в руки, System76 или Raptor CS, например.
Но так ведь всегда было с любым железом любых производителей, которые поддержку Linux из коробки не декларируют (а Apple, на моей памяти, не декларировала таковую никогда).
Добавлю от себя к этому списку:
— написаной на языке, на котором критический для безопасности платформы код писать практически невозможно, потому что это требует нечеловеческой концентрации внимания.
— разрабатываемой кучей плохо связанных друг с другом вендоров, половина из которых вообще не выпускает никаких продуктов для конечного пользователя, а другая не имеет никакого понятия о том, как разрабатывать ПО (потому что они разрабатывают железо и продают его же), и не имеет штатных специалистов по безопасности вообще.
— сляпаной в спешке из копипасты и говнокода, т.к. практически все разработчики прошивок имеют крайне строгие дедлайны (привязанные к выходу новых процессоров, которые, внезапно, выпускает совсем другая компания, которой на ОЕМов наплевать) и потому вынуждены выпускать то, что получилось. При этом процессоры (одинаковые по сути, но разные по маркировке) выходят каждые 6-9 месяцев, и обновлять продукты ОЕМы вынуждены в том же цикле, т.е. на разработку и отладку прошивок банально нет времени, какая уж тут безопасность…
— имеющей древние неисправленные уязвимости, потому что цена ошибок при обновлении очень высока (сломанное железо, возврат по гарантии, недовольные пользователи) и сами обновления дороги (тестирование долгое и дорогое, повторная сертификация долгая жутко и дорогая до невозможности), обновления выпускаются либо очень поздно, либо вообще никогда, т.е. любые проблемы безопасности остаются неисправленными на реальном железе практически вечно.
Можно добавить еще десяток, но я опасаюсь за свои НДА…
Улучшения безопасности SMM и нормальная цепочка доверия от железа будут полезны любой ОС, которая поддерживает UEFI SecureBoot. Поддержу TPM2 для DRTM и TXT (и его аналогов от AMD и Qualcomm) нужно будет добавить либо в ядро, либо в один из загрузчиков (Google работает над этим в данный момент), чтобы получилось использовать и их.
По сути, MS вынужден был заставить своих ОЕМов починить известные проблемы безопасности своих прошивок, организовать относительно нормальную цепочку доверия, следить за обнаруженными уязвимостями и исправлять их по мере сил. Вот это — очень ценно само по себе, даже если вместо Windows используется иная ОС.
Отличная инициатива, поддерживаю двумя руками, но пока что непонятно, насколько это все будет хорошо реализовано в реальном железе, а не в восторженных пресс-релизах.
Желание MS убрать прошивку из цепочки доверия понятно — они ее не контролируют толком, вендоров даже своих карманных (тем более тайваньских ОЕМов, которые выпускают львиную долю плат на рынке десктопов) не могут заставить реализовать все нужные им технологии защиты должным образом, но при этом вынуждены базировать свои весьма неплохие технологии защиты ядра через виртуализацию (которые они реализовали и отладили на Xbox 360 и Xbox One, вот отличный доклад Тони Чена) на очень непрочном фундаменте из говна и палок.
Конечному пользователю ОС это все не очень интересно, и ограничит его не очень сильно (кроме тех случаев, когда сам пользователь хочет патчить прошивку, аж кушать не может), зато потенциальному атакующему сильно усложнит жизнь (при условии, что в реализации не окажется чемодана багов, конечно).
Я не соглашусь с тем, что это проблема Раста, нет, это проблема косности и нежелания вендоров переходить на более качественный язык, но пока их все устраивает на С (а их все устаивает, они с ассемблера кое-как перелезли совсем недавно, меньше 15 лет назад), ничего со своей стороны они менять не станут — это дорого, а софтом они не торгуют (т.е. софт может быть любого качества, лишь бы работал хоть как-то).
Про стандарт: дело не в том, что он нигде не реализован весь (весь он и не нужен), а в том, что в компиляторе можно быть уверенным сколько-нибудь, особенно если у вас архитектура какая-нибудь непопулярная. Мне от этой уверенности не жарко и не холодно (потому что EFI использует последние версии clang, а не сертифицированный компилятор, отлитый в бронзе), но я знаю людей, которым нужен и стандарт, и сертифицированный компилятор, и которые без них никуда не перейдут.
Почти все интерфейсы между модулями в EFI описаны в виде т.н. протоколов, которые по факту — С-структуры с указателями на функции. Выглядят они примерно вот так. Таких файлов в проекте — море разливаное, и нужен инструмент, который автоматически генерировал бы из них определения, понятные коду на Расте (потому что держать два источника этих определений — преступление, они тут же разойдутся). Смотрел полгода назад — утилиты такой не нашел, все конвертеры c2rust не могут прожевать typedef'ы, union'ы и битовые поля, а в коде прошивки их очень много.
Если прошивку прямо с нуля на нем разрабатывать — можно уже сейчас, если вот эти проблемы выше не блокируют, а вот если внедрять какие-то куски на Расте в уже существующую большую кодовую базу на С, то начинаются проблемы вроде невозможности использования заголовочных файлов с typedef, и неполной совместимости моделей памяти и владения (отчего половина glue-кода получается внутри unsafe-блоков), различия в подходах и т.п.
Короче — работы по внедрению много, а то, что результат в итоге получится сильно лучше, чем без такого внедрения — на воде вилами писано, поэтому бизнес пока что вставать в стройные ряды Rust Evangelism Task Force не спешит.
Большей части производителей железа ультрафиолетов Линукс и все, что связано с ним, поэтому и мешать ему специально никто не будет — это дополнительные затраты, которые никогда не отобьются.
А без этого она у вас скомпрометирована по умолчанию при тех же самых вводных (сложно и обнаружить заразу, и вывести ее). Более того, программатор помогает и там, и там, просто вам теперь прошивку не дают модифицировать.
Истинно так, задача ОЕМа — денег заработать своим акционерам, и потому он выбирает между увеличением издержек на поддержку Линукса и потенциальным увеличением прибыли от его любителей.
Практически, Андроид — это не Линукс, хоть там и ядро от него. Там Гугл четко разделил систему на BSP и драйверы (которые, часто вместе с поддержкой, нужно покупать у производителя процессора и чипсета вместе с его железом), написанные вендором, и юзерспейс, написаный Гуглом. То, что этот юзерспейс раздают бесплатно под открытой лицензией означает только то, что любой китайский нонейм может брать и использовать его, но при этом у Гугла таки можно купить поддержку, получить собственного FAE, у них есть набор тестов для проверки совместимости и вот это все, отличающее продукт от поделки на коленке.
ОЕМ «затачивает» свою машину под совместимость с Windows ровно потому, что на ней предустановлена Windows и будет установлена Windows с вероятностью больше 95%. Если у ОЕМа есть деньги и желание обеспечивать совместимость с Linux, FreeBSD, OpenBSD и прочими, чтобы обеспечить себе конкурентное преимущество в среде их пользователей — ему все карты в руки. Пока что этим занимаются только крупные корпорации, у мелких китайских ОЕМов денег на тестирование чего-то, кроме Windows, нет. В каком месте тут сговор и с кем — мне не ясно.
Ошибки в железе были и будут, потому что оно умопомрачительно сложное само по себе, но их наличие — не повод отказываться от защиты прошивки.
UPD: поискал, оказывается, на SMM таки можно наброситься через Spectre, но при неизвестных адресах и недоступности SMRAM даже на чтение это сродни поиску иголки в открытом космосе.
Если на самом деле отказывается, можно сбросить на программаторе без особых проблем, но мне слабо верится, что проблема вызвана повреждением именно NVRAM (а не ME FS, к примеру).
Про Линукс: задачи не дать его установить не ставилось и не стоит до сих пор, но и поддерживать его на каком-то рынке, кроме серверного, большей части производителей смысла нет, потому что с одной стороны у тебя комбинаторный взрыв при тестировании от обилия разных дистрибутивов и вариантов, а с другой — вместо понятной коммерческой компании, у которой можно купить поддержку, и которая при необходимости предоставит своих Field Application Engineer'ов, у вас в партнерах какие-то бородачи в мейлинг-листах, которые на половину вопросов отвечают «заткнитесь и хакайте», на другую половину не отвечают вообще, а присланные патчи разносят в пух и прах, ибо они сделаны не по их канону и гайдлайнам.
Вендорам при этом нужен не красивый код и одобрение Торвальдса лично, а железка работающая плюс-минус как-нибудь, зато выпущенная точно в срок, потому что десктопное железо — продукт очень низкомаржинальный, и не успевшие пару-тройку раз к day1 производители вылетают с рынка на раз.
Либо линуксоиды начинают делать свое железо, изначально все поддерживающее из коробки, либо за ними встает корпорация, которая наводит там унификацию и порядок, выдает документацию и тестовые наборы, продает поддержку и предоставляет FAE, либо позволить себе его смогут только крупные корпорации вроде Lenovo, Dell и HP, и только в очень узких рамках одного-двух самых популярных дистрибутивов новейшей на момент выпуска железок версии (и то исключительно потому, что корпорации эти могут ждать полгода, пока их карманные бородачи на зарплате не напишут им драйверы, угодные хозяевам балагана).
Если вам ничего этого не нужно — отлично, на рынке пока еще достаточно вендоров, у которых никаких крипточипов нет и не предвидится, если вам такие по душе — голосуйте за них рублем.
Кроме того, есть и вендоры, которые изначально нацелены на продвинутого пользователя и передают ему всю безопасность в руки, System76 или Raptor CS, например.
— написаной на языке, на котором критический для безопасности платформы код писать практически невозможно, потому что это требует нечеловеческой концентрации внимания.
— разрабатываемой кучей плохо связанных друг с другом вендоров, половина из которых вообще не выпускает никаких продуктов для конечного пользователя, а другая не имеет никакого понятия о том, как разрабатывать ПО (потому что они разрабатывают железо и продают его же), и не имеет штатных специалистов по безопасности вообще.
— сляпаной в спешке из копипасты и говнокода, т.к. практически все разработчики прошивок имеют крайне строгие дедлайны (привязанные к выходу новых процессоров, которые, внезапно, выпускает совсем другая компания, которой на ОЕМов наплевать) и потому вынуждены выпускать то, что получилось. При этом процессоры (одинаковые по сути, но разные по маркировке) выходят каждые 6-9 месяцев, и обновлять продукты ОЕМы вынуждены в том же цикле, т.е. на разработку и отладку прошивок банально нет времени, какая уж тут безопасность…
— имеющей древние неисправленные уязвимости, потому что цена ошибок при обновлении очень высока (сломанное железо, возврат по гарантии, недовольные пользователи) и сами обновления дороги (тестирование долгое и дорогое, повторная сертификация долгая жутко и дорогая до невозможности), обновления выпускаются либо очень поздно, либо вообще никогда, т.е. любые проблемы безопасности остаются неисправленными на реальном железе практически вечно.
Можно добавить еще десяток, но я опасаюсь за свои НДА…
По сути, MS вынужден был заставить своих ОЕМов починить известные проблемы безопасности своих прошивок, организовать относительно нормальную цепочку доверия, следить за обнаруженными уязвимостями и исправлять их по мере сил. Вот это — очень ценно само по себе, даже если вместо Windows используется иная ОС.
Желание MS убрать прошивку из цепочки доверия понятно — они ее не контролируют толком, вендоров даже своих карманных (тем более тайваньских ОЕМов, которые выпускают львиную долю плат на рынке десктопов) не могут заставить реализовать все нужные им технологии защиты должным образом, но при этом вынуждены базировать свои весьма неплохие технологии защиты ядра через виртуализацию (которые они реализовали и отладили на Xbox 360 и Xbox One, вот отличный доклад Тони Чена) на очень непрочном фундаменте из говна и палок.
Конечному пользователю ОС это все не очень интересно, и ограничит его не очень сильно (кроме тех случаев, когда сам пользователь хочет патчить прошивку, аж кушать не может), зато потенциальному атакующему сильно усложнит жизнь (при условии, что в реализации не окажется чемодана багов, конечно).