XEN и будущее automotive: как опенсорс-гипервизор становится конкурентом коммерческим автомобильным решениям

    Это история в двух частях — о новом витке развития automotive. В первой Алекс Агизим, CTO Automotive & Embedded Systems в EPAM, расскажет о виртуализации в автомобильном компьютере. А также как и почему опенсорсный гипервизор XEN может стать полноценным конкурентом коммерческим решениям для автомобильной индустрии.

    image

    Сразу должен предупредить — я не буду бросать в читателя кусками кода и инженерными тонкостями. Здесь речь пойдет о глобальных вещах, которые, как мы думаем, изменят автомобильную индустрию уже в ближайшие 2-4 года. Так же, как 12 лет назад мобильные телефоны навсегда изменились с появлением Android и Apple iOS.

    В EPAM Automotive мы занимаемся двумя крупными блоками: виртуализацией и облачной платформой для деплоймента сервисов прямо в автомобиль. Этот рассказ — о первом.

    Два подхода


    Если вы следите за автомобильной темой, то наверняка заметили, как активно Google развивает тему инфотейнмента со своим Android Auto OS. С конца прошлого года компания заключила несколько стратегических партнерств с автопроизводителями по интеграции Android Auto OS в автомобиль.

    Но у производителей по-прежнему есть опасения. Главная причина — safety. В современных и будущих автомобилях Infotainment Cluster и Instrumental Cluster, содержащий “жизненно важные” приборы и индикаторы, становятся единым целым и используют одни и те же ресурсы. Физические стрелки и индикаторы сменились нарисованными. Однако водитель должен видеть правдивые показания скорости, уровень топлива, состояние тормозной системы, двигателя несмотря ни на что. Недопустимо, если где-то в пути экраны вдруг зависнут и потребуют перезагрузки. А по опыту смартфонов на Android мы знаем, что это вполне возможно.

    Производители автомобилей решают такую проблему в лоб: ставят два или больше компьютеров. Например, первый занимается отрисовкой и обслуживанием всей приборной панели. Во втором бегает Android Auto OS и показывает навигацию, музыку, приложения и т.д.

    У этого варианта есть несколько минусов. Во-первых, несколько компьютеров все-таки дороже одного. Во-вторых, усложняется имплементация: нужно обеспечивать обмен информацией между Android-частью и insturmental cluster, согласованность и множество других аспектов.

    Другой вариант — по примеру клауда использовать виртуализацию с помощью гипервизора. Мощности и возможностей современных микропроцессоров в автомобильных компьютерах вполне достаточно. К компьютеру подключаются минимум два экрана. Один — для Android — инфотейнмент. Другой — для обслуживания приборной панели. Две операционные системы бегают в изолированных виртуальных машинах. Даже если Android “устанет” и упадет, перезагрузится только виртуальная машина, в которой он исполняется.

    С такой консолидацией мы можем работать на одном компьютере и сделать интеграцию гораздо проще. Но и здесь есть нюансы.

    Автомобильный гипервизор


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

    В автомобильном же компьютере, кроме CPU, оперативной памяти и хранилища, есть разные копроцессоры для специфических задач. К примеру, тот же GPU, который нужен и Android, и приборной панели. Значит, задача гипервизора — предоставить возможность обеим операционным системам пользоваться копроцессорами. К тому же, сделать так, чтобы Android не заткнул копроцессор какой-то нелегальной командой или программной ошибкой.

    Это требование functional safety – Instrumental Cluster должен работать без оглядки на возможные танцы Android. Поэтому гипервизор должен быть достаточно продвинутым и иметь специальные механизмы, с помощью которых обеспечивается полная изоляция.

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

    1. Полная изоляция виртуальных машин, на которых работают инфотейнмент и приборная панель


    image

    Во-первых, у компьютера много периферии, кнопки, тачскрин network, etc… Виртуалиация периферии уже поддерживается набором драйверов.

    image

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

    image

    В-третьих, реализована виртуализация TEE Support — trusted execution environment. Это специальная, аппаратно защищенная зона в процессоре, которая занимается исполнением различных секьюрных процедур. Но так как операционных систем больше одной, запросы от них к TEE тоже разделены.

    image

    Ниже можно увидеть статус компонент и если интересно посмотреть код

    image

    2. Питание и производительность


    Любая операционная система управляет питанием и производительностью и может переводить компьютер в режим низкого энергопотребления в соответствии с текущими задачами и загрузкой. То же может захотеть сделать и автомобильный Android: если нет текущих задач, он решает отправить процессор в power save mode. Но ОС, которая занимается приборами, должна продолжать работать. Этот конфликт мы решаем специальным расширением гипервизора. Оно контролирует состояние всей системы и управляет питанием и производительностью.

    Следующий момент — реалтайм. Система должна работать с гарантированным расписанием. Этим мы тоже занимается в рамках XEN Real-Time Scheduler.

    3. Функциональная безопасность


    Последний по очереди, но первый по значимости для будущего автоиндустрии блок. Производители автомобилей сегодня понимают, что виртуализационный подход поможет им действительно создавать значительно более гибкие и мощные системы для обслуживания digital cockpit. Для этого нужен automotive-grade гипервизор.

    На рынке есть 3-4 коммерческих решения automotive-grade гипервизоров. Но все коммерческие продукты обладают недостатками:

    • дороговизна лицензии;
    • отсутствие возможность легко поменять что-либо в ПО по своим потребностям
    • производитель за такое ломит чек и сроки;
    • vendor lock.

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

    Что осталось решить


    На пути в опенсорс остается последняя, но ключевая преграда. Открытый гипервизор для автомобиля должен быть functional safety compliant. До недавнего времени все считали, что сделать его таким невозможно. Теперь есть подвижки.

    Последние время мы активно работаем с XEN Hypervisor опенсорс комьюнити. Задача — адаптировать процесс разработки, чтобы XEN можно было сертифицировать по safety.

    В конце марта прошел саммит в Кембридже, где собрались все заинтересованные лица. Во-первых, все основные компании, которые занимаются разработкой XEN: Citrix, ARM, Xilinx, Renesas, EPAM. Во-вторых, компании, которые занимаются сертификацией В-третьих, компании, которые предоставляют инструменты для автоматического анализа системы и выявления проблемных мест.

    В результате саммита мы разработали план, по которому совершенно возможно сделать опенсорс гипервизор functional safety compliant. До конца этого года мы планируем получить конкретный набор необходимых артефактов, чтобы при интеграции XEN в автомобильные компьютеры их можно было сертифицировать по safety.

    XEN становится полноценным конкурентом коммерческим решениям в автопромышленности и отбирая у них последний аргумент об отсутствии safety сертификации.

    Из последнего — в середине июля прошел Xen Developer Summit. Function Safety была одной из основных тем. Мы презентовали подход к решению Functional Safety (по ссылке PDF).

    Почему XEN?


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

    Проект XEN существует с 2003 года и по сравнению с другими опенсорсными решениями имеет очень широкий деплоймент в дата-центрах. Он уже стал достаточно зрелым. С 2012 года XEN имеет нативную поддержку ARM-архитектуры. А процессоры именно этой архитектуры в основном используются в автопромышленности.

    Кроме того, мы провели много работы, проанализировали разные решения и добились очень хороших показателей производительности. К примеру, если производительность операционной системы, которая бегает на процессоре без виртуализации, равна Х, то на виртуальной машине это 0,96-0,97X. А в коммерческих гипервизорах падение производительности может достигать 30%. Разница на порядок выглядит убедительно.

    Поэтому XEN кажется нам подходящим базовым решением. Поэтому EPAM драйвит этот проект. Есть уже несколько европейских автопроизводителей, которые занимаются оценкой решения на базе XEN для будущих автомобилей с digital cockpit, Android внутри и прочими вещами, о которых я говорил выше.

    Параллельно этой большой истории мы развиваем собственную connected vehicle платформу Aos. Ее основная идея в том, что мы, с одной стороны, даем разработчикам connected services возможность деплоить их прямо в автомобильный компьютер, а с другой — изолируем их от критических функций, обеспечивая безопасность. Об этом я расскажу в следующей части.
    EPAM
    119,59
    Компания для карьерного и профессионального роста
    Поделиться публикацией

    Комментарии 15

      0
      А в легкомоторной авиации не думали это решение применять?
        0
        Там таки берут второй компьютер
        +2

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


        С учётом стоимости "второго компьютера" попытка экономить на этих спичках звучит как катастрофа. Причина? Никто, никогда не поручится за код магнитолы. А она будет физически херачить на том же процессоре, который управляет тормозами и впрыском в двигатель.


        Просто посмотрите сюда: https://www.cvedetails.com/vulnerability-list/vendor_id-6276/XEN.html


        An issue was discovered in Xen through 4.11.x on Intel x86 platforms allowing guest OS users to cause a denial of service (host OS hang) because Xen does not work around Intel's mishandling of certain HLE transactions associated with the KACQUIRE instruction prefix.


        An issue was discovered in Xen through 4.11.x allowing 64-bit PV guest OS users to cause a denial of service (host OS crash) because #GP[0] can occur after a non-canonical address is passed to the TLB flushing code. NOTE: this issue exists because of an incorrect CVE-2017-5754 (aka Meltdown) mitigation.


        An issue was discovered in Xen 4.11 allowing HVM guest OS users to cause a denial of service (host OS crash) or possibly gain host OS privileges because x86 IOREQ server resource accounting (for external emulators) was mishandled.


        An issue was discovered in Xen 4.9.x through 4.11.x, on Intel x86 platforms, allowing x86 HVM and PVH guests to cause a host OS denial of service (NULL pointer dereference) or possibly have unspecified other impact because nested VT-x is not properly restricted.


        An issue was discovered in the Linux kernel through 4.17.11, as used in Xen through 4.11.x. The xen_failsafe_callback entry point in arch/x86/entry/entry_64.S does not properly maintain RBX, which allows local users to cause a denial of service (uninitialized memory usage and system crash). Within Xen, 64-bit x86 PV Linux guest OS users can trigger a guest OS crash or possibly gain privileges.


        … OS kernels may not expect this order of events and may therefore experience unexpected behavior when it occurs.


        An issue was discovered in Xen through 4.9.x. Grant copying code made an implication that any grant pin would be accompanied by a suitable page reference. Other portions of code, however, did not match up with that assumption. When such a grant copy operation is being done on a grant of a dying domain, the assumption turns out wrong. A malicious guest administrator can cause hypervisor memory corruption, most likely resulting in host crash and a Denial of Service. Privilege escalation and information leaks cannot be ruled out.


        A grant unmapping issue was discovered in Xen through 4.9.x. When removing or replacing a grant mapping, the x86 PV specific path needs to make sure page table entries remain in sync with other accounting done. Although the identity of the page frame was validated correctly, neither the presence of the mapping nor page writability were taken into account.


        … Я не хочу этот рассадник багов между кодом для тормозов моей машины и stagefright на моей магнитоле.

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

          Тоже присоединяюсь к этому запросу. Как-то очень сомнительно, что кто-то решится применять такое решение в реальных системах.


          Как по мне простым и одновременно удобным решением являются решения типа CarPlay — то есть основной компьютер выделяет видео-окно, в котором можно делать все, что хочешь. И пусть та ОС падает сколько хочет.

            0
            Расслабьтесь — ни на каких не будет! Управление двигателем — это свой мир очень узко специализированных RTOS с цилиндр-синхронными процессами, коих можно по пальцам одной руки пересчитать (как и производителей тех систем) и про которые мало кто слышал, и не будет там ни андроидов ни гипервизоров…
            +1
            Двигателем управляет другая система, которая работает на OS-less микроконтроллере.
            Infotainment Cluster и Instrumental Cluster это части отвечающие за отображение — навигация-радио и приборная панель. Приборная панель часть системы безопасности, поэтому ее важно изолировать от инфотеймента, но все системы отвечающие за двигатели, вождение и активную безопасность вынесены в отдельные «железные» компоненты повышенной надежности.
              0

              Тогда я не могу понять противоречивые требования: instrumental cluster важен, но мы его хотим засунуть под гипервизор с целью...? С целью сэкономить 5 баксов?

                0
                instrumental cluster важен, но не на столько чтобы его «крутить» на отдельной железяке. Тем более что эта железяка должна быть на linux, чтобы UI отображать. И получается что для приборной панели 2 отдельных полноценных компа — один с linux и один с android. И оба не особо нагруженны и активно общаются между собой. Логично сделать одну железяку. Но могу сказать, что это пока state of art решения :) Большинство ставит 2 железяки.
                Но все это никак не касается управления автомобилем — эта часть изолированна от всех информационных компонент и работает на микроконтроллерах без операционки.
                И да — цель это экономия. Но не 5$ — это специально сделанные платы в усиленных корпусах с специфичными автомобильными шинами и стоят несколько сотен баксов. Плюс упрощение общей архитектры внутри авто.
                  0

                  Просто взгляните на приборные панели современных авто — большущий TFT дисплей, рисующий стрелки, карты, машинки и т.д.
                  Все понимают, что мобильные платформы, типа iOS/Android — это идеальные средства для данного применения — плавная графика, наличие огромного количества графических библиотек и главное — разработчиков. Но есть одна серьезная проблема — эти системы любят падать. И если в телефоне упавшее приложение просто перезапускается одним тыком, то в автомобиле так нельзя. А системы, заточенные на safety имеют совершенно другую архитектуру. Графики на них почти нет, а разработчиков днем с огнем не найти.
                  Вот и мучаются они, надеясь с помощью гипервизоров сделать костыли.


                  ПС я просто у себя дома веду эксперимент — планшет на стенке на Андроиде в режиме 365/7/24. Там запущено всего одно приложение для управления умным домом — десяток кнопок и несколько показателей — температура, иконки света. Все остальное отключено — автоматические обновления, выход в интернет закрыт( ручной IP без шлюза), и все равно раз в шесть месяцев он теряет Wi-Fi, а приложение падает немного чаще. Из-за этого поставил автоперезапускалку, которая должна его мониторить, но она… тоже периодически падает! Вот вам такой андроид.

              0

              Может кому-то будет интересно, но прямо сейчас я участвую в Google Summer of Code c проектом Xen on Beagleboard-x15, а тут можно отслеживать прогресс. Если у кого-то есть большой опыт c omap am572x и желание помочь, то добро пожаловать в обсуждения (лист рассылки xen-devel или irq: #beagle-gsoc на freenode).

                0
                на порядок — это в 10 раз…
                  0
                  >..EPAM драйвит этот проект.
                  >… даем разработчикам connected services возможность деплоить
                  >Открытый гипервизор для автомобиля должен быть functional safety compliant.
                  > копроцессоры
                  Написано на Руглише.
                    0

                    IMHO "драйвит" и "копроцессоры" тоже стоило на English оставить :)

                    0
                    А процессоры именно этой архитектуры в основном используются в автопромышленности.

                    В инфотейнмент — может быть, но в реалтайм приложения ARM только пытается заскочить, а погоду делают PowerPC, TriCore и некоторые намного менее распространенные архитектуры.
                      0
                      Есть ещё открытые гипервизоры – Интеловский ACRN и Jailhouse Сименса. Это довольно новые разработки и они оба про безопасность в авто и промприменениях, включая поддержку интетеймент-приложений и ОС, если нужно.

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

                      Самое читаемое