Комментарии 19
Ядро Linux:
- Написано на С
- Взаимодействует с недоверенным вводом (и внешним миром)
- Содержит песочницу… под собой, а не снаружи.
DOOM?
Да. Согласно этой терминологии так и есть.
… При том, что в том же Rust'е вызов naked function является unsafe на 100%, а вещи, которые в naked function творят, к безопасности отношения не имеют, я не уверен, что замена в этом месте C/C++ на Rust что-то фундаментально поменяет. А как писать ядро без naked functions — я очень хочу посмотреть.
В отличие от Си, в Расте аудит UB требуется только в unsafe коде. Которого очень мало — в т.ч. учитывая текущую практику разработки системных компонентов или операционных систем.
Например, в сетевом стеке Fuchsia:
➜ connectivity git:(master) rg -c "unsafe" | cut -d ":" -f2 | paste -s -d+ - | bc
316
➜ connectivity git:(master) tokei
===============================================================================
Language Files Lines Code Comments Blanks
===============================================================================
C 129 119529 86791 13677 19061
C Header 749 128257 69341 38631 20285
C++ 860 275408 206504 24284 44620
C++ Header 1 289 220 23 46
Go 69 28229 22411 2436 3382
JSON 85 2564 2556 0 8
Makefile 1 23 4 17 2
Shell 5 188 118 38 32
SVG 6 131 131 0 0
TOML 2 100 77 11 12
-------------------------------------------------------------------------------
Markdown 101 9067 0 7179 1888
|- BASH 1 6 6 0 0
|- JSON 3 98 98 0 0
|- Rust 5 211 174 9 28
(Total) 9382 278 7188 1916
-------------------------------------------------------------------------------
Rust 1029 362682 299593 22419 40670
|- Markdown 757 20900 48 18476 2376
(Total) 383582 299641 40895 43046
===============================================================================
Total 3037 926467 687746 108715 130006
===============================================================================
➜ connectivity git:(master)
К сожалению, именно число строк посчитать уже сложно. Но порядок и так видно, если на 300 тысяч строк кода 300 мест, где могут быть проблемы.
А как писать ядро без naked functions — я очень хочу посмотреть.
Легко. Вызываем обычные функции из асма. Я так делал, загляните в мои статеечки.
С другой стороны не очень понятна мысль про unsafe
. Разница как раз в этом месте и будет фундаментальной. Блок unsafe
предполагает, что внутри вы вручную налагаете ограничения для соответствия всем правилам safe-абстракций. Ну и традиционное: unsafe
не отключает никакие проверки, которые Rust делает.
Э… Простите, а как вы будете уговаривать процессор вызывать "обычные функции" в обработчике прерываний? Там задача — ничего не поломать у прерванного процесса, и без naked functions — никуда. см rust-rfcs/1201.
Легко и непринуждённо поговорю с процессором на его ассемблере. Читайте про такую штуку, как ABI. Я при помощи extern
говорю функции из Rust следовать стабильному ABI (а не своему внутреннему) и в ассемблере просто выполняю требования ABI. При этом extern
сам по себе не требует unsafe
. Вообще говоря можно полностью написать ядро без единого unsafe
. Всё останется корректным. Просто это не столь удобно.
А неудобно это именно по той причине, что я теряю мощную фундаментальную абстракцию под названием unsafe
.
Вообще да, если посмотреть на статистику нахождения там багов и уязвимостей, в т.ч. вызванных проблемами небезопасной работы с памятью.
Например, вот относительно недавнее исследование. Оно не блещет полнотой, но достаточно репрезентативно.
Почему антисанкционную?
А, ну тогда не. Конечно можно на расте через jni приложения крафтить, но это все еще sandbox внутри jvm, так что едва ли это замена. Да и Kotlin сейчас уже пишется довольно большим международным коммунити.
Ну ещё можно на нём нативный код внутри приложений готовить. Это кстати вполне возможно уже некоторое время, кое-кто даже так делает, нужно только правильно соблюсти соглашения по сигнатурам с JNI чтобы скомпилированный код мог вызываться из JVM. Однако я считаю, что в этом нет особой необходимости, т.к. код обычных приложений исполняется внутри процесса который не может сильно навредить системе, плюс нейтив в андроиде чаще всего используется для удобного переиспользования кодовой базы на C/C++ внутри приложения.
Вот внутри системы это действительно очень важно, особенно в тех частях которые можно подёргать из обычных приложений, таких как binder. В них чаще всего и находят опасные уязвимости которые можно раскрутить в эксплоиты дающие локальное повышение привилегий. Теоретически, rust должен сделать этот код намного безопаснее
При чём тут "по-сути"? Вы знаете где они зарегистрированы? В какой стране у них лицензии и права на ПО зарегистрированы? То, что они родом из РФ… Ну люксофт — тоже родом из РФ, но российской компанией не считается вот совсем. А Епам, если мне память не изменяет — из Беларуси. Но его тоже не считают белорусской компанией.
Rust включили в список основных языков для разработки платформы Android