03.08.2019 15:19
itglobalcom 39 17400 Источник
В начале июля группа инженеров из Red Hat и Бостонского университета выпустила whitepaper, в котором предложила сменить монолитное ядро Linux на архитектуру unikernels. Мы решили разобраться в материале и обсудить реакцию ИТ-комьюнити на это предложение.


Фото — Eamonn Maguire — Unsplash

Unikernels как альтернатива


Известно, что Linux использует монолитное ядро. Оно управляет процессами, сетевыми функциями, периферией и доступом к файловой системе. Однако как пишут авторы статьи из Red Hat и Бостонского университета (стр.1), такая структура имеет свои недостатки. В частности, высокопроизводительные приложения вынуждены использовать фреймворки вроде DPDK и SPDK, чтобы получить беспрепятственный доступ к устройствам ввода/вывода в обход ядра.

Определенные трудности возникают и в облаке. Для большей безопасности корпоративные приложения развертывают на отдельных виртуальных машинах. Каждая ВМ находится под управлением полновесной операционной системы. В результате вычислительные ресурсы серверов расходуются не самым оптимальным образом.

Улучшить ситуацию может альтернативный подход — unikernels. Идея следующая — связать приложение с необходимыми библиотеками операционной системы и скомпилировать их в один бинарный файл. После этот «бинарник» можно использовать для загрузки системы. Такой подход дает возможность специализировать функциональность ОС под нужды конкретного приложения.

Ресурсы такой системы расходуются эффективнее. Также unikernels обладают более высокой производительностью, по сравнению с монолитной архитектурой ядра. Причина — упрощение IO-путей, так как все данные и файлы размещаются в едином адресном пространстве. Также пропадает необходимость переключать контекст между пользовательским пространством и пространством ядра.

Команда инженеров из Бостонского университета и Red Hat разработала прототип Linux на базе unikernels. Операционная система получила название Unikernel Linux (UKL).

Что сделали инженеры


Как заявляют разработчики (стр.3), они изменили всего одиннадцать и добавили двадцать новых строк кода в Linux kernel v5.0.5 и glibc. «Классическое» ядро сохранило работоспособность — пользователь может выбрать способ сборки (UKL или нет).

Авторы создали небольшую UKL-библиотеку, в которой разместили специальные «заглушки», которые маскируют неиспользуемые системные вызовы. Также они модифицировали линкер ядра, чтобы определять новый тип сегментов, например TLS (thread local storage) из бинарников ELF. Еще был модифицирован процесс сборки, который теперь объединяет код приложения, glibc и UKL-библиотеку в один бинарный файл.

Инженеры работают над исправлением ряда недостатков. Например, они планируют переместить TLS-память из пространства ядра и отказаться от vmalloc при управлении распределением памяти, чтобы упростить систему.

Мнения


Разработчики Red Hat говорят, что UKL может стать полноценной альтернативой для запуска процессов, работающих с аппаратным обеспечением напрямую (в обход ядра). Авторы оригинальной статьи заявляют (стр.2), что сервис кэширования memcached под unikernels работает на 200% быстрее, чем под Linux.

В целом об инициативе авторов оригинальной статьи положительно отозвалось и ИТ-сообщество. Резиденты Hacker News отметили, что архитектура unikernels значительно повысит безопасность программной среды. В случае взлома приложения хакер получит доступ лишь к его бинарнику.


Фото — Jack Young — Unsplash

Один из резидентов Hacker News даже предложил радикальное решение — переписать ядро Linux под unikernels с нуля на Rust. По его словам, язык решит проблему с большим количеством багов, связанных с безопасностью памяти. Другой пользователь назвал идею хорошей, однако предложил подождать несколько лет, пока разработчики языка разберутся с нестабильностью библиотек. Хотя один энтузиаст уже пишет свою операционную систему на Rust. Исходники можно найти на GitHub.

Другие реализации


UKL — не единственная реализация операционной системы на базе unikernels. Например, похожее решение разрабатывает группа инженеров из Политехнического университета Виргинии, компании Qualcomm и Рейнско-Вестфальского технического университета Ахена в Германии. Их легковесное ядро называется HermiTux. Оно позволяет быстро запускать приложения поверх гипервизора — по словам авторов, время загрузки не превышает 0,1 сек. Потребление памяти в тестовом окружении составляет 9 Мбайт, что в десять раз меньше, чем у классического ядра Linux.

Также имеет смысл отметить ОС MirageOS, разработанную на OCaml. Ядро может запускаться поверх гипервизоров Xen, KVM, BHyve и VMM (OpenBSD), а также на мобильных платформах. Система поддерживает несколько десятков библиотек на языке OCaml для выполнения сетевых операций (DNS, SSH, OpenFlow, HTTP, XMPP), работы с хранилищами и параллельной обработки данных. Можно сказать, что MirageOS — это один из первых успешных unikernels-проектов. Интересно, что его сайт с блогом также реализован как unikernel.

Эти операционные системы уже используются в продакшн-средах многими организациями — например, Кембриджским университетом, IBM, Ericsson и Docker. Есть вероятность, что скоро к этим ОС присоединится новая — Unikernel Linux.


О чем мы пишем в корпоративном блоге:

Комментарии (39)


  1. apro
    03.08.2019 18:48
    #20469179
    +4

    Хотя один энтузиаст уже пишет свою операционную систему на Rust.

    На самом деле много кто пишет ОС на Rust, но самая известная с довольно большой командой это:


    https://www.redox-os.org/


    1. Vadem
      03.08.2019 19:42
      #20469219
      +2

      Из известных ещё Fuchsia частично на Rust написана.


      1. khim
        03.08.2019 23:49
        #20469685
        +1

        Там только SDK для Rust. Тоже неплохо, но вроде никаких компонентов на Rust у них нету.


        1. Vadem
          04.08.2019 22:34
          #20471547

          Я был под впечатлением, что Fuchsia частично на Rust написана, т.к. видел код на нём в исходниках.
          Например тынц, тынц, тынц и тынц. Ну и ещё много других мест находил.
          В ядре правда ничего на Rust я не нашёл.
          Не понятно также какой процент от общего количества исходников написан на Rust. Но можно попробовать посчитать.


          1. khim
            05.08.2019 01:22
            #20471839

            В данном случае совершенно неважно какой процент написан на Rust. Нужно смотреть за динамикой. Вообще так-то кажется, что как раз для middleware OS Rust вообще подходит идеально: обычно там нет каких-то сильно хитрых алгоритмов (они в других местах системы сидят), но важно не напутать в [относительно] простом коде с правами доступа…

            Если Rust там приживётся и количество компонент на нём будет расти — ну это очень хороший признак.


  1. Alex_ME
    03.08.2019 20:45
    #20469321
    +1

    1) Насколько я знаю (поправьте меня, если я ошибаюсь) DPDK и сетевой стэк имеет более легковесный, чем стэк в ядре (который универсальный и все такое), а снижение накладных расходов на syscalls и копирование данных в пользовательское адресное пространство и обратно
    2) Т.е. вся их скомпилированная в один большой бинарь система исполняется в Ring 0? Минус накладные расходы на системные вызовы с переключениями контекста, сбросом буферов TLB и прочим. Минус безопасность. Нужно очень доверять запущенному приложению и быть уверенным, что оно не полезет в чужую память, не упадет и так далее. Вообще, вспоминается проект Microsoft Singularity.


    1. khim
      03.08.2019 23:51
      #20469687
      -1

      Вообще, вспоминается проект Microsoft Singularity
      Там хотя бы защита на уровне языка была. Тут скорее Windows 9X и её «надёжность» стоит вспомнить…


      1. ss-nopol
        05.08.2019 15:50
        #20473895

        Да что уж там… Прямой доступ к железу, единое адресное пространство… Вспоминать надо MS-DOS…


    1. 0xd34df00d
      04.08.2019 04:19
      #20469913
      +4

      А какая чужая память, если это приложение — это все, что крутится на машине? Нет никакой чужой памяти.


      1. VolCh
        04.08.2019 07:30
        #20469987

        Тут больше вопрос по использованию с докером


        1. dominigato
          04.08.2019 16:05
          #20470867

          Так это вместо докера, судя по описанию. Одно приложение в мини-виртуалке


          1. VolCh
            05.08.2019 00:43
            #20471777

            Так эта мини-виртуалка напрямую с железом действует, поверх какой-то ОС/гипервизора?


            1. dominigato
              05.08.2019 11:08
              #20472609

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


            1. Ti_Fix
              05.08.2019 12:08
              #20472899

              Идея следующая — связать приложение с необходимыми библиотеками операционной системы и скомпилировать их в один бинарный файл. После этот «бинарник» можно использовать для загрузки системы.
              Получается, что ваше приложение превращается в часть ядра операционной системы.


    1. voidMan
      04.08.2019 04:29
      #20469917

      Никто не предлагает отдавать любому приложению такой доступ, просто появляется возможность делать специализированные сборки ядра под некое приложение, как например сервер memcached или redis.


  1. keydon2
    03.08.2019 21:07
    #20469365
    +3

    Либо я не понял идею, либо это какая-то наркомания.

    В целом об инициативе авторов оригинальной статьи положительно отозвалось и ИТ-сообщество. Резиденты Hacker News отметили, что архитектура unikernels значительно повысит безопасность программной среды. В случае взлома приложения хакер получит доступ лишь к его бинарнику.

    Но ведь не только к бинарнику, но и к данным, которые обрабатывает этот бинарник и к ресурсам, которые он использует (впрочем данные тоже ресурс). Т.е. фактически хакер получает точно такой же доступ как и на обычном контейнере. Более того тут и пользовательского уровня не будет — избавляемся от одних уязвимостей и становимся более уязвимым к другим.

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

    Как это дело дебажить? Туда ж ни по ssh не зайти, ни логи почитать, ни прочие плюшки вроде syslog'а, нулевого даунтайма при обновлении не получить (без балансировки уровня выше), крона и прочего. В проде это гораздо ценее чем даже 100% к производительности и удаления некоторых уязвимостей (особый вопрос насколько это действительно улучшает безопасность).

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

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


    1. IkaR49
      03.08.2019 23:20
      #20469627
      +1

      Вот меня упоминание в сабже раста тоже несколько смутило. Я люблю раст, но извините, это же практически сказать «переписать линукс на раст».


    1. Loggus66
      04.08.2019 06:56
      #20469967

      Как это дело дебажить? Туда ж ни по ssh не зайти, ни логи почитать, ни прочие плюшки вроде syslog'а, нулевого даунтайма при обновлении не получить (без балансировки уровня выше), крона и прочего.

      Изучаю k8s сейчас, те же мысли. Так что… Может и взлететь, будет модной молодёжной технологией.


    1. balsoft
      04.08.2019 09:27
      #20470049

      Мне вот тоже интересно — какие же проблемы безопасности мы решаем? Уязвимости в ядре по-прежнему останутся уязвимостями, только теперь к ним добавятся уязвимости приложения (которых гораздо больше, чем уязвимостей в ядре), при этом каждая такая уязвимость, которая раньше осталась бы в user-space, теперь дает полный доступ к машине на уровне даже большем, чем root в user-space.


      1. dominigato
        04.08.2019 16:09
        #20470877
        +1

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


    1. Zarathu5trA
      04.08.2019 23:22
      #20471645

      Вы кажется не улавливаете суть. Фактически, концепция 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 смотрит на отдельное, пусть и большое и сложное, приложение/сервис, и думает как бы это так получше его организовать.


      1. VolCh
        05.08.2019 00:48
        #20471793

        То есть unikernels это, прежде всего, замена "одно универсальное ядро ОС на один специфический процесс" на "одно специфическое ядро ОС на один специфический процесс"? Замена универсальных ОС на голом железе или полной виртуализации путём выпиливания всего ненужного для конкретного приложения и, перевода ядра с приложением на один уровень защиты?


        1. anton19286
          05.08.2019 10:26
          #20472455

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


          1. apro
            05.08.2019 10:57
            #20472563

            В принципе, уровень защиты почти теряет смысл

            Но защита программиста самого от себя ведь все еще актуальна.
            Теперь ошибка в сервисе который сидит рядом с главным и перепаковывает логи, чтобы послать в хранилище логов может уронить всю систему, или вызвать повреждение любых данных. Любая ошибка в программе может вызвать "kernel panic" или просто все наглухо повесить, если например "расстрелять" память потока ядра обслуживающего IRQ.


            1. anton19286
              06.08.2019 08:39
              #20475875

              Ну это смотря на чем и как писать. Хотя, почему бы и нет? Какой смысл держать живым ядро, если приложение уже недоступно?


              1. apro
                06.08.2019 11:54
                #20476573

                Ну это смотря на чем и как писать.

                Ну большинство VM "безопасных" языков программирования написаны на C/C++.


                Хотя, почему бы и нет?

                Эээ… Допустим вы крутите БД, она написана с учетом инварианта что ОС позволяет при падении БД быть уверенным, что либо данные совсем не записались, либо записались целиком. А теперь при возможности уронить вместе с БД ядро, у вас может произойти все что угодно при перезапуске БД,
                например потеря вообще всех данных из-за того что расстреляли память vfs и всего что ниже и она при перезапуске так синхронизировала кэш ФС,
                что даже fsck не может найти "концов".


  1. maxzhurkin
    04.08.2019 00:05
    #20469709
    +2

    А ещё в эмбедовке можно развернуться, где полноценная ОС — жирновато, а «всё сам» — грустновато


    1. yakk
      04.08.2019 15:03
      #20470741

      Действительно, по описанию больше похоже на какую-то embedded RTOS статически скомпонованую с приложением. Только вот все вспомогательные демоны, для логов или для отладки нужно получается также встраивать непосредственно в приложение, ну или расширять возможности ОС.


    1. Zarathu5trA
      04.08.2019 23:23
      #20471647

      Опоздали с идеей. Уже сделано :-) www.tockos.org/assets/papers/tock-sosp2017.pdf


  1. evocatus
    04.08.2019 12:48
    #20470459
    +1

    Думаю, что люди, которые сталкивались с 10Гбит Ethernet, 40Гбит Ethernet и пр. смотрят на эти вещи совсем по-другому. Когда приходится использовать механизмы zero-copy (PACKET_MMAP), то мечтаешь именно о чём-то типа этой Unikernel.
    Linux ведь много где используется, в т.ч. для скоростного ввода-вывода со специального оборудования, никакого выхода в Сеть там нет, и на уязвимости, по большому счёту, наплевать, а самое главное — throughput и latency любой ценой.


  1. realimba
    04.08.2019 14:28
    #20470663
    -1

    Предлагаю авторам не мелочиться и сразу идти в сторону baremetal. Механизмы безопасности вырезали, зачем оставлять HAL, вдруг оно тоже меделнно работает? А все баги просто лечить быстрым рестартом каждые 10 сек.


  1. gdt
    04.08.2019 15:27
    #20470797

    Попахивает экзоядром, разве нет?


    1. Zarathu5trA
      04.08.2019 23:25
      #20471649

      Именно! Все unikernel-ы по сути тянуться из так называемых LibraryOS, которые в свою очередь происходят из идей экзоядра.


  1. dominigato
    04.08.2019 16:14
    #20470891

    Что-то похожее уже мутят везде. Kata containers засунули докер в виртуалку, но тоже обрезанную со всех сторон. Есть и другие попытки скрестить контейнеры с виртуалками, пытаясь соединить хорошую изоляцию с хорошим перформансом. Думаю мы будем свидетелями еще многих опытов на эту тему.


  1. bgnx
    04.08.2019 16:26
    #20470919

    В статье был упомянут MirageOS, но почему-то не упоминается проект IncludeOS который является более известным и мейнстримовым — с++ а не ocaml (советую посмотреть на ютюбе несколько докладов про includeos где также освещается общая тема unikernels, например в вопросе безопасности — https://youtu.be/t4etEwG2_LY?t=1810)


  1. Karpion
    04.08.2019 19:55
    #20471305

    Читаем внимательно:

    В частности, высокопроизводительные приложения вынуждены использовать фреймворки вроде DPDK и SPDK, чтобы получить беспрепятственный доступ к устройствам ввода/вывода в обход ядра.
    и
    Идея следующая — связать приложение с необходимыми библиотеками операционной системы и скомпилировать их в один бинарный файл. После этот «бинарник» можно использовать для загрузки системы. Такой подход дает возможность специализировать функциональность ОС под нужды конкретного приложения.
    Ну и каким же образом «компиляция всей системы в один файл» позволит «получить беспрепятственный доступ к устройствам ввода/вывода в обход ядра хост-системы»? А если такого доступа нет — то в чём вообще смысл?

    После этот «бинарник» можно использовать для загрузки системы.
    Образ вирт.машины — это бинарник. Ну и какая разница — лежит ли это дело в одном файле или в разных?
    В Windows — драйверы лежат в отдельных файлах. Это не мешает системе быть монолитной.

    Также unikernels обладают более высокой производительностью, по сравнению с монолитной архитектурой ядра. Причина — упрощение IO-путей, так как все данные и файлы размещаются в едином адресном пространстве.
    Судя по описанию — unikernels правильнее всего было бы назвать «супермонолитной системой», ибо там не только ядро монолитно, но и в ядро впихнуто одно приложение… или несколько…

    Вообще-то, смысл разделения ядра и приложений — в защите ядра от приложений и в защите приложений друг-от-друга. Если Вы предлагаете это отменить — то проще всего вернуться к DOS. Ну да, нужен новый DOS — 64-битный, с драйверами. Но это будет именно DOS, в т.ч. и с отсутствием защиты файлов от несанкционированного доступа.

    Авторы создали небольшую UKL-библиотеку, в которой разместили специальные «заглушки», которые маскируют неиспользуемые системные вызовы.
    Я ещё в 199*-е годы перекомпилировал ядро FreeBSD, удаляя из него ненужные мне компоненты. И никакой UKL-библиотеки мне не требовалось!

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

    Один из резидентов Hacker News даже предложил радикальное решение — переписать ядро Linux под unikernels с нуля на Rust. По его словам, язык решит проблему с большим количеством багов, связанных с безопасностью памяти.
    Идею переписать систему на безопасный язык — я добряю и приветствую. Однато, тут можно ожидать проблему с производительностью.

    легковесное ядро HermiTux позволяет быстро запускать приложения поверх гипервизора — по словам авторов, время загрузки не превышает 0,1 сек.
    Кажется, до кого-то начинает доходить, что внутри вирт.машины не нужно ядро, разработаное не для работы на голом железе, а для работы именно внутри вирт.машины. Т.е. большинство сист.вызовов приложения надо напрямую перенаправлять в хозяйскую систему, а не пытаться самостоятельно манипулировать аппаратурой.


    1. VolCh
      05.08.2019 00:54
      #20471807

      Если Вы предлагаете это отменить — то проще всего вернуться к DOS. Ну да, нужен новый DOS — 64-битный, с драйверами. Но это будет именно DOS, в т.ч. и с отсутствием защиты файлов от несанкционированного доступа.

      В какой-то мере, кажется, именно это и предлагается. Защита, может и будет, но на уровне прав доступа ФС, защита от ошибок программиста, от случайных попыток записать файл, который сам же объявил как RO. На голом железе — просто один процесс в нулевом кольце с прямым доступом к железу. На виртуалке для гипервизора — полноценная ОС, а внутри тот же один процесс в нулевом кольце с тем же прямым доступом к железу, но к виртуальному, с защитой на уровне гипервизора.


    1. Finnix
      05.08.2019 22:48
      #20475269

      Вообще-то, смысл разделения ядра и приложений — в защите ядра от приложений и в защите приложений друг-от-друга. Если Вы предлагаете это отменить — то проще всего вернуться к DOS. Ну да, нужен новый DOS — 64-битный, с драйверами. Но это будет именно DOS, в т.ч. и с отсутствием защиты файлов от несанкционированного доступа.

      Haiku?


      1. Karpion
        06.08.2019 21:22
        #20478399

        VolCh:

        Защита, может и будет, но на уровне прав доступа ФС, защита от ошибок программиста, от случайных попыток записать файл, который сам же объявил как RO.
        Тут есть более интересная проблема: Все современные файловые системы имеют буферизацию данных (кэш для чтения и для записи). А если программа работает в режиме ядра — она может случайно записать что-то в эти буферы; просто выставить неверное значение указателя и записать по этому адресу произвольное значение. Или можно записать произвольное значение в программный код драйвера файловой системы.

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

        Finnix:
        Haiku?
        Если Haiku не имеет защиты файлов — то она очень скоро станет благодатной средой для распространения вирусов. Т.е. «взлететь» эта система может — но как только она станет более-менее популярной, она рухнет с жуткими скандалами.
        А защита ядра от приложений и защита приложений друг-от-друга — я так понял, там присутствует в полноценном режиме вытесняющей многозадачности.