Google профинансирует добавление поддержки языка rust в ядро linux

Обновлено: 08.01.2025

Компания оплатит год работы Мигеля Охеда (Miguel Ojeda) над его проектом Rust for Linux. Работа будет вестись в рамках проекта Prossimo под эгидой организации ISRG (Internet Security Research Group) — учредителя проекта Let's Encrypt.

По данным Microsoft около 70% всех уязвимостей, описанных в CVE, вызваны небезопасной работой с памятью. Написание на Rust таких компонентов, как драйверы устройств, может снизить риск появления уязвимостей.

Написание на Rust таких компонентов, как драйверы устройств, может снизить риск появления уязвимостей.

Если в таком предложении есть слово «может», то зачем оно все надо?

Наоборот. Адекватная новость про Rust. Всякий булшит «про исключает как класс ошибки с памятью», «математически доказана безопасность» и прочие восхваления порождают только флуд и ссылки на CVE в приложениях/библиотеках на Rust.

да, типа прототип. потому один человек. жаль только, что результат будет лишь через год.

crypt ★★★★★ ( 19.06.21 18:24:29 )
Последнее исправление: crypt 19.06.21 18:24:42 (всего исправлений: 1)

Потому что может, лучше чем не может.

С языком С уязвимости тоже могут не появиться, а могут и появится :)

С языком С уязвимости тоже могут не появиться, а могут и появится :)

Значит при прочих равных, в Си могут появиться чаще. Это же всё из разряда, а у меня сосед каждый день бухал и 100 лет прожил.

На наших глазах происходит борьба двух сект, старые|новые свидетели идеального кода на си, вторая состоит из точно таких же, только в них меньше садомазохистских наклонностей, хотя выпендрёжа столько же.

shpinog ★★★ ( 19.06.21 18:39:46 )
Последнее исправление: shpinog 19.06.21 18:40:13 (всего исправлений: 1)

Опять подрывной деятельностью занимаются, мерзкие проприетарщики

Но все таки C секта как-то роднее чем их ржавое корыто.

Кто мешает всякие инструментальные средства контроля С кода пилить, вроде valgrind-ов, sanitizer-ов всяких, статических анализаторов (да хоть, извиняюсь, PVS Studio), которые эффективно устремляют вероятность ошибки работы с памятью к нулю. Нет, обязательно надо какой-то новомодный язычок изобрести и пытаться всё на него переписать, вместо полезной деятельности.

Но все таки C секта как-то роднее чем их ржавое корыто.

А когда было иначе? Даже Иисусу подсрачники в начале давали, просто за то что он новый.

ждём переписывания самого ядра. сишник давно пора выкинуть на помойку, где ему и место

Однажды это всё равно произойдёт. Си язык классный, относительно простой, проверенный десятилетиями. Но он не может жить вечно. Кстати, как обстоят дела у GCC с поддержкой Rust?

Кто мешает всякие инструментальные средства контроля С кода пилить, вроде valgrind-ов, sanitizer-ов всяких, статических анализаторов (да хоть, извиняюсь, PVS Studio), которые эффективно устремляют вероятность ошибки работы с памятью к нулю. Нет, обязательно надо какой-то новомодный язычок изобрести и пытаться всё на него переписать, вместо полезной деятельности.

Говорю же, уровень садо-мазо. Кто будет платить за обучение, или нанимать отдельного тестировщика с знаниями всего этого, платить за разработку и лицензии на всё это. Можно, да можно.

В современном мире рабы сами учат, то что нужно рынку, подрастёт поколение смузи растеров, будут такие же бородатые как Си-шники, и писать более безопасное.

Какой ещё отдельный тестировщик, это уже давно не модно, профессия умерла как класс. Разработчик сам это должен уметь и применять, очевидно же. Ну и во всякий континуус интегрейшен оно должно быть внедрено и бить по рукам автоматически.

будут такие же бородатые как Си-шники, и писать более безопасное.

а что принципиально мешает

valgrind-ов, sanitizer-ов всяких, статических анализаторов (да хоть, извиняюсь, PVS Studio)

Принципиально может и ничего, но боюсь что корпорации с этим не согласны. Я уверен что Rust запихнут максимально глубоко, рано или поздно.

Мне кажется, у них жопа треснет весь существующий полезный сишный код переписать

Какой ещё отдельный тестировщик, это уже давно не модно, профессия умерла как класс.

Да ладно, в прошлом году знакомый устраивался.

Разработчик сам это должен уметь и применять, очевидно же. Ну и во всякий континуус интегрейшен оно должно быть внедрено и бить по рукам автоматически.

Кому должно? Фулл стек рабы, скорее исключение, чем правило.

Всё может быть, Карл!

Как же сейчас задницы бабахнут у луддитов :з

По данным Microsoft около 70% всех уязвимостей, описанных в CVE, вызваны небезопасной работой с памятью.

Скоро это уже как молитву можно будет читать.

Потому что сектантов постоянно ловлят на пропаганде, и теперь они пытаются изображать объективность.

Ты же покажешь, из чего это следует, да? Откуда ты взял это «значит».

На наших глазах происходит борьба двух сект

Ну и как обычно можно видеть попытки приписать оппонентам свои свойства. Это сильно.

Что питонобой может знать о ядре и языках?

Ты же покажешь, из чего это следует, да? Откуда ты взял это «значит».

Зачем? Ты же убеждён, что в поле с дерьмом и на трассе, шанс наступить в парашу одинаковый.

Кому должно? Фулл стек рабы, скорее исключение, чем правило.

Это не «фулл стек», зачем ты врёшь?

Я тебя ранее умножил на ноль по теме твоего недоязычка, зачем ты снова приходишь позориться? И да, как там с сегфолтом на safe c++, родил уже?

Ты опять таблетки забыл принять? :D

Ты же покажешь, из чего это следует, да? Откуда ты взял это «значит».

Ну да, сам напиши, проведи профф аудит с помощью анализаторов, организуй над собой контроль, каждый индус так делает.

Умножеил он на 0, хах. Иди улицы мети, ничтожество.

Я вот тоже не понимаю. Зачем они всех обманывают. Unsafe также есть в С++ …

Какой ещё отдельный тестировщик, это уже давно не модно, профессия умерла как класс. Разработчик сам это должен уметь и применять, очевидно же. Ну и во всякий континуус интегрейшен оно должно быть внедрено и бить по рукам автоматически.

Вот с таких заявлений и начинается глючный и непротестированный говнокод

«фулл-стек» - это что-то из классификации веб-макак, к программистам это не имеет отношения

Я у мамы всё умею (с).

Потому что дошколёнок нихрена не может и не знает. Оно было поймано мной на кукаретинге про «сегфолт на c++», далее ему было приказано либо воспроизвести ту же семантику на safe rust, либо показать сегфолт на safe c++. Это дошколятское отребье ничего не смогло и начало нести рандомную херню и убежала.

Впрочем, это можно видеть и здесь - плебей слился сразу же, одним моим вопросом.

Ты уже не так уверена, растоманя?

Линукс конкурент фуксии, с помощью растомусора гугл уничтожит ядро - профит

Расскажи нам о луддитах, растоманя

Если в таком предложении есть слово «может», то зачем оно все надо?

Это моя редактура, было «позволит снизить риск». Но позволит или нет зависит от того, что делает код и как он написан.

Давайте ещё код писать, компилировать и запускать будут три разных человека. А то специализации недостаточно.

Действительно. Вон там как безликой биомассе ононизмусов припекло - уже который год не могут смириться что за ржавым будущее :D

anonymous-angler ★ ( 19.06.21 19:44:58 )
Последнее исправление: anonymous-angler 19.06.21 19:45:50 (всего исправлений: 1)

Растопомойка к реальному программированию тоже особо отношения не имеет, что не мешает ведомым баранам блеять о его незаменимости

Если компилятором будет gccrs, то это очень даже неплохо.

Потому что может, лучше чем не может.

Кто мешает всякие инструментальные средства контроля С кода пилить, вроде valgrind-ов, sanitizer-ов всяких, статических анализаторов (да хоть, извиняюсь, PVS Studio), которые эффективно устремляют вероятность ошибки работы с памятью к нулю. Нет, обязательно надо какой-то новомодный язычок изобрести и пытаться всё на него переписать, вместо полезной деятельности.

Угу, будем всю эту срань (возможно ещё проприетарную или платную) деплоить, интегрировать, соединять, создавать топики на Лоре «почему санитайзер говорит что мой код пахнет, там же всего три сегфолта и память не может быть считана в одном, но не в критических местах» вместо того, чтобы такие ошибки были закрыты как класс современным языком и компилятором, без наследия тонн c98.

То, что Си может и популярен, и у него один из прекраснейших синтаксисов, но он всё же устаревает. Морально. Поколение смузихлёбов не может и не хочет учить этот язык.

В более ранней публикации компания Google объявила, что в Android теперь поддерживается язык программирования Rust, применяемый в разработке этой ОС как таковой. В связи с этим авторы данной публикации также решили оценить, насколько язык Rust востребован в разработке ядра Linux. В этом посте на нескольких простых примерах рассмотрены технические аспекты этой работы.

На протяжении почти полувека C оставался основным языком для разработки ядер, так как C обеспечивает такую степень управляемости и такую предсказуемую производительность, какие и требуются в столь критичном компоненте. Плотность багов, связанных с безопасностью памяти, в ядре Linux обычно весьма низка, поскольку код очень качественный, ревью кода соответствует строгим стандартам, а также в нем тщательно реализуются предохранительные механизмы. Тем не менее, баги, связанные с безопасностью памяти, все равно регулярно возникают. В Android уязвимости ядра обычно считаются серьезным изъяном, так как иногда позволяют обходить модель безопасности в силу того, что ядро работает в привилегированном режиме.

Предполагается, что Rust уже дозрел до того, чтобы составить компанию C в качестве языка для практической реализации ядра. Rust помогает сократить количество потенциальных багов и уязвимостей безопасности в привилегированном коде, при этом он хорошо сочетается с основой ядра и позволяет поддерживать хорошие показатели производительности.

Поддержка Rust

Был разработан первичный прототип драйвера Binder, позволяющий адекватно сравнивать характеристики безопасности и производительности имеющейся версии на C и ее аналога на Rust. В ядре Linux более 30 миллионов строк кода, поэтому мы не ставим перед собой цель переписать его целиком на Rust, а обеспечить возможность дописывать нужный код на Rust. Мы полагаем, что такой инкрементный подход помогает эффективно использовать имеющуюся в ядре высокопроизводительную реализацию, в то же время предоставляет разработчикам ядра новые инструменты для повышения безопасности памяти и поддержания производительности на уровне в ходе работы.

Мы присоединились к организации Rust для Linux, где сообщество уже много сделало и продолжает делать для добавления поддержки Rust в систему сборки ядра Linux. Также нам нужно проектировать системы таким образом, чтобы фрагменты кода, написанные на двух языках, могли взаимодействовать друг с другом: нас особенно интересуют безопасные абстракции без издержек, которые позволяют коду Rust использовать функционал ядра, написанный на C, а также возможность реализовывать функционал на идиоматическом Rust, который можно гладко вызывать из тех частей ядра, что написаны на C.

Поскольку Rust – новый язык в ядре, у нас также есть возможность обязывать разработчиков придерживаться наилучших практик в области составления документации и соблюдения единообразия. Например, у нас есть конкретные машинно-проверяемые требования, касающиеся использования небезопасного кода: для каждой небезопасной функции разработчик должен документировать те требования, которым должна удовлетворять вызывающая сторона – таким образом, гарантируется безопасность использования. Кроме того, при каждом вызове небезопасных функций разработчик обязан документировать те требования, которые должны удовлетворяться вызывающей стороной в качестве гарантии того, что использование будет безопасным. Кроме того, для каждого вызова к небезопасным функциям (или использования небезопасных конструкций, например, при разыменовании сырого указателя) разработчик должен документировать обоснование, почему делать так безопасно.

Rust славится не только своей безопасностью, но и тем, насколько он полезен и удобен для разработчиков. Далее рассмотрим несколько примеров, демонстрирующих, в чем Rust может пригодиться разработчикам ядра при написании безопасных и корректных драйверов.

Пример драйвера

Рассмотрим реализацию семафорного символьного устройства. У каждого устройства есть актуальное значение; при записи n байт значение устройства увеличивается на n; при каждом считывании это значение понижается на 1, пока значение не достигнет 0, в случае чего это устройство блокируется, пока такая операция декремента не сможет быть выполнена на нем без ухода ниже 0.

Допустим, semaphore – это файл, представляющий наше устройство. Мы можем взаимодействовать с ним из оболочки следующим образом:

Когда semaphore – это устройство, которое только что инициализировано, команда, показанная выше, блокируется, поскольку текущее значение устройства равно 0. Оно будет разблокировано, если мы запустим следующую команду из другой оболочки, так как она увеличит значение на 1, тем самым позволив исходной операции считывания завершиться:

Мы также сможем увеличить счетчик более чем на 1, если запишем больше данных, например:

увеличивает счетчик на 3, поэтому следующие 3 считывания не приведут к блокированию.

Чтобы продемонстрировать еще некоторые аспекты Rust, добавим к нашему драйверу следующие возможности: запомним, каково было максимальное значение, достигнутое в течение всего жизненного цикла, а также запомним, сколько операций считывания выполнил на устройстве каждый из файлов.

Теперь покажем, как такой драйвер был бы реализован на Rust, сравнив этот вариант с реализацией на C. Правда, отметим, что разработка этой темы в Google только начинается, и в будущем все может измениться. Мы хотели бы подчеркнуть, как Rust может пригодиться разработчику в каждом из аспектов. Например, во время компиляции он позволяет нам устранить или сильно снизить вероятность того, что в код вкрадутся целые классы багов, при том, что код останется гибким и будет работать с минимальными издержками.

Символьные устройства

Разработчику необходимо сделать следующее, чтобы реализовать на Rust драйвер для нового символьного устройства:

Реализовать типаж FileOperations : все связанные с ним функции опциональны, поэтому разработчику требуется реализовать лишь те, что релевантны для данного сценария. Они соотносятся с полями в структуре C struct file_operations .
Реализовать типаж FileOpener это типобезопасный эквивалент применяемого в C поля open из структуры struct file_operations .
Зарегистрировать для ядра новый тип устройства: так ядру будет рассказано, какие функции нужно будет вызывать в ответ на операции над файлами нового типа.

Символьные устройства в Rust отличаются целым рядом достоинств по части безопасности:

Все ассоциированные функции в FileOperations получают неизменяемые ссылки на self (подробнее об этом ниже), кроме функции release , которая вызывается последней и получает в ответ обычный объект (а в придачу и владение им). Тогда реализация release может отложить деструкцию объекта, передав владение им куда-нибудь еще, либо сразу разрушить его. При работе с объектом с применением подсчета ссылок «деструкция» означает декремент количества ссылок (фактическое разрушение объекта происходит, когда количество ссылок падает до нуля).

То есть, здесь мы опираемся на принятую в Rust систему владения, взаимодействуя с кодом на C. Мы обрабатываем написанную на C часть кода, которым владеет объект Rust, разрешая ему вызывать функции, реализованные на Rust, а затем, в конце концов, возвращаем владение обратно. Таким образом, коль скоро код на C, время жизни файловых объектов Rust также обрабатывается гладко, и компилятор обязывает поддерживать правильное управление временем жизни объекта на стороне Rust. Например, open не может возвращать в стек указатели, выделенные в стеке, или объекты, выделенные в куче, ioctl / read / write не может высвобождать (или изменять без синхронизации) содержимое объекта, сохраненное в filp->private_data , т.д.

Если разработчику требуется изменить некоторое состояние (а это в порядке вещей), то это можно сделать при помощи внутренней изменяемости : изменяемое состояние можно обернуть в Mutex или SpinLock (или atomics) и безопасно через них изменить.

Во время компиляции это препятствует возникновению багов, при которых разработчику не удается приобрести нужную блокировку при доступе к полю (поле недоступно), или когда разработчику не удается обернуть поле в блокировку (поле предназначено только для чтения).

Причина, по которой FileOperation выделен в собственный типаж (в отличие, например, от open , входящего в состав типажа FileOperations ) – так можно разрешить выполнять регистрацию конкретной реализации файла разными способами.

Статическая типизация: мы пользуемся тем, что в Rust поддерживаются дженерики, поэтому реализуем все вышеупомянутые функции и типы в виде статических типов. Поэтому у разработчика просто нет возможности преобразовать нетипизированную переменную или поле в неправильный тип. В коде на C в вышеприведенной таблице есть приведения от, в сущности, нетипизированного указателя ( void *) к желаемому типу в начале каждой функции: вероятно, в свеженаписанном виде это работает нормально, но также может приводить к багам по мере развития кода и изменения допущений. Rust отловит все такие ошибки еще во время компиляции.

Операции над файлами: как упоминалось выше, разработчику требуется реализовать типаж FileOperations , чтобы настраивать поведение устройства на свое усмотрение. Это делается при помощи блока, начинающегося с impl FileOperations for Device , где Device – это тип, реализующий поведение файла (в нашем случае это FileState ). Оказавшись внутри блока, инструменты уловят, что здесь может быть определено лишь ограниченное количество функций, поэтому смогут автоматически вставить прототипы. (лично я использую neovim и LSP-сервер rust-analyzer .)

При использовании этого типажа в Rust, та часть ядра, что написана на C, все равно требует экземпляр struct file_operations . Контейнер ядра автоматически генерирует такой экземпляр из реализации типажа (а опционально также макрос declare_file_operations ): хотя, в нем и есть код, чтобы сгенерировать корректную структуру, здесь все равно все const , поэтому интерпретируется во время компиляции, и во время выполнения не дает никаких издержек.

Обработка Ioctl

Чтобы драйвер предоставлял собственный обработчик ioctl, он должен реализовывать функцию ioctl , входящую в состав типажа FileOperations , как показано в следующей таблице.

Команды Ioctl стандартизированы таким образом, что, имея команду, мы знаем, предоставляется ли под нее пользовательский буфер, как ее предполагается использовать (чтение, запись, и то, и другое, ничего из этого) и ее размер. В Rust предоставляется диспетчер (для доступа к которому требуется вызвать cmd.dispatch ), который на основе этой информации автоматически создает помощников для доступа к памяти и передает их вызывающей стороне.

Но от драйвера не требуется этим пользоваться. Если, например, он не использует стандартную кодировку ioctl, то Rust подходит к этому гибко: просто вызывает cmd.raw для извлечения сырых аргументов и использует их для обработки ioctl (потенциально с небезопасным кодом, что требуется обосновать).

Но, если в реализации драйвера действительно используется стандартный диспетчер, то ситуация значительно улучшается, поскольку ему вообще не придется реализовывать какой-либо небезопасный код, и:

Указатель на пользовательскую память никогда не является нативным, поэтому пользователь не может случайно разыменовать его.
Типы, позволяющие драйверу считывать из пользовательского пространства, допускают лишь однократное считывание, поэтому мы не рискуем получить баги TOCTOU (время проверки до времени использования). Ведь когда драйверу требуется обратиться к данным дважды, он должен скопировать их в память ядра, где злоумышленник не в силах ее изменить. Если исключить небезопасные блоки, то допустить баги такого класса в Rust попросту невозможно.
Не будет случайного переполнения пользовательского буфера: считывание или запись ни в коем случае не выйдут за пределы пользовательского буфера, которые задаются автоматически на основе размера, записанного в команде ioctl. В вышеприведенном примере реализация IOCTL_GET_READ_COUNT обладает доступом лишь к экземпляру UserSlicePtrWriter , что ограничивает количество доступных для записи байт величиной sizeof(u64) , как закодировано в команде ioctl.
Не смешиваются операции считывания и записи: в ioctl мы никогда не записываем буферы, предназначенные для считывания, и наоборот. Это контролируется га уровне обработчиков чтения и записи, которые получают только экземпляры UserSlicePtrWriter и UserSlicePtrReader соответственно.

Типы, применяемые для чтения и записи пользовательской памяти, не реализуют типажи Send и Sync , и поэтому они (и указатели на них) небезопасны при использовании в другом контексте. В Rust, если бы разработчик попытался написать код, который передавал бы один из этих объектов в другой поток (где использовать их было бы небезопасно, поскольку контекст менеджера памяти там мог быть неподходящим), то получил бы ошибку компиляции.
Вызывая IoctlCommand::dispatch , логично предположить, что нам потребуется динамическая диспетчеризация, чтобы добраться до фактической реализации обработчика (и это повлечет дополнительные издержки, которых не было бы в C), но это не так. Благодаря использованию дженериков, компилятор сделает функцию мономорфной, что обеспечит нам статические вызовы функции. Функцию можно будет даже оформить внутристрочно, если оптимизатор сочтет это целесообразным.

Разработчикам разрешено использовать мьютексы и спинлоки для обеспечения внутренней изменяемости. В нашем примере мьютекс используется для защиты изменяемых данных; в приведенной ниже таблице показаны структуры данных, используемые в C и Rust соответственно, а также показано, как реализовать ожидание и дождаться, пока счет станет ненулевым, и мы сможем выполнить требуемое считывание:

Отметим, что такие операции ожидания вполне обычны в существующем коде на C, например, когда канал ожидает «партнера» для записи, сокет домена unix ожидает данные, а поиск индексного дескриптора ожидает завершения удаления, либо помощник пользовательского режима ожидает изменения состояния.

А вот какими достоинствами обладает соответствующая реализация на Rust:

В следующих примерах показано, как в нашем драйвере реализованы операции open , read и write :

Здесь видны и еще некоторые достоинства Rust:

Оператор ? operator: используется реализациями open и read в Rust для неявного выполнения обработки ошибок; разработчик может сосредоточиться на семафорной логике, и код, который у него получится, будет весьма компактным и удобочитаемым. В версиях на C необходимая обработка ошибок немного замусоривает код, из-за чего читать его сложнее.
Обязательная инициализация: Rust требует, чтобы все поля структуры были инициализированы при ее создании, чтобы разработчик не мог где-нибудь нечаянно забыть об инициализации поля. В C такая возможность не предоставляется. В нашем примере с open , показанном выше, разработчик версии на C мог легко забыть вызвать kref_get (пусть даже все поля и были инициализированы); в Rust же пользователь обязан вызвать clone (повышающую счет ссылок на единицу), в противном случае он получит ошибку компиляции.
Область видимости при RAII: при реализации записи в Rust используется блок выражений, контролирующий, когда inner выходит из области видимости и, следовательно, когда снимается блокировка.
Поведение при целочисленном переполнении: Rust стимулирует разработчиков всегда продумывать, как должны обрабатываться переполнения. В нашем примере с write , мы хотим обеспечить насыщение, чтобы не пришлось плюсовать к нашему семафору нулевое значение. В C приходится вручную проверять, нет ли переполнений, компилятор не оказывает дополнительной поддержки при такой операции.

Облачные серверы от Маклауд быстрые и безопасные.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Любая достаточно развитая технология неотличима от волшебства.

Google профинансирует добавление поддержки языка Rust в ядро Linux

На этой неделе компания Google объявила о намерении профинансировать проект по повышению безопасности Linux путём написания отдельных частей ядра операционной системы на языке программирования Rust. Такое изменение означало бы серьёзный технологический и культурный сдвиг для проекта программного обеспечения с открытым исходным кодом, ставшего основой для обширных областей Интернета и операционных систем, в том числе Android.

Согласно имеющимся данным, написанием частей ядра Linux на Rust будет заниматься Мигель Охеда (Miguel Ojeda), являющийся автором программного обеспечения для ускорителя частиц Большого адронного коллайдера и работавший над безопасностью для языков программирования. Оплату контракта возьмёт на себя Google через некоммерческую организацию Internet Security Research Group.

Предполагается, что добавление в ядро Linux написанных на языке Rust модулей снизит вероятность возникновения уязвимостей, вызванных небезопасной работой с памятью. На момент выхода в 1991 году Linux был написан на языке C, который более уязвим по сравнению с современными языками программирования. Создатель ядра Linux Линус Торвальдс (Linus Torvalds) заявил о готовности к переменам, если будет доказана ценность использования языка Rust для Linux. На данный момент Охеда предложил внести 13 изменений, которые необходимы для запуска модулей Rust в Linux.

Что касается языка Rust, то он был разработан компанией Mozilla, но в настоящее время его развитием занимается некоммерческая организация Rust Foundation. Особое внимание в нём уделяется безопасной работе с памятью. Подразделение безопасности Microsoft ещё в 2019 году заявляло о том, что «Rust представляет собой лучшую альтернативу C и C++».

Rust — язык, возникший из Mozilla — обеспечивает гарантии безопасности памяти для операционной системы Android, которая исторически писалась на C и C ++. Google внедряет Rust в новый код Android, пишет ZDNet.

Читайте в тему:

То же касается и ядра Linux, лежащего в основе Android. Как сообщил в прошлом месяце специалист по открытым исходным кодом ZDNet Стивен Дж. Воан-Николс , разработчики ядра Linux считают, что имеет смысл писать новые части ядра на Rust, а не переписывать все ядро Linux, которое содержит более 30 миллионов строк кода, в основном написанных на С.

«Мы чувствуем, что Rust теперь готов присоединиться к C в качестве практического языка для реализации ядра. Это может помочь нам уменьшить количество потенциальных ошибок и уязвимостей безопасности в привилегированном коде, при этом прекрасно взаимодействуя с ядром ядра и сохраняя его характеристики производительности», объясняет Уэдсон Алмейда Филью из команды Google Android.

Филью отмечает, что количество ошибок, связанных с безопасностью памяти, в ядре Linux довольно низкое. Однако, когда они возникают, команда безопасности Android обычно считает их серьёзными недостатками.

Чтобы показать, какие преимущества Rust может принести разработчикам ядра Linux, Google разработал пример драйвера под названием «семафор».

«Как Rust может помочь разработчику — вот аспект, который мы хотели бы подчеркнуть», — отмечает Филью.— «Например, во время компиляции он позволяет нам исключить или значительно снизить вероятность появления классов ошибок, в то же время оставаясь гибким и имея минимальные накладные расходы».

Разработчик ядра Linux Мигель Охеда на этой неделе выпустил запрос комментариев (RFC) в список рассылки Linux, в котором излагается предложение по второму языку ядра вместе с несколькими патчами для ядра Linux, написанными на Rust.

Охеда также создал группу Rust для Linux , к которой также присоединилась команда Google Android.

«Мы знаем, что внедрение нового основного языка в ядро сопряжено с огромными затратами и рисками. Мы рискуем разделить усилия и увеличиваем объем знаний, необходимых для работы над некоторыми частями ядра», — пишет Охеда.— «Самое главное, что любой новый язык, представленный, означает, что любой модуль, написанный на этом языке, будет труднее заменить позже, если поддержка нового языка будет прекращена. Тем не менее, мы считаем, что даже сегодня преимущества использования Rust перевешивают затраты».

Как отмечает Phoronix, создатель ядра Linux Линус Торвальдс уже высказал некоторые опасения по поводу Rust, хотя он также сказал, что «в целом я его не ненавижу». Однако Торвальдс добавил, что «паника сбоев во время выполнения является фундаментальной проблемой».

Филхо объяснил, что, поскольку Rust является новым для ядра, есть возможность улучшить процессы и документацию.

«Например, у нас есть определённые требования, проверенные машиной, в отношении использования небезопасного кода: для каждой небезопасной функции разработчик должен задокументировать требования, которые должны выполняться вызывающими абонентами, чтобы гарантировать её безопасное использование; кроме того, для каждого вызова "небезопасные функции (или использование небезопасных конструкций, таких как разыменование необработанного указателя), разработчик должен задокументировать обоснование того, почему это безопасно», — пишет Филью.

Rust, который в 2015 году достиг версии 1.0, похоже, набирает обороты у разработчиков. AWS, Huawei, Google, Microsoft и Mozilla поддерживают фонд Rust Foundation, который был запущен в феврале. Первым председателем фонда был избран Шейн Миллер, старший технический менеджер AWS .

Ранее Startpack сообщал, что более 500 000 пользователей Huawei загрузили из официального магазина Android приложения компании, заражённые вредоносной программой Joker, которая подписывается на мобильные сервисы премиум-класса.

Startpack также подготовил список VPN-сервисов (Virtual Private Network). VPN предлагает дополнительный уровень безопасности, шифруя все данные, например, IP-адреса, которые передаются по сети. Это обеспечивает анонимность пользователя в сети и предотвращает утечку конфиденциальных бизнес-данных.

Особая рекомендация: Proton VPN — высокоскоростной швейцарский VPN, который гарантирует конфиденциальность пользовательских данных.

Читайте также: