LINUX.ORG.RU
ФорумTalks

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

 , , ,


0

2

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

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

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

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

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

Это просто твой организм хочет сделать что-нибудь встроенное, только не хочет учить ассемблер.

abraziv_whiskey ★★★★★
()

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

Столько гемора ради вот этого.

ox55ff ★★★★★
()
Ответ на: комментарий от post-factum

Типа того, только не делать целую ОС, а юзать линукс. Кроме того, там код управляемый, сборщик мусора и другой сложный рантайм. А в раста рантайм прост, да и можна вообще без интерпретации. Компилировать во время установки пакета.

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

Лол. Даже если говорить только про синтаксис, fasm может с этим поспорить.

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

QubeOS

В википедии

implements a Security by Isolation approach.[11] The assumption is that there can be no perfect, bug-free desktop environment.

У меня же наоборот. Отказ от изоляции, и предположение что *can* be perfect, bug-free desktop environment

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

Точнее, баги могут быть, но не те от которых защищает операционная система.

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

А потом компилировать и выполнять? Можно сразу в машинный, но так проще.

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

Так я это и предлагаю. Только вот переводить в ассемблер и запускать только тот байткод, который прошел проверку на memory safety. Инструмент, который делает такую проверку и есть компилятор раста.

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

Операционная система (а точнее, процессор) тоже дают защиту от memory corruption, но эта защита имеет рантайм цену. А проверка кода *до* запуска ничего не стоит в рантайме.

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

Только вот Rust чисто без unsafe тоже не быстрый. Надо будет написать продуманную std, даюбы все ситуации описать в safe-коде.

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

Только вот Rust чисто без unsafe тоже не быстрый

И в каких же случаях он медленный - когда оптимизация не включена?

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

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

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

И пример XXX на си, где 5 все компилируется в 5 байт а не пятьдесят структур умных указателей. Ну зато есть плюс, на расте трудно писать «неправильно».

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

Первая пятерка в комментарии материализовалась из воздуха.

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

Ну вроде tailgunner был в треде, поэтому я и напомнил. Суть в том что я спросил как написать свой лексер на расте а потом мне 5 страниц объясняли что я дурак и это не лексер, а почему не говорили и там предложили мне пример с unsafe и навароченный пример. Rust vs C

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

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

Зачем? Впрочем, неважно. Пример показывает только то, что на безопасном Rust невозможно писать так, как на Си.

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

Safe код на rust теоретически не может сделать ничего от чего защищает OS.

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

bbk123 ★★★★★
()

Inferno OS что-то подобное делала, лет так 20 назад.

qrck ★★
()

не спасет от спектрума

pftBest ★★★★
()

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

Как бы не была хороша мысль не использовать mmu но у нее много плюсов. Смотрел презентацию исследования добавления MMU для GPU, там на наборе разных алгоритмов в худшем случае просадка была только 12%, при средней просадки в 2%. И это в 2014 году, сейчас наверно еще лучше могут сделать.
Я уже жду не дождусь когда будет общая память для GPU и CPU, в том смысле что не надо будет гонять туда сюда данные и видеокарты не будут ограниченны малым размером памяти(а то у меня сейчас на видеокарте всего 2GB памяти, тогда как для CPU 32GB).

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

На такой код не будет ссылки и достать ее неоткуда.

vlad9486
() автор топика

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

Толстота-то какая, жырнота!

IMAM
()

Сложно будет писать программы без unsafe. Лучше смотри в сторону google native client, они там как-то верифицируют машинный код.

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

MMU ничего не стоит? https://www.usenix.org/legacy/events/osdi10/tech/full_papers/Soares.pdf Теперь уже ядро лежит в отдельном адресном пространстве, потому все прелести переключения контекста будут при каждом сисколе. Из контекста ядра же сисколы не нужны и все процесы, которые запущены по предлагаемой схеме будут в том же адресном пространстве что и ядро.

Как скастовать царя? Пусть придет и расскажет где я неправ, он что-то там знает по теме.

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

Столько гемора ради вот этого.

Ты лучше спроси почему поциент думает что будет увеличение производительности

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

Я уже жду не дождусь когда будет общая память для GPU и CPU, в том смысле что не надо будет гонять туда сюда данные

На PlayStation4 и XboxOneX – уже :)

Stil ★★★★★
()

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

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

Типа того, только не делать целую ОС, а юзать линукс
Кроме того, там код управляемый, сборщик мусора и другой сложный рантайм
Компилировать во время установки пакета

Але, гугл давно уже сделал android. Это то же самое, только вместо rust там java и dalvik. Как видишь, хоть и взлетело, но работает как Г. И ни каким «Профит: небольшое увеличение производительности и пылающие пуканы растохейтеров» там не пахнет.

Aswed ★★★★★
()

Потому тащим в ядро еще и Rust компилятор,

который может часами компилировать

загружаем только растокод «mid-level IR», например. Позже сделать какой-то байткод

А потом делаем direct bytecode execution, ой - https://en.wikipedia.org/wiki/Jazelle

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

Я уже жду не дождусь когда будет общая память для GPU и CPU, в том смысле что не надо будет гонять туда сюда данные и видеокарты не будут ограниченны малым размером памяти(а то у меня сейчас на видеокарте всего 2GB памяти, тогда как для CPU 32GB).

Это давно есть на APU от AMD. Называется HSA. А уж интегрированные видеокарты видеопамять от оперативной давно себе откусывают.

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

А уж интегрированные видеокарты видеопамять от оперативной давно себе откусывают.

Но ведь пока все равно надо гонять из оперативной памяти в «откусанную» оперативную память. А хочется именно общей памяти, тут правда стоит вопрос в пропускной способности ОЗУ. Если я правильно понимаю одна планка памяти DDR4 сейчас может обеспечить максимум 25GB/s, 8 канальная уже 200GB/s а это все-го лишь пропускная способность как у Radeon RX 570/GeForce GTX 1060. Даже будущая лучшая DDR5 которая удвоит пропускную способность до 400GB/s для 8 каналов будет уступать по пропускной способности текущим топовым GPU. А значит годных PC HSA с не заоблачными ценами в пользовательском сегменте в ближайшее время не предвидится. Разве что как-то умудрятся в качестве альтернативы DDR5 выпускать системы использующие HBM память. Я готов купить такое даже если эта память будет распаяна на материнке.

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

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

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

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

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