Next speaker is Tom Van Eyck, who is actually also from the same department that you and
me are from.
And he will, I think, be the only speaker that talks a little bit about our trust zone,
so take it ahead.
Yeah, so I'm Tom.
I'm a first year PhD student at the KU Leuven, and I'll be talking about the research we
have done in the last year, year and a half.
So to sketch a bit of context, we are researching on cyber-physical systems.
Cyber-physical systems are systems that interact with the real world, for example, air compressor's
robotic arms.
These systems have a controller with safety-critical applications.
However, in the recent years, the industry is moving to including a Commodity OS-like
Linux to facilitate software updates and third-party applications for monitoring of the cyber-physical
systems.
However, as you can imagine, to keep the safety-critical applications safe, you have to put this on
a separate processor so that the Commodity OS may not influence it, but this becomes
very expensive.
So what industry wants to do is that they want to integrate both these things on a single
processor.
So that's basically the requirement that the industry has at this point, but a few problems
result from it.
The first is, I think, the most obvious.
Whenever there's a bug in the Commodity OS or an attacker, they can influence the execution
of the safety-critical applications, which means that the safety-critical applications
cannot be guaranteed to have their availability, so the safety aspect is completely lost, which
is not acceptable for these cyber-physical systems.
The second issue that arises is that these safety-critical applications have real-time
execution requirements, although there is some support in Linux.
For real-time execution, this is mostly not what industry is looking for, so they want
to have a real low latency real-time execution scheduler as well.
And the third issue that arises is that industry also wants to share the peripherals between
the safety-critical applications and the Commodity OS, because these monitoring applications
should be able to read out the peripherals, however, industry doesn't want them to be
able to disable the peripherals, because then, again, availability isn't guaranteed.
For example, if the train wants to break and the peripheral for the brakes is disabled,
no brake can be pressed, this is quite an issue.
So out of this, our research question was formed, can we ensure availability for safety-critical
applications while running a Commodity OS on the same system with little developer impact?
And to repeat, we need isolation of the critical applications, we need real-time execution of
these critical applications, and we also need a transparent sharing system for the peripherals.
As an aside, the threat model that we assumed was that there is a strong remote adversary
with root privileges in the Commodity OS, they want to launch a denial of service attack
on the complete system, and we assume that the hardware, critical applications and peripherals
are trusted and everything else is not.
So jumping into our first requirement, to isolate the critical applications, we chose
to use ARM Trust Zone, because it's integrated in high-end, low-end devices, embedded devices
as well, and it has existed for quite some time, so the chance that the industry already
has a processor deployed with ARM Trust Zone on it is quite high.
So ARM Trust Zone is actually just hardware-based isolation, it creates two worlds, as you can
see the normal world on the left and the secure world on the right, it does this by defining
two security states with their own address spaces.
In that way, we can ensure confidentiality and integrity for code and data in the secure
world, because the hardware blocks any access to these address spaces of the secure world
coming from the normal world.
We use OPTE, which is an open-source TE implementation of ARM Trust Zone, and it works together with
Linux in the normal world.
So architecture, you can see again the normal world on the left and the secure world on
the right.
All the great boxes are the boxes that were already there in OPTEOS and Linux, but the
white boxes we added.
So for requirement one, of course, is ARM Trust Zone.
Requirement two, we added a secure scheduler and a secure interrupt.
For requirement three, we added a driver in the normal world and a secure driver in the
secure world, and then we also have developed a use case where we monitor the Linux kernel,
and that's also in the secure world, but I'll talk about that later.
So for the real-time scheduler, so for the real-time execution requirements, we basically
need two things.
We need a periodic interrupt, and we need a scheduling system.
For this periodic interrupt, we use a hardware timer on the board.
It's very simple.
We set the interrupt to be the highest priority of the complete system, and we protect it
from the normal world so that the normal world cannot disable it or reconfigure it.
So when an interrupt is triggered by this hardware timer, it gets caught by OPTEOS.
OPTEOS checks if it's a scheduling interrupt.
If so, it passes on execution to Friartos, which is a well-known, relatively small real-time
operating system, which supports task prioritization and preemption, which is very useful for industry.
So whenever Friartos gets control, it will schedule its tasks, and after all tasks have
executed, control will be given back to OPTEOS so that the system can function as normally.
And then for requirement three, we have a – so this is obviously the normal way that
an application on the user level would interact with hardware peripherals.
However, these peripherals need to be in a secure world, so we also need to move part
of the driver into the secure world.
So this is called driver splitting often.
We basically introduce a secure driver in the secure world at kernel level, which is
the liaison between the normal world and the peripheral.
So this secure driver then to keep the developer efforts minimal should not contain a lot.
In fact, very little.
Only hardware accesses can be put in a secure driver, but you can also put some security
policies in there.
So for example, if a user application in a normal world wants to read something, it
will get allowed.
But if it isn't allowed, for example, to disable the peripheral, the secure driver
is able to just stop the request and nothing will happen.
The secure driver may also include some logic to share the access between the normal and
the secure world.
For example, if you have a screen as a peripheral, the secure world's content of the screen
will always be displayed on top of the normal world content.
And the nice thing about creating such a system is indeed only the developers of the driver
at the kernel level in the normal world need to care about any changes made to the system.
As far as the user level applications know, nothing has changed, which is very useful
for industry as well.
Of course, you need read and write access, and this is given by a set of APIs included
in OptiOS called the global platform APIs.
These are a standardized set of function calls to facilitate calling into the secure world,
providing data and getting data back.
We've measured this to take on average 123 microseconds, which is plenty fast enough
for industry.
But of course, secure peripherals might also want to return an interrupt, might trigger
an interrupt, and this interrupt must also be returned at some point to the normal world.
So for this, we developed a notifier system that consists of two parts, one in the normal
world, one in the secure world.
So what happens is that if an interrupt is triggered at the peripheral, it will get forwarded
to the secure world notifier by the secure driver.
Then the secure world notifier will trigger an interrupt in the normal world, which will
be caught by the normal world notifier, and this will forward it to any driver in the
normal world that wants to know if such an interrupt has happened using a published
subscribe system.
So now we solved all the three requirements, but then we got on to thinking, what can we
do with this?
So we developed a use case where we tried to monitor the Linux kernel running state
if it has crashed or not.
So we adopted a very simple system to do this.
We basically challenged the Linux kernel using a notification from the system we just built,
and we expect the response back in a certain time frame.
If we got the response back, Linux is alive, otherwise it's not.
It's as simple as that.
The things that we can do with this is however more interesting.
Whenever Linux doesn't respond in time and we know it's dead, we can, from the secure
world, we can dump the kernel state, normal world memory, and we can even reboot Linux
kernel while still keeping the safety critical applications running.
So we did that.
It will show a demo where we reboot Linux.
So whenever the monitor in the secure world notices that Linux kernel is dead.
So first, to go back a bit, first we store the kernel image at boot time because then
we know that Linux is in a good state and it's up and running because we need access
to the normal world file system.
So we get the image, we store it in the secure world, we protect it from normal world memory
so that no access from normal world is possible anymore.
So then when Linux crashes, we notice this.
We disable all the cores because we are on a multi-core system.
We disable all the cores except for our own.
We write the image back again to the normal world and then we just jump to the kernel
start address.
I left some tricky things out because OptiOS needs to do some resetting of its own systems
as well but that's not that important.
So I have a demo that basically demonstrates this.
So again on the left, if you can see it clearly, we have the normal world, isn't very important
what you can see there.
The most important thing is on the right in the secure world.
You can see on the top that that's the output that the monitor is giving every 500 milliseconds.
So every 500 milliseconds it's selling a challenge to Linux and getting a response back.
If it's a response, it's obviously green.
So now if we go into Linux and we make or we cause a crash in the system.
Very simple crash kernel panic.
We immediately see that the monitor notices this.
It will start rebooting process and keep in mind that the secure world is still executing
its task in a real-time fashion with a given known latency.
And after Linux has rebooted, we again see that the monitor notices Linux is alive.
And if after we wait a bit, we get again a shell which we can use like any other Linux
system.
Yeah, the demo.
Thank you.
So then to conclude, again, a research question.
Can we ensure availability for safety-critical applications while running a commodity-OS
on the same system with little developer impact?
We do believe so.
We did this by leveraging threshold isolation to isolate the critical applications.
We introduced a secure scheduling system with freeRTOS.
And we introduced also a transparent peripheral sharing system.
We have some documentation online.
I put it as a tutorial, but you need this board to be able to run it.
So it's still ongoing research.
And we will update this tutorial whenever we update, we get new stuff in our research.
You can also look at the documentation for Opti as well.
And if you have any questions at any time, just contact me at this email address.
I'd be happy to answer them.
So that was it.
I hope you enjoyed the presentation.
And if you have questions.
Yeah.
So one of the problems I see with this approach is that you move the device to the secure
world.
They basically have a seam layer to make the cabinet talk to the device you move to the
secure world.
The problem is, we've been discussing this for a while, but the problem is you expose
a bigger back surface in both the, which is the drivers, basically breaking the main assumption
in opting that we don't trust Linus, right?
So you have a buffer that fits into your driver and you kind of start to trust that buffer
because it ends up being hardware, so there needs to be some kind of arbitration or rationalization
process during that thing.
And how do you thought about this?
Yeah, of course.
It was indeed that if you move a driver into the secure world, we increase the attack surface
considerably, of course, and we solved this, or we thought about it indeed, and we came
to the conclusion that it is indeed a problem.
However, if you get secure policies, which you know in advance, so for example, we know
that a peripheral can be read only by the normal world, but not written because of course
you designed a system like so.
You can see, based on the actual requests that are sent by the normal world, if it is
allowed or not.
So if it's, for example, a write request to an address, we know we cannot allow this.
However, if it's a read address, we know we can just execute it and return the data.
We have a hardware vendor who will just listen and have a hardware that responds to do memory
address cases and you should be fine.
Yeah, but that's not the case, sadly enough.
The thing is that there's an RFC that we haven't been able to reason about it, which
we don't have a watchbook like you have an object that we do have is that we, once the
camera comes up, we measure portions of the text area of the camera.
We take a text and then we periodically randomly check if that hasn't taken.
Now, arguably, that's not a very strong attack against recent, you know, rocks and stuff
like that, but you should check that out at some point.
Yeah, we are considering this for other research projects that we are running at the same time.
It's a question that keeps coming back.
How do we authenticate the normal world or the Linux kernel to the secure world?
How do we make sure that it is running correctly?
Because the kernel, when it comes up, we basically change the bounce of the muscle code.
Yeah, indeed.
Yeah.
After some point, in this case, it's arguably trust what happens.
Yeah, indeed.
And there is some research going into attestation, so not remote attestation but locally.
And also some continuous attestation, but it's still an Linux kernel, which is very difficult to attestate.
The last thing is the kernel itself, right?
So when you write it to memory and then reboot it, you need to have some kind of cryptographic
set, right?
Because the trending in the whole chain of trust is, you know, you boot with the effect
that verifies your kernel and then you outestate it.
But if you load the kernel and down to an entry point, first of all, you need to cryptographic
verify what you're doing.
Yeah, of course, yeah.
And there's been some code and development going into EFI where if you down to the kernel
entry point and not the EFI entry point, you use a bunch of security services.
For example, ASL app.
Yeah, of course.
So this was a proof of concept indeed.
If you just write the kernel image back to the normal world and jump to it, it's of course
a big problem.
So if you want to actually build such a system in a secure way, you will need to do checking
your image at boot time when you store it in memory.
Once you've checked it and stored it, you know that it's safe and then whenever you want
to reboot, you can set up the normal world completely so that it is again in a well-known
secure state like at boot time and then write the image.
We can talk.
Of course, yeah.
There's more problems, right?
Because for example, if you boot like that, ASLR won't work properly in our, at least in
our system.
Okay.
Okay, we'll have a good discussion.
Yeah.
Yeah, go ahead.
Maybe a follow-up question to this initial observation about the sort of security aspects
of kind of sharing responsibility for the peripherals.
Another reason why you would want to partition the peripherals rather than to give control
competes with trust is also performance, right?
Because essentially now you're saying that for any peripheral access, you need that to
go through the...
Yeah, so there is...
There is some latency number, but did you evaluate the overall performance degradation
on the Linux?
Yes, indeed we did.
I did not include the slide.
Ah, yeah.
So the question was, if we evaluated the complete latency of sharing peripherals between the
two worlds, yeah, we did indeed verify, don't have a slide for the graphs, but if you look
at these numbers, you can see that to go to the peripheral from the normal world, it takes
around 103 microseconds.
This is however in a standard call in OptiOS, and there is also something like a fast call
and then you will get six microsecond latency, which is very fast, certainly fast enough
for the requirements set by our industrial partners.
And also the 68 microseconds to go back is also quickly enough for these systems, because
these systems often have a control loop of one millisecond.
So that means that, yeah, even with these numbers, you have like 95 or above of the original
performance or time of execution in the normal world.
So this is, we think this is a cost that we can totally take in developing the systems
just because it gives us so many benefits on security level.
Is that good?
Okay.
Yeah.
So the question was, how does this system using a trusted execution environment compare
to a hypervisor implementation?
At our research group in this synod, we are working with very low-end embedded devices.
So this is a proof of concept on quite a high processor, it would be possible to do it in
a hypervisor.
I don't know how to do it because I haven't taken a look at it that closely, but on these
very low-end embedded devices, it's mostly not useful or it's even damaging for the lifetime
of device to use a hypervisor because you have also quite some overhead and a very limited
lifetime battery.
You have a very limited energy budget.
So on these lower-end processes, there is an arm trust on implementation that is also
very energy efficient.
So if we would, of course, not use Opti-Res and Linux, but take the same principles and
apply it to such a chip, we believe we could stay in the energy budget that these low-end
devices have.
And we don't think it's something we can immediately do with hypervisors, but of course, that's
not my research area, so that's something that can, of course, be very interesting to
research.
There was a question in the back.
Is there an instance of this hardware that we can use on the cloud to try it out?
I'm afraid not, so there is no instance in the cloud that is available to try right now.
However, there is, I don't know if you know QEMU, possibly you do, so QEMU.
It does support ARM virtualization.
So we actually first started using that to develop our system, but we very quickly moved
on to a hardware device because of our industrial partners.
So the code, as is, won't immediately run on QEMU, but if you change the interrupt
numbers and the things that are different, it should be relatively easy to reproduce
the same results on a virtualized system as well.
Just to continue on the question on virtual machines versus OPE.
I think one key difference is that OPE is actually a real trusted execution environment
in the sense that compared to a virtual machine where the hypervisor would have access to
the address space of the protected application and through flow, with OPE, it doesn't.
Anything that runs on the unsecured world does not see that the physical address space
cannot access.
Well, I guess, for example, our question is like the Siemens software controllers, actually
the hypervisor is not Windows or Linux, it's the custom hypervisor, and that also has access
like proper.
So if it is an hypervisor that uses hardware virtualization, it does have access to the
address space of whatever VM is running on the machine.
If it's based on the ARM64's virtualization extension, it will have access to the address
space.
With OPE, the address space is only accessible to the secure world.
It's controlled by the secure monitor, which is running at a very privileged level, which
is more privileged than the hypervisor.
So the hypervisor does not get access to the secure application, whereas with an hypervisor,
the hypervisor could just mess with the nested page tables and do whatever it wants, access
to the secure peripheral database.
Maybe to kick in here then, I love this, so that's what the coffee break hours are like
before.
So please continue this discussion, but just for the general audience, would I have like
a 10-minute break now?
I won't call it a coffee break because there's not enough time to run downstairs, you wouldn't
come back up.
In 10 minutes, we will continue with the next talk, but exactly use it for these type of
one-to-one break and continue the discussion in the next 10 minutes.
One thing I wanted to pitch in.