Comments 45
Хотя один энтузиаст уже пишет свою операционную систему на Rust.
На самом деле много кто пишет ОС на Rust, но самая известная с довольно большой командой это:
Из известных ещё Fuchsia частично на Rust написана.
Там только SDK для Rust. Тоже неплохо, но вроде никаких компонентов на Rust у них нету.
Я был под впечатлением, что Fuchsia частично на Rust написана, т.к. видел код на нём в исходниках.
Например тынц, тынц, тынц и тынц. Ну и ещё много других мест находил.
В ядре правда ничего на Rust я не нашёл.
Не понятно также какой процент от общего количества исходников написан на Rust. Но можно попробовать посчитать.
Например тынц, тынц, тынц и тынц. Ну и ещё много других мест находил.
В ядре правда ничего на Rust я не нашёл.
Не понятно также какой процент от общего количества исходников написан на Rust. Но можно попробовать посчитать.
В данном случае совершенно неважно какой процент написан на Rust. Нужно смотреть за динамикой. Вообще так-то кажется, что как раз для middleware OS Rust вообще подходит идеально: обычно там нет каких-то сильно хитрых алгоритмов (они в других местах системы сидят), но важно не напутать в [относительно] простом коде с правами доступа…
Если Rust там приживётся и количество компонент на нём будет расти — ну это очень хороший признак.
Если Rust там приживётся и количество компонент на нём будет расти — ну это очень хороший признак.
Оценить объем использования Rust в Фуксии можно по этому списку измененных файлов BUILD.gn — «Switch Rust test deps to _test targets», вероятно это те «пакеты/библиотеки» что созданы на базе Rust. Более 100 файлов (BUILD.gn).
Есть отдельная папка garnet/lib/rust/
Есть отдельная папка garnet/lib/rust/
1) Насколько я знаю (поправьте меня, если я ошибаюсь) DPDK и сетевой стэк имеет более легковесный, чем стэк в ядре (который универсальный и все такое), а снижение накладных расходов на syscalls и копирование данных в пользовательское адресное пространство и обратно
2) Т.е. вся их скомпилированная в один большой бинарь система исполняется в Ring 0? Минус накладные расходы на системные вызовы с переключениями контекста, сбросом буферов TLB и прочим. Минус безопасность. Нужно очень доверять запущенному приложению и быть уверенным, что оно не полезет в чужую память, не упадет и так далее. Вообще, вспоминается проект Microsoft Singularity.
Вообще, вспоминается проект Microsoft SingularityТам хотя бы защита на уровне языка была. Тут скорее Windows 9X и её «надёжность» стоит вспомнить…
UFO just landed and posted this here
Тут больше вопрос по использованию с докером
UFO just landed and posted this here
Так эта мини-виртуалка напрямую с железом действует, поверх какой-то ОС/гипервизора?
UFO just landed and posted this here
Идея следующая — связать приложение с необходимыми библиотеками операционной системы и скомпилировать их в один бинарный файл. После этот «бинарник» можно использовать для загрузки системы.Получается, что ваше приложение превращается в часть ядра операционной системы.
Никто не предлагает отдавать любому приложению такой доступ, просто появляется возможность делать специализированные сборки ядра под некое приложение, как например сервер memcached или redis.
Либо я не понял идею, либо это какая-то наркомания.
Но ведь не только к бинарнику, но и к данным, которые обрабатывает этот бинарник и к ресурсам, которые он использует (впрочем данные тоже ресурс). Т.е. фактически хакер получает точно такой же доступ как и на обычном контейнере. Более того тут и пользовательского уровня не будет — избавляемся от одних уязвимостей и становимся более уязвимым к другим.
Увеличение производительности конечно впечатляют, но сравнивать надо не с приложением пользовательского уровня, а с модулем ядра, написанным для выполнения функции этого приложения. Учитывая что и сабж и написание такого модуля примерно одинаково нетривиально и что большая часть приложений «тормозят» ожидая данных, то профит от всей этой махинации для меня теряется.
Как это дело дебажить? Туда ж ни по ssh не зайти, ни логи почитать, ни прочие плюшки вроде syslog'а, нулевого даунтайма при обновлении не получить (без балансировки уровня выше), крона и прочего. В проде это гораздо ценее чем даже 100% к производительности и удаления некоторых уязвимостей (особый вопрос насколько это действительно улучшает безопасность).
Комментарий про раст и вовсе выглядит то ли издевкой, то ли сарказмом.
Для меня это все выглядит мертворожденным и я бы лучше рассмотрел другие способы достижения тех же целей (безопасность, эффективность).
В целом об инициативе авторов оригинальной статьи положительно отозвалось и ИТ-сообщество. Резиденты Hacker News отметили, что архитектура unikernels значительно повысит безопасность программной среды. В случае взлома приложения хакер получит доступ лишь к его бинарнику.
Но ведь не только к бинарнику, но и к данным, которые обрабатывает этот бинарник и к ресурсам, которые он использует (впрочем данные тоже ресурс). Т.е. фактически хакер получает точно такой же доступ как и на обычном контейнере. Более того тут и пользовательского уровня не будет — избавляемся от одних уязвимостей и становимся более уязвимым к другим.
Увеличение производительности конечно впечатляют, но сравнивать надо не с приложением пользовательского уровня, а с модулем ядра, написанным для выполнения функции этого приложения. Учитывая что и сабж и написание такого модуля примерно одинаково нетривиально и что большая часть приложений «тормозят» ожидая данных, то профит от всей этой махинации для меня теряется.
Как это дело дебажить? Туда ж ни по ssh не зайти, ни логи почитать, ни прочие плюшки вроде syslog'а, нулевого даунтайма при обновлении не получить (без балансировки уровня выше), крона и прочего. В проде это гораздо ценее чем даже 100% к производительности и удаления некоторых уязвимостей (особый вопрос насколько это действительно улучшает безопасность).
Комментарий про раст и вовсе выглядит то ли издевкой, то ли сарказмом.
Для меня это все выглядит мертворожденным и я бы лучше рассмотрел другие способы достижения тех же целей (безопасность, эффективность).
Вот меня упоминание в сабже раста тоже несколько смутило. Я люблю раст, но извините, это же практически сказать «переписать линукс на раст».
Как это дело дебажить? Туда ж ни по ssh не зайти, ни логи почитать, ни прочие плюшки вроде syslog'а, нулевого даунтайма при обновлении не получить (без балансировки уровня выше), крона и прочего.
Изучаю k8s сейчас, те же мысли. Так что… Может и взлететь, будет модной молодёжной технологией.
Мне вот тоже интересно — какие же проблемы безопасности мы решаем? Уязвимости в ядре по-прежнему останутся уязвимостями, только теперь к ним добавятся уязвимости приложения (которых гораздо больше, чем уязвимостей в ядре), при этом каждая такая уязвимость, которая раньше осталась бы в user-space, теперь дает полный доступ к машине на уровне даже большем, чем root в user-space.
Вы кажется не улавливаете суть. Фактически, концепция unikernel меняет представление об организации вычислительного процесса. Это новая абстракция, которая уровнем выше чем процесс, и фактически объединяет совокупность процессов + «ядро», которые на самом деле реализуют один высокоуровневый сервис. Та же база данных как пример. Зачастую заводят целый физический сервер исключительно под БД. Но кроме самой БД туда входит ядро ОС, драйвера сетевого и дискового стека, сервисы, какие-то обслуживающие приложухи и утилиты, мониторинг тот же и т. д. плюс целый веер библиотек. Де факто, все они реализуют один мегасервис — БД. Вот идея unikernel это выделись весь этот зоопарк ПО который реализует БД и запаковать его в одно мегаприложение, попутно сняв по сути не особо нужную в таком случае изоляцию и тесно слинков и соптимизировав получившееся чудо. И вот это чудо — это что-то среднее между виртуальной машиной, контейнером и приложением.
С точки зрения надежности. Посмотрите на unikernel с перспективы вот этого вот конечного мегасервиса. Вам как клиенту без разницы почему оно крэшнулось. Из-за kernel panic или из-за ошибки в glibc или из-за бага в самой БД. Во всех случаях конечный результат один — сервис недоступен. Поэтому и нет особо большого смысла в изоляции между компонентами мегаприложения.
С точки зрения безопасности будет та же картина. Если ваше мегаприложение скомпрометировали со стороны «пользователя» — сервис попал к хакеру. Со стороны ядра — тоже самое. Да, есть всяческие нюансы, но в целом ситуация такая. Но! Как бы и с какой стороны не было скомпрометировано ваше мегаприложение, оно изолировано от других мегаприложений. То есть получив БД хакеру будет ну очень сложно пролезть в параллельно работающий на той же физической машине web-сервер. Даже если он смог залезть в «ядро» в БД.
Зато с точки зрения эффективности:
1) Низкий уровень абстракций ресурсов даваемых хостом unikernel-у позволяет всячески извращаться со стороны приложения (кастомные файловые системы и сетевые протоколы вам в руки).
2) Отсутствие изоляции может очень сильно снизить накладные расходы (в разы).
3) Тесная линковка и кросмодульная оптимизация может дать дополнительный прирост производительности.
Так что идея хоть и совершенно не новая (http://cnp.neclab.eu/projects/lightvm/lightvm.pdf) и корнями тянется вот аж сюда в 1995 год (https://pdos.csail.mit.edu/6.828/2008/readings/engler95exokernel.pdf), но вполне себе имеющая смысл. Особенно для всяких серверов и сложных апликух.
Однако! Говорить об unikernels как о замене того же монолита (Linux) имеет мало смысла. Потому что ОС смотрит как весь компьютер и думает как организовать вычисления на нем годным образом (мультиплексирование ресурсов, защита между приложениями и т.д.), а unikernel смотрит на отдельное, пусть и большое и сложное, приложение/сервис, и думает как бы это так получше его организовать.
С точки зрения надежности. Посмотрите на unikernel с перспективы вот этого вот конечного мегасервиса. Вам как клиенту без разницы почему оно крэшнулось. Из-за kernel panic или из-за ошибки в glibc или из-за бага в самой БД. Во всех случаях конечный результат один — сервис недоступен. Поэтому и нет особо большого смысла в изоляции между компонентами мегаприложения.
С точки зрения безопасности будет та же картина. Если ваше мегаприложение скомпрометировали со стороны «пользователя» — сервис попал к хакеру. Со стороны ядра — тоже самое. Да, есть всяческие нюансы, но в целом ситуация такая. Но! Как бы и с какой стороны не было скомпрометировано ваше мегаприложение, оно изолировано от других мегаприложений. То есть получив БД хакеру будет ну очень сложно пролезть в параллельно работающий на той же физической машине web-сервер. Даже если он смог залезть в «ядро» в БД.
Зато с точки зрения эффективности:
1) Низкий уровень абстракций ресурсов даваемых хостом unikernel-у позволяет всячески извращаться со стороны приложения (кастомные файловые системы и сетевые протоколы вам в руки).
2) Отсутствие изоляции может очень сильно снизить накладные расходы (в разы).
3) Тесная линковка и кросмодульная оптимизация может дать дополнительный прирост производительности.
Так что идея хоть и совершенно не новая (http://cnp.neclab.eu/projects/lightvm/lightvm.pdf) и корнями тянется вот аж сюда в 1995 год (https://pdos.csail.mit.edu/6.828/2008/readings/engler95exokernel.pdf), но вполне себе имеющая смысл. Особенно для всяких серверов и сложных апликух.
Однако! Говорить об unikernels как о замене того же монолита (Linux) имеет мало смысла. Потому что ОС смотрит как весь компьютер и думает как организовать вычисления на нем годным образом (мультиплексирование ресурсов, защита между приложениями и т.д.), а unikernel смотрит на отдельное, пусть и большое и сложное, приложение/сервис, и думает как бы это так получше его организовать.
То есть unikernels это, прежде всего, замена "одно универсальное ядро ОС на один специфический процесс" на "одно специфическое ядро ОС на один специфический процесс"? Замена универсальных ОС на голом железе или полной виртуализации путём выпиливания всего ненужного для конкретного приложения и, перевода ядра с приложением на один уровень защиты?
В принципе, уровень защиты почти теряет смысл, если кроме данных приложения других данных в системе у нас просто нет.
В принципе, уровень защиты почти теряет смысл
Но защита программиста самого от себя ведь все еще актуальна.
Теперь ошибка в сервисе который сидит рядом с главным и перепаковывает логи, чтобы послать в хранилище логов может уронить всю систему, или вызвать повреждение любых данных. Любая ошибка в программе может вызвать "kernel panic" или просто все наглухо повесить, если например "расстрелять" память потока ядра обслуживающего IRQ.
Ну это смотря на чем и как писать. Хотя, почему бы и нет? Какой смысл держать живым ядро, если приложение уже недоступно?
Ну это смотря на чем и как писать.
Ну большинство VM "безопасных" языков программирования написаны на C/C++.
Хотя, почему бы и нет?
Эээ… Допустим вы крутите БД, она написана с учетом инварианта что ОС позволяет при падении БД быть уверенным, что либо данные совсем не записались, либо записались целиком. А теперь при возможности уронить вместе с БД ядро, у вас может произойти все что угодно при перезапуске БД,
например потеря вообще всех данных из-за того что расстреляли память vfs и всего что ниже и она при перезапуске так синхронизировала кэш ФС,
что даже fsck не может найти "концов".
Вы совершенно неверно поняли мысль, что «уровень защиты почти теряет смысл»
А ещё в эмбедовке можно развернуться, где полноценная ОС — жирновато, а «всё сам» — грустновато
Действительно, по описанию больше похоже на какую-то embedded RTOS статически скомпонованую с приложением. Только вот все вспомогательные демоны, для логов или для отладки нужно получается также встраивать непосредственно в приложение, ну или расширять возможности ОС.
Опоздали с идеей. Уже сделано :-) www.tockos.org/assets/papers/tock-sosp2017.pdf
Думаю, что люди, которые сталкивались с 10Гбит Ethernet, 40Гбит Ethernet и пр. смотрят на эти вещи совсем по-другому. Когда приходится использовать механизмы zero-copy (PACKET_MMAP), то мечтаешь именно о чём-то типа этой Unikernel.
Linux ведь много где используется, в т.ч. для скоростного ввода-вывода со специального оборудования, никакого выхода в Сеть там нет, и на уязвимости, по большому счёту, наплевать, а самое главное — throughput и latency любой ценой.
Linux ведь много где используется, в т.ч. для скоростного ввода-вывода со специального оборудования, никакого выхода в Сеть там нет, и на уязвимости, по большому счёту, наплевать, а самое главное — throughput и latency любой ценой.
UFO just landed and posted this here
Попахивает экзоядром, разве нет?
UFO just landed and posted this here
В статье был упомянут MirageOS, но почему-то не упоминается проект IncludeOS который является более известным и мейнстримовым — с++ а не ocaml (советую посмотреть на ютюбе несколько докладов про includeos где также освещается общая тема unikernels, например в вопросе безопасности — https://youtu.be/t4etEwG2_LY?t=1810)
Читаем внимательно:
В Windows — драйверы лежат в отдельных файлах. Это не мешает системе быть монолитной.
Вообще-то, смысл разделения ядра и приложений — в защите ядра от приложений и в защите приложений друг-от-друга. Если Вы предлагаете это отменить — то проще всего вернуться к DOS. Ну да, нужен новый DOS — 64-битный, с драйверами. Но это будет именно DOS, в т.ч. и с отсутствием защиты файлов от несанкционированного доступа.
В частности, высокопроизводительные приложения вынуждены использовать фреймворки вроде DPDK и SPDK, чтобы получить беспрепятственный доступ к устройствам ввода/вывода в обход ядра.и
Идея следующая — связать приложение с необходимыми библиотеками операционной системы и скомпилировать их в один бинарный файл. После этот «бинарник» можно использовать для загрузки системы. Такой подход дает возможность специализировать функциональность ОС под нужды конкретного приложения.Ну и каким же образом «компиляция всей системы в один файл» позволит «получить беспрепятственный доступ к устройствам ввода/вывода в обход ядра хост-системы»? А если такого доступа нет — то в чём вообще смысл?
После этот «бинарник» можно использовать для загрузки системы.Образ вирт.машины — это бинарник. Ну и какая разница — лежит ли это дело в одном файле или в разных?
В Windows — драйверы лежат в отдельных файлах. Это не мешает системе быть монолитной.
Также unikernels обладают более высокой производительностью, по сравнению с монолитной архитектурой ядра. Причина — упрощение IO-путей, так как все данные и файлы размещаются в едином адресном пространстве.Судя по описанию — unikernels правильнее всего было бы назвать «супермонолитной системой», ибо там не только ядро монолитно, но и в ядро впихнуто одно приложение… или несколько…
Вообще-то, смысл разделения ядра и приложений — в защите ядра от приложений и в защите приложений друг-от-друга. Если Вы предлагаете это отменить — то проще всего вернуться к DOS. Ну да, нужен новый DOS — 64-битный, с драйверами. Но это будет именно DOS, в т.ч. и с отсутствием защиты файлов от несанкционированного доступа.
Авторы создали небольшую UKL-библиотеку, в которой разместили специальные «заглушки», которые маскируют неиспользуемые системные вызовы.Я ещё в 199*-е годы перекомпилировал ядро FreeBSD, удаляя из него ненужные мне компоненты. И никакой UKL-библиотеки мне не требовалось!
В случае взлома приложения хакер получит доступ лишь к его бинарнику.Вообще-то, в случае взлома приложения хакер получит доступ ко всей вирт.машине, причём сразу в режиме ядра. В частности, он сможет сразу отключить систему мониторинга, работающую в этой вирт.машине — так что мониторинг надо вешать в хост-систему или в соседнюю вирт.машину.
Один из резидентов Hacker News даже предложил радикальное решение — переписать ядро Linux под unikernels с нуля на Rust. По его словам, язык решит проблему с большим количеством багов, связанных с безопасностью памяти.Идею переписать систему на безопасный язык — я добряю и приветствую. Однато, тут можно ожидать проблему с производительностью.
легковесное ядро HermiTux позволяет быстро запускать приложения поверх гипервизора — по словам авторов, время загрузки не превышает 0,1 сек.Кажется, до кого-то начинает доходить, что внутри вирт.машины не нужно ядро, разработаное не для работы на голом железе, а для работы именно внутри вирт.машины. Т.е. большинство сист.вызовов приложения надо напрямую перенаправлять в хозяйскую систему, а не пытаться самостоятельно манипулировать аппаратурой.
Если Вы предлагаете это отменить — то проще всего вернуться к DOS. Ну да, нужен новый DOS — 64-битный, с драйверами. Но это будет именно DOS, в т.ч. и с отсутствием защиты файлов от несанкционированного доступа.
В какой-то мере, кажется, именно это и предлагается. Защита, может и будет, но на уровне прав доступа ФС, защита от ошибок программиста, от случайных попыток записать файл, который сам же объявил как RO. На голом железе — просто один процесс в нулевом кольце с прямым доступом к железу. На виртуалке для гипервизора — полноценная ОС, а внутри тот же один процесс в нулевом кольце с тем же прямым доступом к железу, но к виртуальному, с защитой на уровне гипервизора.
Вообще-то, смысл разделения ядра и приложений — в защите ядра от приложений и в защите приложений друг-от-друга. Если Вы предлагаете это отменить — то проще всего вернуться к DOS. Ну да, нужен новый DOS — 64-битный, с драйверами. Но это будет именно DOS, в т.ч. и с отсутствием защиты файлов от несанкционированного доступа.
Haiku?
VolCh:
Нет уж, ведение файловой системы надо передать защищённому процессу. Вплоть до того, что этот процесс работает на другм процессоре с отдельной памятью — как это сделано в сетях с файловыми серверами. Вот при таком подходе — да, можно позволить прикладной программе резвиться в режиме ядра или даже использовать процессор в режиме без какой-либо защиты.
Finnix:
А защита ядра от приложений и защита приложений друг-от-друга — я так понял, там присутствует в полноценном режиме вытесняющей многозадачности.
Защита, может и будет, но на уровне прав доступа ФС, защита от ошибок программиста, от случайных попыток записать файл, который сам же объявил как RO.Тут есть более интересная проблема: Все современные файловые системы имеют буферизацию данных (кэш для чтения и для записи). А если программа работает в режиме ядра — она может случайно записать что-то в эти буферы; просто выставить неверное значение указателя и записать по этому адресу произвольное значение. Или можно записать произвольное значение в программный код драйвера файловой системы.
Нет уж, ведение файловой системы надо передать защищённому процессу. Вплоть до того, что этот процесс работает на другм процессоре с отдельной памятью — как это сделано в сетях с файловыми серверами. Вот при таком подходе — да, можно позволить прикладной программе резвиться в режиме ядра или даже использовать процессор в режиме без какой-либо защиты.
Finnix:
Haiku?Если Haiku не имеет защиты файлов — то она очень скоро станет благодатной средой для распространения вирусов. Т.е. «взлететь» эта система может — но как только она станет более-менее популярной, она рухнет с жуткими скандалами.
А защита ядра от приложений и защита приложений друг-от-друга — я так понял, там присутствует в полноценном режиме вытесняющей многозадачности.
Если программа может случайно записать байтик «не туда», значит в программе ошибка. Чем запись мусора в код драйвера принципиально отличается от записи некорректных данных в файл или массив? Более того, пусть лучше система грохнется, чем программа будет незаметно подсовывать лажу.
Плюс, мне кажется, сейчас большинство контейнеризованных сервисов не используют файлы вообще.
Плюс, мне кажется, сейчас большинство контейнеризованных сервисов не используют файлы вообще.
Программы содержат ошибки. Поэтому хотелось бы иметь хоть какую-то защиту — пусть не от всего, но максимально возможную. Поэтому изоляция вычислительной подзадачи в виде отдельного процесса — намного лучше, чем запуск этой вычислительной подзадачи в режиме ядра.
Допустим, программа занимает адреса от 0 до 999, а ядро и драйверы — адреса от 1000 до 1999 (ну, числа условные). Допустим, в результате сбоя программа пишет по адресу 1477. Если программа изолирована в виде процесса — она реально грохнется. Если же программа работает в режиме ядра — она повредит код или данные ядра. Что лучше?
Понятно, что от обращения по адресу 666 такая защита не спасёт. Но хоть что-то…
Если «большинство контейнеризованных сервисов не используют файлы вообще», то что они используют?
Если базу данных — то как они к ней обращаются? И как Unikernels ускорит работу этих обращений?
Допустим, программа занимает адреса от 0 до 999, а ядро и драйверы — адреса от 1000 до 1999 (ну, числа условные). Допустим, в результате сбоя программа пишет по адресу 1477. Если программа изолирована в виде процесса — она реально грохнется. Если же программа работает в режиме ядра — она повредит код или данные ядра. Что лучше?
Понятно, что от обращения по адресу 666 такая защита не спасёт. Но хоть что-то…
Если «большинство контейнеризованных сервисов не используют файлы вообще», то что они используют?
Если базу данных — то как они к ней обращаются? И как Unikernels ускорит работу этих обращений?
Если программа изолирована в виде процесса — она реально грохнется. Если же программа работает в режиме ядра — она повредит код или данные ядра. Что лучше?Без разницы. В отсутствие процессов данные ядра имеют нулевую ценность.
что они используют?S3 и подобное. Очереди, Logstash.
И как Unikernels ускорит работу этих обращений?Сокеты, наверное, тоже ускорятся.
Помните суперкомпьютер на Малинках? В него бы Library OS легла идеально.
В отсутствие процессов — мы лишаемся вытесняющей многозадачности с защитой процессов. Т.е. на такую машину уже невозможно зайти по SSh и запустить программу анализа, которая подскажет нам, что там происходит. Это как в DOS.
Я не понял, как очереди могут заменить собой файлы. Это сильно разные сущности.
В принципе, вместо файлов можно использовать транзакционную СУБД. Во многих случаях это правильно. Но в других случаях — гибкости СУБД будет остро не хватать.
Я не понял, про какие сокеты Вы говорите. Как правило, через сокеты программа общается с программами, работающими на том же компьютере; при использовании вирт.машин — на той же вирт.машине. Но выше Вы предлагаете отказаться от многозадачности.
Смысл Library OS на «суперкомпьютере на Малинках» я не понял. В каком режиме это должно работать?
Я не понял, как очереди могут заменить собой файлы. Это сильно разные сущности.
В принципе, вместо файлов можно использовать транзакционную СУБД. Во многих случаях это правильно. Но в других случаях — гибкости СУБД будет остро не хватать.
Я не понял, про какие сокеты Вы говорите. Как правило, через сокеты программа общается с программами, работающими на том же компьютере; при использовании вирт.машин — на той же вирт.машине. Но выше Вы предлагаете отказаться от многозадачности.
Смысл Library OS на «суперкомпьютере на Малинках» я не понял. В каком режиме это должно работать?
Sign up to leave a comment.
Первый прототип: Unikernels как этап в эволюции Linux