LINUX.ORG.RU
ФорумTalks

Отказаться от аппаратной защиты используя байткод

 , , ,


0

2

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

Идея такая: пишем модуль ядра (.ko), который будет тащить с диска пользовательский код и пускать на нем треды в контексте ядра в нулевом кольце. Это небезопасно. Потому тащим в ядро еще и Rust компилятор, загружаем только растокод «mid-level IR», например. Позже сделать какой-то байткод, по которому можно будет валидировать отсутствие unsafe, и интерпретатор с jit компиляцией.

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

Профит: небольшое увеличение производительности и пылающие пуканы растохейтеров.

Я вообще не разбираюсь в низкоуровневом программировании но думаю что взлетит. Взлетит?

Запускаем только то, что не содержит unsafe

unsafe нужен не просто для красоты. Далеко не всё может быть реализовано на safe rust

Идея такая: пишем модуль ядра (.ko)

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

Профит: небольшое увеличение производительности

Сперва добейся.

Я вообще не разбираюсь в низкоуровневом программировании но думаю что взлетит. Взлетит?

Без софта не взлетит. А софт под твой код надо переписывать.

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

А проверка кода *до* запуска ничего не стоит в рантайме.

Прогрев jit(или твоей идеи) полностью замедляет кучу мелких утилит. Подумай с какой скоростью будет выполняться какой-нибудь bash скрипт

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

Реализованны на уровне процессора и практически ничего не стоят.

Настолько, что в спекулятивном выполнении не используются

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

Але, гугл давно уже сделал android. Это то же самое, только вместо rust там java и dalvik

Гугл додумался пускать java модулем ядра O_O?

NextGenenration ★★
()
Последнее исправление: NextGenenration (всего исправлений: 1)
Ответ на: комментарий от bbk123

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

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

Далеко не всё может быть реализовано на safe rust

Это доказывать надо. linked list можно на смартпоинтерах, а они могут быть в стандартной библиотеке (которая unsafe и не проверяется). А больше примеров я не знаю.

И если этот модуль упадёт, то повалит с собой много чего

Это как ядро, ядро тоже может упасть. Вообще компьютер со стола может упасть :)

А софт под твой код надо переписывать

Вот именно потому и не взлетит, а жаль.

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

linked list можно на смартпоинтерах

И зачем тебе тогда нужен rust? Почему тогда не взять язык в котором умные указатели идут прямиком из коробки, типа go или crystal?

Это как ядро, ядро тоже может упасть. Вообще компьютер со стола может упасть :)

И сколько раз за день у тебя падает ядро?

Вот именно потому и не взлетит, а жаль.

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

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

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

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

Кроме того, с какой скоростью будет выполняться проверка какого-нибудь большого софта типа фокса?

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

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

Не понял. А из std это не из коробки?

И сколько раз за день у тебя падает ядро?

Воображаемый модуль ядра падает еще меньше.

vlad9486
() автор топика
Ответ на: комментарий от NextGenenration

перезагрузившись к примеру в винду

Так и ядро можно пропатчить.

с какой скоростью будет выполняться проверка какого-нибудь большого софта типа фокса

Не проверка, а проверка и трансляция в машинный код. Где-то со скоростью компиляции c++ кода. Живут же как-то на Gentoo.

vlad9486
() автор топика
Ответ на: комментарий от KivApple

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

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

Не понял. А из std это не из коробки?

Для этого нужна синтаксическая соль. Завязывать весь софт на один язык не лучшая иедя

Воображаемый модуль ядра падает еще меньше.

«программы на haskell не имеют побочных эффектов, поскольку их никто не запускает». Как ты собираешься бороться с утечками памяти в ядре?

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

Так и ядро можно пропатчить.

Вообще-то мне было интересно как ты собираешься бороться с этой проблемой.

Где-то со скоростью компиляции c++ код

То есть всё плохо

Живут же как-то на Gentoo

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

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

А они могут гарантировать memory safety?

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

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

Так и ядро можно пропатчить.

uefi вполне позволяет подписывать ядра, и в случае отсутствия подписи ты не сможешь запустить своё ядро.

NextGenenration ★★
()
Последнее исправление: NextGenenration (всего исправлений: 1)
Ответ на: комментарий от NextGenenration

Как ты собираешься бороться с утечками памяти в ядре?

Также как это сделано для «обычных» процессов. Ядро освобождает их память когда они завершаются. Тоже самое может делать модуль ядра для «ядерных» процессов.

vlad9486
() автор топика
Ответ на: комментарий от NextGenenration

Это достигается не какой-то особой магией, а вполне конкретными действиями.

Значит это нельзя проверять автоматически. А отсутствие unsafe можно.

vlad9486
() автор топика
Ответ на: комментарий от bbk123

Строго говоря, относится только safe rust. Докажи что не относится.

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

Значит это нельзя проверять автоматически

Полностью управляемый код и не нужно проверять. Достаточно на уровне байткода запретить арифметику указателей и поручить управление памятью GC, и всё.

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

И этим кто-то пользуется IRL?

Конкретных людей не назову, но могу сказать что на некоторые пк линукс не поставить именно по этой причине

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

Также как это сделано для «обычных» процессов. Ядро освобождает их память когда они завершаются. Тоже самое может делать модуль ядра для «ядерных» процессов.

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

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

Я писал игрушечные модули ядра и ядра. Не вижу с этим проблем. Думаю что с процессом связаны binary tree всех указателей на кучу, binary tree хендлов открытых файлов и всего прочего. Но пруфов нету и не гуглится. Сам буду рад ссылке на конкретный код, или доку.

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

Если у тебя уже есть опыт создания модулей, то создать модуль порождающий пару процессов по требованию, в которых утекает какой-то объём памяти ты уже можешь. И быстрее будет это проверить самому.

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

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

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