Мы тут, мне кажется, говорим про разную безопасность, я — про «security», а вы — про «safety». Более того, одним только переходом на другой ЯП дело точно не ограничится, и это вовсе не серебряная пуля, но без этого перехода ограничения становятся слишком сильные, разработка слишком медленной и дорогой, и потому security продолжают заметать под ковер в погоне за сроками.
Safety — это отдельная тема, которой я касался не очень сильно, и довольно давно, поэтому разговор предметный по ней не поддержу, прошу пардону.
Мы тут, мне кажется, уже перешли на обсуждение проектов вообще, а не только таких мелких, как в этой статье. Я согласен с тем, что там, где можно использовать Питон, Раст тоже отлично зайдет.
Запрос на замену С на низком уровне идет сейчас с нескольких сторон, и производительность — не самая популярная из них, на мой взгляд. Код на и на Расте, и на С — достаточно быстрый, а критические части все равно придется писать на чем-то, напрямую ложащемся на архитектуру, будь это ассемблер или что-то еще похожее.
Я безопасник, и потому мне замена С нужна для того, чтобы среднестатистический код, написанный среднестатистическим обычным разработчиком-мидлом (который мало что понимает во всей этой безопасности ненужной, он по своей предметной области специалист) перестал быть невыносимо отвратительным с точки зрения сопротивления внешним воздействиям. Если такой достаточно-безопасный код при этом еще и нормально переживет нахождение в большом репозитории на несколько десятков проектов, в который каждый день коммитят несколько десятков человек, и его безопасность не деградирует со временем до состояния «след простыл» — моя жизнь станет значительно лучше, и CVE станет значительно меньше.
Опыт при этом показывает, что С в данном случае не помогает ничего, ни тулинг, ни грамотное управление, ни внедрение SDL, ни обучение всех разработчиков основам security mindset, потому что инструмент никогда под безопасность не затачивался, и требует соблюдение железной дисциплины не просто от программиста, а вообще от всех программистов, когда либо трогавших код на нем.
Писать безопасный код на С нечеловечески сложно, медленно, и потому дорого, от этого дырявое нынче абсолютно все, и очень много усилий направлено в итоге на то, чтобы заставить всю эту гору кода на С и его производных, которую мы все уже написали и вынуждены использовать и поддерживать, вести себя хоть в каких то рамках приличия. В железо пришлось затащить и теневой стек (чтобы хоть как-то бороться с ROP), и шифрованную и\или тегированную память, и компартментализацию (многоуровневую), и даже контракты (CHERI), и занесут еще вагон всего, только бы ПО не чинить.
В общем, Раст — это шаг в очень правильном направлении, и я его приветствую всеми фибрами души.
Согласен с тем, что свидетелям святого дедлайна и поборникам стиля куяк-куяк-и-в-прод замена С на Раст поможет мало, и они в своем новом коде тоже начнут срезать углы направо и налево. При этом даже в таком говно-расте срезанные углы можно искать поиском по unsafe, плюс компилятор не даст собрать совсем уже невообразимую херню вроде замены "&" на "&&" или "&&" на ",".
В приличных местах (где за качество результата все таки готовы сколько-нибудь отвечать) говнокодеров рано или поздно либо перевоспитывают, либо изгоняют, и остаются люди, которые хотели бы писать на С хороший, добротный код, решающий их задачи и не отнимающий на написание слишком много времени, но они не могут, даже если хотят, потому что это выше человеческих сил.
На Расте, все же, намного проще писать, потому что нужно меньше вещей держать в голове (управление ресурсами в коде, переполнение буферов отслеживается компилятором, инициализация автоматическая, молчаливых приведений типов нет, молчаливых знаковых расширений нет, за арифметику с указателями бьют по рукам, за накидывание структур на память бьют по рукам, и т.п.), т.е. по итогу писать нормально, стабильно выдавая подходящий результат за разумное время, на нем может большее количество людей, и ошибок в коде получается в среднем меньше, по крайней мере мне так показалось. На С же нужна предельная концентрация внимания, постоянные проверки и перепроверки, вагон всякого тулинга и анализаторов, а в результате все равно имеем вот такое:
Толк будет в любом случае, я думаю, потому что затраты на поддержку низкого уровня ошибок теперь переложены на компилятор (который не устает), и в долгую эта стратегия все-таки окупается так или иначе. Безопасники давят со своей стороны, хоть и несильно, но стабильно, плюс можно оказаться в авангарде прогресса и получить бесплатную рекламу, плюс те подходы к дизайну, которые вынуждает применять Раст (иммутабельность по умолчанию, RAII, pattern matching, data race safety) — они сами по себе часто приводят к ускорению и упрощению кода, и получается тут на 5% быстрее стало, тут на 10% меньше ошибок, с миру по нитке — вот новый телевизор.
Рано или поздно на Раст (или другой более безопасный, но все еще достаточно низкоуровневый ЯП) все равно перейдут (т.к. С для потоковой коммерческой разработки — это все-таки очень плохой инструмент, скальпель в руках коновала), потому что их додавят таки безопасники, но не думаю, что это получится сделать скоро.
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, и только в очень узких рамках одного-двух самых популярных дистрибутивов новейшей на момент выпуска железок версии (и то исключительно потому, что корпорации эти могут ждать полгода, пока их карманные бородачи на зарплате не напишут им драйверы, угодные хозяевам балагана).
Safety — это отдельная тема, которой я касался не очень сильно, и довольно давно, поэтому разговор предметный по ней не поддержу, прошу пардону.
Я безопасник, и потому мне замена С нужна для того, чтобы среднестатистический код, написанный среднестатистическим обычным разработчиком-мидлом (который мало что понимает во всей этой безопасности ненужной, он по своей предметной области специалист) перестал быть невыносимо отвратительным с точки зрения сопротивления внешним воздействиям. Если такой достаточно-безопасный код при этом еще и нормально переживет нахождение в большом репозитории на несколько десятков проектов, в который каждый день коммитят несколько десятков человек, и его безопасность не деградирует со временем до состояния «след простыл» — моя жизнь станет значительно лучше, и CVE станет значительно меньше.
Опыт при этом показывает, что С в данном случае не помогает ничего, ни тулинг, ни грамотное управление, ни внедрение SDL, ни обучение всех разработчиков основам security mindset, потому что инструмент никогда под безопасность не затачивался, и требует соблюдение железной дисциплины не просто от программиста, а вообще от всех программистов, когда либо трогавших код на нем.
Писать безопасный код на С нечеловечески сложно, медленно, и потому дорого, от этого дырявое нынче абсолютно все, и очень много усилий направлено в итоге на то, чтобы заставить всю эту гору кода на С и его производных, которую мы все уже написали и вынуждены использовать и поддерживать, вести себя хоть в каких то рамках приличия. В железо пришлось затащить и теневой стек (чтобы хоть как-то бороться с ROP), и шифрованную и\или тегированную память, и компартментализацию (многоуровневую), и даже контракты (CHERI), и занесут еще вагон всего, только бы ПО не чинить.
В общем, Раст — это шаг в очень правильном направлении, и я его приветствую всеми фибрами души.
В приличных местах (где за качество результата все таки готовы сколько-нибудь отвечать) говнокодеров рано или поздно либо перевоспитывают, либо изгоняют, и остаются люди, которые хотели бы писать на С хороший, добротный код, решающий их задачи и не отнимающий на написание слишком много времени, но они не могут, даже если хотят, потому что это выше человеческих сил.
На Расте, все же, намного проще писать, потому что нужно меньше вещей держать в голове (управление ресурсами в коде, переполнение буферов отслеживается компилятором, инициализация автоматическая, молчаливых приведений типов нет, молчаливых знаковых расширений нет, за арифметику с указателями бьют по рукам, за накидывание структур на память бьют по рукам, и т.п.), т.е. по итогу писать нормально, стабильно выдавая подходящий результат за разумное время, на нем может большее количество людей, и ошибок в коде получается в среднем меньше, по крайней мере мне так показалось. На С же нужна предельная концентрация внимания, постоянные проверки и перепроверки, вагон всякого тулинга и анализаторов, а в результате все равно имеем вот такое:
Рано или поздно на Раст (или другой более безопасный, но все еще достаточно низкоуровневый ЯП) все равно перейдут (т.к. С для потоковой коммерческой разработки — это все-таки очень плохой инструмент, скальпель в руках коновала), потому что их додавят таки безопасники, но не думаю, что это получится сделать скоро.
NVIDIA, кстати, недавно перешла на ADA/SPARK для своих automotive-проектов.
Я не соглашусь с тем, что это проблема Раста, нет, это проблема косности и нежелания вендоров переходить на более качественный язык, но пока их все устраивает на С (а их все устаивает, они с ассемблера кое-как перелезли совсем недавно, меньше 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, и только в очень узких рамках одного-двух самых популярных дистрибутивов новейшей на момент выпуска железок версии (и то исключительно потому, что корпорации эти могут ждать полгода, пока их карманные бородачи на зарплате не напишут им драйверы, угодные хозяевам балагана).