LINUX.ORG.RU

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

 ,


2

5

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

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

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

Rust скорее позволяет твоему модулю не отдавать невалидные указатели другим частям ядра. Если все куски ядра отдают только валидные указатели - то невалидных там нет совсем. Осталось только все ведро переписать на растишке.

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

Rust скорее позволяет твоему модулю не отдавать невалидные указатели другим частям ядра.

Ты такой забавный.

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

Rust скорее позволяет твоему модулю не отдавать невалидные указатели другим частям ядра.

ну это же бред - раст в ядре памятью не управляет

Осталось только все ведро переписать на растишке.

попутного ветра :)

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

Да, ты тоже смешной.

Давай дружить?

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

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

Нет, непонятно. Не напишу и ладно. Что смогу - напишу. Я же не предлагаю запрещать С.

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

Так это всё про компилируемые лиспы. Для clisp ещё будет 3. интерпретация байткода замедляет выполнение.

На самом деле п.1 устраним при помощи деклараций типов, а п.2 - использованием диалекта лиспа без сборки мусора.

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