LINUX.ORG.RU

Доклад о разработке модулей ядра на Rust.

 ,


2

5

Появилось интересное видео, в котором авторы фрэймворка для написания модулей для ядра linux делятся своим опытом.

Вольный перевод описания к видео: Т.к. 65% последних уязвимостей стали результатом небезопасного обращения с памятью (переполнение буфера, использование указателя после освобождения и прочее), а не логических ошибок, то как разработчики ядра, так пользователи задались вопросом: возможно ли применение более безопасного языка, чем С для разработки ядра?. В своём выступлении докладчики рассказывают о своей работе над созданием фрэймворка для написания модулей ядра на Rust и доступа к API ядра из безопасного подмножества Rust. В частности, докладчики расскажут о трудностях сборки бинарно-совместимых модулей ядра на Rust, о техниках работы с существующим кодом на С и о том как проектировать безопасные биндинги к API ядра. Также докладчики расскажут о преимуществах и сложностях интеграции Rust в разработку ядра и возможные для сообщества разработчиков ядра.

Жуткую статистику уязвимостей из-за небезопасного обращения с памятью приводят авторы в начале своего выступления:

  • Chrome - 49% в 2019
  • Firefox - 72% в 2019
  • Вообще - 81% с 2014 (по данным Google Project Zero)
  • macOS - 88% в серии 10.14
  • Microsoft - 70% с 2006
andalevor ★★
() автор топика

Т.к. 65% последних уязвимостей стали результатом небезопасного обращения с памятью (переполнение буфера, использование указателя после освобождения и прочее), а не логических ошибок, то как разработчики ядра, так пользователи задались вопросом: возможно ли применение более безопасного языка, чем С для разработки ядра?

А как же С, мать его, плюс-плюс?

Crocodoom ★★★★★
()

Смотри ка, дело то живет!

Shulman
()

Т.к. 65% последних уязвимостей стали результатом небезопасного обращения с памятью (переполнение буфера, использование указателя после освобождения и прочее),

А в чем проблема не совершать эти ошибки? Даже обезьяна после сотого раза поймет, что она делает неправильно.

Deleted
()
Ответ на: комментарий от Deleted

А в чем проблема не совершать эти ошибки? Даже обезьяна после сотого раза поймет, что она делает неправильно.

Хороший, годный наброс. Сейчас тебя адепты научат Родину любить.

anonymous
()
Ответ на: комментарий от anonymous

Хороший, годный наброс.

Это не наброс. Разрабы сами признаются, что небрежно обращаются с памятью, так вся проблема в них самих.

А Родину я люблю, правительство не люблю.

Deleted
()
Ответ на: комментарий от Deleted

А в чем проблема не совершать эти ошибки? Даже обезьяна после сотого раза поймет, что она делает неправильно.

Вроде как практика показывает, что даже эксперты по C++ допускают ошибки данного рода.

seiken ★★★★★
()
Ответ на: комментарий от Zhbert

В начале своего доклада авторы делают краткий обзор языков и коротко аргументируют свой выбор. Лиспа, правда, в списке нет, но есть хаскель. Такой вопрос авторам задают в части вопрос-ответ, они говорят, что производительность будет на уровне, т.к. код на Rust делает то же, что и код на С, без дополнительных накладных расходов, например на GC.

andalevor ★★
() автор топика
Ответ на: комментарий от Zhbert

А чего не на лиспе?

1. Динамическая типизация порождает накладные расходы на память: у тебя уже не просто «int64» с предсказуемым футпринтом, а полноценный «объект» со всеми вытекающими

2. Сборщик мусора порождает накладные расходы на время выполнения: периодическая очистка памяти от ненужных объектов, или же периодическая дефрагментация памяти.

Crocodoom ★★★★★
()

Внесите царя!

anonymous
()
Ответ на: комментарий от darkenshvein

Там вообще С++ (не чистый С, с которым пытаются бороться в ядре). Но когда всякие непонятные тонкости останавливали аналитиков!

anonymous
()

вангую, что они наткнутся на ту же самую проблему, что автор Way Cooler: указатели, которые могут внезапно стать NULL. Для доступа к ним придется либо применять unsafe, либо реализовать обвязку со всей логикой. Последнее оказалось слишком трудоемко даже для небольшой библиотеки wlroots, что уж говорить про ядро.

Т.ч. ничего у них не получится, и все продолжат писать на сях. Ну точнее, может быть получится для каких-нибудь обособленных корпоративных модулей, в которых разработчики будут плевать на существующие подсистемы ядра и велосипедить все свое (см. NVidia) - но кому нужна такая экосистема?

anonymous
()

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

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

Интересно, как к этому относится Линус?

Нейтрально

Deleted
()
Ответ на: комментарий от andalevor
  1. Вы всё врёти. (с)
  2. Нормальные программисты не совершают таких ошибок. (с)
  3. Ко-ко-ко. (с)

PS: Тему не читал.

RazrFalcon ★★★★★
()
Ответ на: комментарий от Deleted

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

Как видим из статистики, для большинства людей это слишком сложная задача, а значит сишка не подходит для разработки.

ЧТД

RazrFalcon ★★★★★
()
Ответ на: комментарий от andalevor

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

Учитывая, где применяют Ада, было бы логичнее сравнивать если не в первую, то во вторую-третью очередь именно с этим языком.

gag ★★★★★
()
Ответ на: комментарий от RazrFalcon

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

Компилятор раст никогда не сбоит при оптимизациях многочисленных передач владения?

gag ★★★★★
()
Ответ на: комментарий от RazrFalcon

Как видим из статистики, для большинства людей это слишком сложная задача, а значит сишка не подходит для разработки.

А где статистика, сколько разработчиков из общего кол-ва как часто допускают указанные ошибки?

gag ★★★★★
()
Ответ на: комментарий от gag

Ага, то есть засланный казачок там резвится, а все остальные молодцы? Ну-ну.

RazrFalcon ★★★★★
()
Ответ на: комментарий от gag

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

red75prim ★★★
()
Ответ на: комментарий от RazrFalcon

Я смотрю конец C все так же у тебя на устах.💄

anonymous
()
Ответ на: комментарий от RazrFalcon

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

Как видим из статистики, для большинства людей это слишком сложная задача, а значит сишка не подходит для разработки.

ЧТД

Друг, читай внимательнее. Откуда ты взял про большинство людей? В статистике говорится, что большинство уязвимостей происходят из-за некорректной работы с памятью. Видишь разницу?

P.S. Я считаю, что расту самое место в ядре.

Crocodoom ★★★★★
()
Ответ на: комментарий от RazrFalcon

Не хотелось объяснять базовую арифметику, но мне не жалко.

Какая-то доля разработчиков ядра «не в состоянии удержать в голове ментальную модель памяти». Может быть, это 0.1%, может 1%, может 10%, может 100%. Я не знаю. И ты не знаешь. И статистика, к которой ты аппелируешь, никак не помогает этот процент оценить.

А о чём же она говорит? Что из всех багов в ядре, ошибки памяти являются наиболее трудноуловимыми. Поэтому на них приходится 65% обнаруженных уязвимостей. А на другие ошибки 35%. Вот и всё. Не важно, какая доля разрабов эти ошибки упускает в своём коде — важно, что она, в целом, упускает их чаще, чем другие.

Crocodoom ★★★★★
()
Ответ на: комментарий от Crocodoom

А другие проекты в учёт не берём? Баги не только в ядре, как бы.

наиболее трудноуловимыми

Падаждите. Вы таки хотите сказать, что санитайзеры бесполезны? Ужас-ужас.

RazrFalcon ★★★★★
()
Ответ на: комментарий от Legioner

Линус слишком стар для изучения нового языка и будет упорствовать

Дело даже не в том, что старый. В C он - царь, за эти годы каждую бородавку в лицо запомнил. С новым ЯП придётся опуститься до простого смертного, на время позволить всяким соплям стать выше него. Оно ему надо?

anonymous
()
Ответ на: комментарий от hotpil

злобные комментарии Линуса про раст?

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

Похоже, опять извиняться перед поехавшими minority он не хочет, по поводу раста благоразумно молчит.

Это не крестовики, не Нвидия и не Тео де Раадт, растоманы (которые, кстати, судя по треду, даже не отличают С от С++) будут полыхать пуканами и травить его изо всех сил, до изнеможения

anonymous
()
Ответ на: комментарий от Legioner

Зато багов меньше будет.

потому что эти драйверы (все два хелловорда) не будут работать на большей части архитектур которые поддерживает Linux и не поддерживает Rust

Это же круто.

anonymous
()
Ответ на: комментарий от Legioner

Хочешь сказать, что все драйверы прям такие кроссплатформенные?

нет, даже не знаю зачем ты это написал. Для неподдерживаемой растом архитектуры ты никакой драйвер не напишешь - так понятней ?

anonymous
()
Ответ на: комментарий от Crocodoom

более безопасного языка, чем С

Плюсы тут каким боком?

trex6 ★★★★★
()
Ответ на: комментарий от Zhbert

И как оно скажется на скорости работы?

Если нормально писать, то никак не скажется.

trex6 ★★★★★
()
Ответ на: комментарий от anonymous

Для неподдерживаемой растом архитектуры

Вопрос решаемый. Запилить rust поверх б-жественной GCC-шечки и все будет работать. Вопрос времени и желания.

trex6 ★★★★★
()
Ответ на: комментарий от Deleted

А в чем проблема не совершать эти ошибки? Даже обезьяна после сотого раза поймет, что она делает неправильно.

... и возьмёт нормальный язык ;)

PexuOne
()
Ответ на: комментарий от Legioner

Интересно, как к этому относится Линус? Можно ли ждать появления официальных биндингов и модулей на Rust в ядре? Боюсь, Линус слишком стар для изучения нового языка и будет упорствовать

его в оправдании педофилии ещё не обвиняли?

PexuOne
()
Ответ на: комментарий от Legioner

В целом да. Практически всё что в ядре есть не завязано на особенности конкретной архитектуры и может быть собрано для всего что поддерживается. Исключения есть, но обычно там специфичное что-то.

Dark_SavanT ★★★★★
()
Ответ на: комментарий от trex6

Запилить rust поверх б-жественной GCC-шечки и все будет работать

всё работает без rust, но кому-то надо 5 человек чтобы лампочку вкрутить

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.