Сопровождающий разработчик стабильной ветки ядра Linux Грег Кроа-Хартман (Greg Kroah-Hartman) привёл убедительные доводы в пользу написания новых драйверов ядра Linux на языке программирования Rust. Кроа-Хартман является ярым сторонником добавления кода на Rust в ядро Linux. Он призвал ментейнеров проекта и разработчиков писать новый код для ядра и драйверов Linux на Rust, а не на C.
Грег Кроа-Хартман утверждает, что подавляющее большинство ошибок ядра Linux вызвано «глупыми маленькими крайнимипограничными случаями в C, которые полностью исчезли в Rust» (stupid little corner cases in C that are totally gone in Rust). Он полностью согласен за постепенный переход от кодовой базы C к новому коду на Rust, где эти проблемы с безопасностью памяти и другие недостатки C невозможны.
«Как человек, который видел почти ВСЕ исправления ошибок в ядре и проблемы безопасности за последние 15+ лет (ну, надеюсь, все они попадают в стабильные ветки, мы иногда пропускаем некоторые, когда сопровождающие/разработчики забывают пометить их как исправления ошибок), и который видит ВСЕ выпущенные патчи против уязвимостей ядра, я думаю, что могу высказаться по этой теме», — уточнил Кроа‑Хартман.
Согласно заявлению Кроа-Хартмана, 30 миллионов строк кода на C ядра Linux никуда не денутся в ближайшее время, но для нового кода/драйверов уже запущен процесс написания на Rust, где такие многие типы ошибок просто не могут произойти (или происходят гораздо реже).
«Почему бы нам не сделать это? C++ не даст нам ничего из этого в ближайшее десятилетие, и проблемы комитета по языку C++, похоже, указывают на то, что всем лучше отказаться от этого языка как можно скорее, если они хотят иметь какую‑либо кодовую базу, которую можно поддерживать в течение любого периода времени», — пояснил Кроа‑Хартман.
Ранее Бьёрн Страуструп представил «профили» для обеспечения безопасности ресурсов и типов в рамках проекта «C++ на стероидах», чтобы помочь разработчикам сосредоточиться на эффективном использовании современного C++ и избежать устаревших «тёмных углов» языка.
«Rust — это не „серебряная пуля“, которая решит все наши проблемы, но этот язык, безусловно, поможет в огромном количестве проблемных мест для новых вещей ядра в будущем. Почему бы нам не использовать его? Linux — это инструмент, который все остальные используют для решения своих проблем, и вот у нас есть разработчики, которые говорят: „Эй, наша проблема в том, что мы хотим писать код для нашего оборудования, которое просто не может иметь все эти типы ошибок автоматически“. Почему мы должны это игнорировать? Да, я понимаю нашу проблему перегруженности работой сопровождающих проекта (я сам один из таких людей), но здесь у нас есть разработчики, которые действительно делают работу!», — завил Кроа‑Хартман.Полное пояснение позиции Кроа-Хартмана в оригинале"As someone who has seen almost EVERY kernel bugfix and security issue for the past 15+ years (well hopefully all of them end up in the stable trees, we do miss some at times when maintainers/developers forget to mark them as bugfixes), and who sees EVERY kernel CVE issued, I think I can speak on this topic.
The majority of bugs (quantity, not quality/severity) we have are due to the stupid little corner cases in C that are totally gone in Rust. Things like simple overwrites of memory (not that rust can catch all of these by far), error path cleanups, forgetting to check error values, and use-after-free mistakes. That's why I'm wanting to see Rust get into the kernel, these types of issues just go away, allowing developers and maintainers more time to focus on the REAL bugs that happen (i.e. logic issues, race conditions, etc.)
I'm all for moving our C codebase toward making these types of problems impossible to hit, the work that Kees and Gustavo and others are doing here is wonderful and totally needed, we have 30 million lines of C code that isn't going anywhere any year soon. That's a worthy effort and is not going to stop and should not stop no matter what.
But for new code / drivers, writing them in rust where these types of bugs just can't happen (or happen much much less) is a win for all of us, why wouldn't we do this? C++ isn't going to give us any of that any decade soon, and the C++ language committee issues seem to be pointing out that everyone better be abandoning that language as soon as possible if they wish to have any codebase that can be maintained for any length of time.
Rust also gives us the ability to define our in-kernel apis in ways that make them almost impossible to get wrong when using them. We have way too many difficult/tricky apis that require way too much maintainer review just to "ensure that you got this right" that is a combination of both how our apis have evolved over the years (how many different ways can you use a 'struct cdev' in a safe way?) and how C doesn't allow us to express apis in a way that makes them easier/safer to use. Forcing us maintainers of these apis to rethink them is a GOOD thing, as it is causing us to clean them up for EVERYONE, C users included already, making Linux better overall.
And yes, the Rust bindings look like magic to me in places, someone with very little Rust experience, but I'm willing to learn and work with the developers who have stepped up to help out here. To not want to learn and change based on new evidence (see my point about reading every kernel bug we have.)
Rust isn't a "silver bullet" that will solve all of our problems, but it sure will help in a huge number of places, so for new stuff going forward, why wouldn't we want that?
Linux is a tool that everyone else uses to solve their problems, and here we have developers that are saying "hey, our problem is that we want to write code for our hardware that just can't have all of these types of bugs automatically".
Why would we ignore that?
Yes, I understand our overworked maintainer problem (being one of these people myself), but here we have people actually doing the work!
Yes, mixed language codebases are rough, and hard to maintain, but we are kernel developers dammit, we've been maintaining and strengthening Linux for longer than anyone ever thought was going to be possible. We've turned our development model into a well-oiled engineering marvel creating something that no one else has ever been able to accomplish. Adding another language really shouldn't be a problem, we've handled much worse things in the past and we shouldn't give up now on wanting to ensure that our project succeeds for the next 20+ years. We've got to keep pushing forward when confronted with new good ideas, and embrace the people offering to join us in actually doing the work to help make sure that we all succeed together.
thanks,
greg k-h"
Ранее Линус Торвальдс в частном порядке заявил, что продолжит добавлять в свой проект код Rust. Эти действия будут происходить несмотря на возражения многих мейнтейнеров ядра Linux против кода Rust, фактически сделав принятие Rust неизбежным для всех участников сообщества.
Сторонники внедрения Rust в ядро озвучили следующие цели этого мероприятия:
написание нового кода на языке Rust снизит риск ошибок при работе с памятью и состояний гонки, а также исключит некоторые логические ошибки.
мейнтейнерам будет проще рецензировать изменения и проводить рефакторинг модулей с учётом гарантий, предоставляемых языком Rust.
наличие абстракций, использующих продвинутые возможности языка Rust, упростит создание новых драйверов и модулей.
поддержка современного языка привлечёт к разработке ядра новых участников.
применение возможностей инструментария Rust упростит выполнение требований к документированию кода. Например, в проекте Rust for Linux введено требование по обязательному документированию публичных API, требований к безопасности, unsafe‑блоков и инвариантов типов.
Источник новости: habr.com
