Как стать автором
Обновить

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

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

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


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


Просто посмотрите сюда: 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 на моей магнитоле.

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

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


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

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

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

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

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


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

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

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

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

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

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