Okay, that looks green.
Thanks a lot for the kind introduction.
That's actually good to know.
I didn't know that you were involved in all of this.
Yes, this is basically part of the story where this all comes from.
My name is Markus Hainel, and as you can see, I'm with CanConcept.
I was fighting a bit with myself.
What I'm going to talk here about because people said,
I'm so sorry we haven't heard so long about it and make a talk.
Tell us what's new.
And there's a lot of new things.
But still, since I can't tell everything, because I don't know everything.
I tried to limit myself to the stuff I work on a daily basis.
And part of that is the safety and security.
And I'm trying to touch on some other points that are new in L.F.R.E.land as well.
That was new.
There have been a lot of new developments since then.
I'm trying to pick some that might be of interest to everyone.
So we have now a risk drive support in L.F.R.E.
I think that was released last year or the year before,
including the hypervisor extensions.
There is also now, I think, Adam, there's hardware, right?
Recently, so finally you can also use it.
We've had it before, but only with the emulation stuff.
But now you can also use it.
We have the micro hypervisor, which actually is bringing this whole thing that you know as L.F.R.E.
as the micro kernel, with all of the abstractions, with all of the features.
To the cortex R world.
So it's not the cortex M's.
It just talked about, but the cortex R is basically the same problem.
They don't have an MMU.
They have an MPU and reported this to the system.
We did quite a lot of work on extending the variety of support in our system.
So UVM M is our virtual machine monitor, and we have a lot of work going into this.
This is one of the main things that is a selling point for a micro kernel based hypervisor and operating system.
That you have these abstract interfaces that you can tell your users.
Well, it doesn't matter what your hardware is.
You have your system developed against the virtual interface, and everything's nice.
Which is the hardware vendor that all stays the same for you, wherever that's possible.
So one of the things we recently internally demoed is that we have a virtual GPU demo running,
where you have two instances.
For example, Android and Linux running in parallel and sharing the GPU, which is really nice demo.
When you can see a theory showing an Android and Linux and one of them runs Angry Birds,
which is always the demo you do.
The other news is that we are on quite a few new system platforms.
It doesn't really matter to name them.
There's an IMX95. There's the ARCURS from Renezas. There's the NXP hardware.
All of this kind of ties into this automotive story, right?
Because that's one of our major customers as a company.
But for our E, it's also since last year, or even three years ago, we run on ARM system ready platforms.
So if you have something like a graviton, if you have an ARM Neoverse, like an Adlink system,
you can just boot it and it runs. It's an ARM 64-UFU platform, and we have support for this now.
Which is pretty amazing, I think.
When it comes to the other part, it's all about how can we make others believe us that our system is safe and secure, right?
It's not just about building a safe and secure system in security certified systems for a long time.
The first product that was actually certified by a customer of ours with L-4E was certified for Schlüssel.
Not more for the Indians, so it's the lowest ranking in German confidentiality in 2013.
So we worked with a customer to get this system certified.
This continued in 2017 with having a geheim, this is the second level.
So it's kind of like secret, but you're not allowed to translate it. It's geheim.
So we got this certification in 2017, or better a customer product that is.
The story was always about this, you get a certification for an appliance, so you build a box, you put it somewhere, and this gets a certification.
And if you build a new box, you need a new certification.
Since we had a lot of cases in queries into getting this done in 2024, we finalized something that our namely that we got operating system on its own.
Accredited to be to be geheim certified.
Oh, it's called geheim accredited.
And this means that it's the only operating system out there, and it's open source that you can actually use in a geheim context for the German government, for example.
The other thing is that last year we got these two certifications.
The night thing is with the ASL certification.
This is the automotive safety certification, so it's called ASLB, because it's an intermediate certification which makes sense for the types of systems.
This is to be used on.
You kind of get a little two certification for free, which is the industrial safety certification.
And as I said, the EL for plastic certification is imminent.
We're still waiting for the final, okay, but all the documents have been handed in and barring any further requests.
We should get it soon.
So now this is kind of my, have been my day-to-day business in the last five years.
And then they go ahead and tell you, you need to test this, and you tell them, but it's unreachable on this platform.
This is really hard to get into the mindset of the people that you have generic software that has actually generic code that sometimes doesn't matter on a specific platform.
And we did all of this, we certified this together with ElectroBit who did a huge sponsoring job on this and worked together with us as a safety element out of context, which means you can use FRIE, which from our component point of view is the kernel itself and the root picture.
You can use them in a safety context, and then you can build your system on top of it.
Let's do it like that.
And the nice thing is that all of this flew back into the open socials.
So we did a lot of processes looking into interfaces, or they were defined to they have unexpected behavior.
Not necessarily bugs, but stuff where the developer might imagine that something behaves differently than it does in reality.
And actually we found a few of those instances where you said, yeah, it's not a bug.
It doesn't break security, it doesn't break safety, but it's not obvious.
And if you don't know about this, you might actually write an application that in the end makes wrong assumptions about the system behavior, and that's cannot be safely used.
So these are things that really disproved forward, right?
It's a lot of documents, it's a lot of paper, but you also gain a lot from it.
Besides all of these document stuff, you have also this nice topic.
Static analyzes and compiler warnings.
So there are a few standards, and actually the ISO standard doesn't prescribe what you have to do.
You need to have some zane rulework of static analyzes and of checkers that you employ to make sure that this is all zane.
The standard way to do is to use a standard rule set.
Back when we started the project, the industry standard rules, that's where things like MISRAC++208 or the Autosaw rules.
They have a large set of rules, and a lot of them don't make a lot of sense for an operating system.
It's really hard because they tell you things to not do, which from a user length perspective is totally zane.
You shouldn't do the zane and change the cost of changing a rule would be higher than keeping the code as it is.
For example, when somebody tells you to change all of your types in your code and all of the comparisons or whatever,
the risk that you introduce errors is just so much user than the gain that you get from this that you would usually not do this.
So you would follow an approach where you say, okay, for new code, we try to adhere to this.
For existing code, we keep it as the certification agencies usually accept this if it's very recent, right?
Because we tried for some of the MISRA rules to implement them, and if you just go through it and do a lengthed like a second replace of stuff that MISRA thinks it's not okay, you will introduce bugs.
We had cases like this.
We have all of this warning free. I think for most of us those projects or for many of them, this actually comes as a given right.
Usually people don't write code that has warnings. Neither do we.
We enable all of these standard warnings and a bit more.
Some of these are actually also basically just showing stuff that MISRA implement, right?
Things that the compiler can check easily.
Nice anecdotes about static analyzers can be found a lot.
Because there are a large number of solutions on the market and they are usually quite good for the demo cases.
The thing is that many of those are tailored towards small embedded projects, right?
Where you have 20 C files and compile them together into one single binary and then you have this and that's it.
And it gets challenging when you want to check a whole operating system.
You have libraries that are shared between components where you have to justify arrows in the checker and need to tell this is wrong.
And now you need to tell it for every program that uses this library because the tool actually doesn't support you with this.
There's a lot of this stuff.
We had a lot of cases where we actually found in testing on other cases things where we thought this should have been found by a static analyzer.
A null pointer check that was missing.
And the static analyzer could have told us and it actually didn't turn out anything right.
So our experience is static analyzers can be useful to find issues and we did find a few.
If we compare this to the incredible amount of white list entries we had to do.
Where we had to tell the analyzer know this is actually correct code, this is fine.
The effort would have been better spent in more testing or reviewing the code but that's the way it is.
There are also rules that are that are really hard to implement in general that don't make a lot of sense and sometimes the static analyzer actually don't implement them correctly.
So we just got to sometimes as a statement yes it's broken with quality managed and safety applications next to each other.
And for the safety components you needed a lot more.
So we also needed to specify requirements so it's not enough to say you have these interfaces and the code implements the interfaces.
You need to be traceable what part of the code implements what part of your system for what reason and especially this what reason is reflected into the requirements.
So you have things like I need to be able to share memory between applications or to to so high level requirements I need to be able to communicate between applications.
So you break that down and you need an IPC gate and our system design and then you break that down you need to be able to bind to the IPC gate you need to be able to call it and so on and then you break that down again.
So this is quite a lot the high level stuff was about a hundred requirements the lower level ones 525 all of this is linked to the source code all of it is linked to tests so each requirement needs a test.
And as you can see in the last bullet point we wrote about a hundred tests so this is really the code 100 code blocks that are test we used to get as a framework and this this boils down to about 7000 test instances that we run every time we change anything in the system to make sure that it still works.
It's about a hundred thirty thousand lines of test code and total about half of these tests are kernel unit tests so they they really need to test the kernel internally.
The reason for this basically comes up on the next slide and this is kind of a hard requirement we always try it if we kind of avoid it we can't.
Turns out on you need coverage and while the ISO standard doesn't say you need a hundred percent coverage.
The third of fire says well if you don't have a hundred you need to go with a good reason by the remaining part it's not violating user safety guarantees and.
This basically means you need a hundred plus white lists and white lists need to be very spare you sparsely used because otherwise people won't believe you that this is really really safe.
So all of these tests and all of these requirements were done to get the kernel to a hundred percent code coverage on the platform that was the target for the customers this was the.
S32G in this case and we actually got it done and there's a lot interesting anecdotes to be told about this as well coverage is hard.
We try to use open we have us on very smart people in the company that that actually made use of this so you can extract all of this information in the binary and you can then get information such as that this part.
Yes, it's in the coverage report and GCC would have also given you this but LVM also tells you that this is no longer in the final binary and this makes it believable that we don't need to cover it.
It's also extended the tooling and the HTML generation with all on white listing because that's the thing I mentioned before right you need to rationalize everything that you don't cover so for example if we have this generic iq manager implementation and we say okay on this platform you always have.
And and iq chip right then then it doesn't make sense to have this check so we wait the right list entry in total that was 314 white list entries which which I think for for a total of.
13,000 lines of code it's quite it's quite okay right it's blocks it could be large blocks but it usually isn't right it's usually three lines four lines five lines and we needed to optimize the code for the generation for this.
The nice thing is that our customer actually uses this so we had now have a safe hypervisor and they use this to make Linux safe because my argument would be if you don't need to do this for all for this for Linux.
You might get it done if you throw enough people at it but unless you get the Linux developers to follow a process that keeps this in zoom.
You will be lost it moves too fast you cannot follow up with all of these artifacts you need some other way to ensure the safety of a Linux application.
And our customers or electro bit actually uses this to build something called safe Linux.
Or eb corpus linux for safety it's called they basically use the hypervisor that safety certified and our virtual machine monitor and introspect the Linux to make sure that if there's any safety violation in a Linux safety application happening.
That you can trigger a handler that can actually handle this problem and for SLB that's actually enough so you get all of the benefits of having having safety into Linux by just certifying the hypervisor which is a nice thing.
And in principle all of this anyone could do using just the system that's out there on GitHub.
Okay I'm nearly over time already so the micro hypervisor thing I have to left I promise to tell a bit about this.
It's basically the thing Edward said we reported this to the Cortex R platform basically means no MMUs we use MPUs to protect applications we have.
We remove some because these platforms are very stringent memory requirements so we did a lot of work in optimizing this whole system.
And all of this makes this makes this very flexible so let's give this you can good slide later on what's under horizon usability is one of the main topics we now have native FRE cross tool chains they have been.
They are being worked on and will be published soon which means you can just have a cross compiler that just like you would call F the gcc minus min gv you can have an FRE.
And we have a rast cross compiler that's out now we have adequate support under horizon etc.
The challenges are keeping the certification alive and even though we have contributors that are not interested in safety.
And if anybody has good ideas how this can be done we are currently working on our own internal processes but we would value any feedback from the community that might want to contribute to a system how they see this.
We obviously want developers to write requirements and documentation and test to the last degree for every aspect they contribute.
And that's it for now. Sorry.
Thank you.