On 21.07.20 16:33, [email protected] wrote:
I have been reluctant to ask this question for quite a while, especially
from third perspective security, which actually goes hand-in-hand with
the second.
Jan schrieb am Montag, 20. Juli 2020 um 23:27:54 UTC+2:
On 20.07.20 09:57, Rick Xu wrote:
> For 3 reasons, first, it uses a LINUX as a host OS and then
changes it
> to a guest OS, so a running host OS was saved.
> Second, less virtualization and more real-time.
> Third, it's easy to use.
> [..]
> And if it has not been used for products, why?
From my last months' view of setting up an academical use-case of a
mixed criticality/mixed security-level system, from the perspective of
an application-oriented engineer, I would not agree on the term 'easy'.
I have also setup my use-case using other hypervisors, which I would
consider 'easier', but I hit other barriers. Though, everything has pros
and cons and I may be comparing apples with chocolate cheesecake, not
blaming anyone.
It is really cool to see the improved features and the HW support
growing on ARM systems. At this point, I find Jailhouse being quite
tightly interwoven with its underlying HW, in other words, without
excellent knowledge of the HW, setting up JH is really hard.
If I had only one wish, it would be improving the documentation for
Jailhouse integrators.
I don't disagree. I think NXP and TI did some work in the context of
their SDKs, though even that is limited when a customer actually wants
to map that on a concrete product design. And general bits of
information are better shared in the central project. Contributions
welcome (TM)!
Jailhouse is primarily useful in two application areas. [...]
The second, still more research-like area is functional safety. This is
our (Siemens) primary focus with Jailhouse. And while we are still
waiting for and even collaborating on developing [3] a certifiable [...]
The Selene Project sounds interesting, all the best with that!
I am/was working on a project on mixed-criticality security
certification and certifiable HW really is still a blind spot. (what
about, "we just _trust_ Intel processors to do the right thing"?!)
Would you enjoy riding a train where the signalling system was built
with blind trust? Don't worry, you won't because the authorities would
not allow us to release such trains onto the track.
I believe, in the not so far future a good portion of mixed-criticality
systems will also require security certification (to prove integrity of
the safety function). Nothing can function in a void. Any (modern)
critical functionality requires some sort of networking / data exchange
and it is quite wise to split that off into different cells, so there
are different certification levels - both in terms of safety (thorough,
long-term) and of security (quick update/patches). Jailhouse really
shows how much we trust in the underlying HW for these separation
guarantees.
Exactly our concerns. So even if you make it "simpler" by not using
hardware virtualization (with its arch and SoC specialties), you will
end up trying to certify a "simple" OS that does the partitioning for
the different functions with "standard" OS/process isolation means.
And... you will still hit almost the same questions about complex
multicore hardware, how to ensure it does what needs to do for the OS in
that case. Plus you may end up with a way more complex partitioning
layer, way closer to Linux than to Jailhouse.
There are evolving security standards like ISO62443, or, e.g., its
derivative EN 50701 for railway. However, from my current understanding
Jailhouse is still too "low-level" and would require more tooling and
documentation to enable "easy" product certification. And this could
become a professional/commercial service beyond the open-source
initiative or requires additional forces in the product development.
Definitely. We went with a plan for many of those todos /wrt safety to
TÜV a couple of years ago, at a time where we were still hoping for a
breakthrough on the hardware front. It would be quite a bit of work, but
it is more or less clear that this would be feasible (was also the
inofficial feedback from the authorities back then), and that also
economically. Still, more homework would be needed to map results on a
concrete product.
BTW, https://cip-project.org is looking into 62443 compliance for a
small Linux base system. I'm not directly involved on that topic but on
the project in general, and I can confirm from that level that concrete
topics so far are different from what is bothering us /wrt safety
certifications.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/53766782-fbb9-d91f-592d-bc932955bafa%40siemens.com.
