[00:00.000 --> 00:19.560]  Next speaker is Tom Van Eyck, who is actually also from the same department that you and
[00:19.560 --> 00:20.560]  me are from.
[00:20.560 --> 00:24.440]  And he will, I think, be the only speaker that talks a little bit about our trust zone,
[00:24.440 --> 00:25.440]  so take it ahead.
[00:25.440 --> 00:26.440]  Yeah, so I'm Tom.
[00:26.440 --> 00:32.640]  I'm a first year PhD student at the KU Leuven, and I'll be talking about the research we
[00:32.640 --> 00:36.280]  have done in the last year, year and a half.
[00:36.280 --> 00:41.360]  So to sketch a bit of context, we are researching on cyber-physical systems.
[00:41.360 --> 00:46.200]  Cyber-physical systems are systems that interact with the real world, for example, air compressor's
[00:46.200 --> 00:48.000]  robotic arms.
[00:48.000 --> 00:51.800]  These systems have a controller with safety-critical applications.
[00:51.800 --> 00:59.160]  However, in the recent years, the industry is moving to including a Commodity OS-like
[00:59.160 --> 01:06.480]  Linux to facilitate software updates and third-party applications for monitoring of the cyber-physical
[01:06.480 --> 01:07.480]  systems.
[01:07.480 --> 01:13.560]  However, as you can imagine, to keep the safety-critical applications safe, you have to put this on
[01:13.560 --> 01:18.040]  a separate processor so that the Commodity OS may not influence it, but this becomes
[01:18.040 --> 01:19.520]  very expensive.
[01:19.520 --> 01:23.800]  So what industry wants to do is that they want to integrate both these things on a single
[01:23.800 --> 01:24.800]  processor.
[01:24.800 --> 01:30.600]  So that's basically the requirement that the industry has at this point, but a few problems
[01:30.600 --> 01:32.160]  result from it.
[01:32.160 --> 01:34.240]  The first is, I think, the most obvious.
[01:34.240 --> 01:40.160]  Whenever there's a bug in the Commodity OS or an attacker, they can influence the execution
[01:40.160 --> 01:45.680]  of the safety-critical applications, which means that the safety-critical applications
[01:45.680 --> 01:51.040]  cannot be guaranteed to have their availability, so the safety aspect is completely lost, which
[01:51.040 --> 01:54.920]  is not acceptable for these cyber-physical systems.
[01:54.920 --> 01:59.640]  The second issue that arises is that these safety-critical applications have real-time
[01:59.640 --> 02:05.120]  execution requirements, although there is some support in Linux.
[02:05.120 --> 02:09.840]  For real-time execution, this is mostly not what industry is looking for, so they want
[02:09.840 --> 02:15.440]  to have a real low latency real-time execution scheduler as well.
[02:15.440 --> 02:21.320]  And the third issue that arises is that industry also wants to share the peripherals between
[02:21.320 --> 02:27.560]  the safety-critical applications and the Commodity OS, because these monitoring applications
[02:27.560 --> 02:32.440]  should be able to read out the peripherals, however, industry doesn't want them to be
[02:32.440 --> 02:38.680]  able to disable the peripherals, because then, again, availability isn't guaranteed.
[02:38.680 --> 02:43.040]  For example, if the train wants to break and the peripheral for the brakes is disabled,
[02:43.040 --> 02:46.680]  no brake can be pressed, this is quite an issue.
[02:46.680 --> 02:52.240]  So out of this, our research question was formed, can we ensure availability for safety-critical
[02:52.240 --> 02:57.360]  applications while running a Commodity OS on the same system with little developer impact?
[02:57.360 --> 03:03.120]  And to repeat, we need isolation of the critical applications, we need real-time execution of
[03:03.120 --> 03:10.520]  these critical applications, and we also need a transparent sharing system for the peripherals.
[03:10.520 --> 03:14.880]  As an aside, the threat model that we assumed was that there is a strong remote adversary
[03:14.880 --> 03:19.400]  with root privileges in the Commodity OS, they want to launch a denial of service attack
[03:19.400 --> 03:23.840]  on the complete system, and we assume that the hardware, critical applications and peripherals
[03:23.840 --> 03:28.200]  are trusted and everything else is not.
[03:28.200 --> 03:32.920]  So jumping into our first requirement, to isolate the critical applications, we chose
[03:32.920 --> 03:39.240]  to use ARM Trust Zone, because it's integrated in high-end, low-end devices, embedded devices
[03:39.240 --> 03:43.520]  as well, and it has existed for quite some time, so the chance that the industry already
[03:43.520 --> 03:48.080]  has a processor deployed with ARM Trust Zone on it is quite high.
[03:48.080 --> 03:54.000]  So ARM Trust Zone is actually just hardware-based isolation, it creates two worlds, as you can
[03:54.000 --> 03:57.880]  see the normal world on the left and the secure world on the right, it does this by defining
[03:57.880 --> 04:01.480]  two security states with their own address spaces.
[04:01.480 --> 04:06.000]  In that way, we can ensure confidentiality and integrity for code and data in the secure
[04:06.000 --> 04:11.960]  world, because the hardware blocks any access to these address spaces of the secure world
[04:11.960 --> 04:16.160]  coming from the normal world.
[04:16.160 --> 04:22.760]  We use OPTE, which is an open-source TE implementation of ARM Trust Zone, and it works together with
[04:22.760 --> 04:25.720]  Linux in the normal world.
[04:25.720 --> 04:30.040]  So architecture, you can see again the normal world on the left and the secure world on
[04:30.040 --> 04:31.320]  the right.
[04:31.320 --> 04:38.400]  All the great boxes are the boxes that were already there in OPTEOS and Linux, but the
[04:38.400 --> 04:40.120]  white boxes we added.
[04:40.120 --> 04:43.360]  So for requirement one, of course, is ARM Trust Zone.
[04:43.360 --> 04:46.880]  Requirement two, we added a secure scheduler and a secure interrupt.
[04:46.880 --> 04:51.720]  For requirement three, we added a driver in the normal world and a secure driver in the
[04:51.720 --> 04:58.560]  secure world, and then we also have developed a use case where we monitor the Linux kernel,
[04:58.560 --> 05:03.360]  and that's also in the secure world, but I'll talk about that later.
[05:03.360 --> 05:09.080]  So for the real-time scheduler, so for the real-time execution requirements, we basically
[05:09.080 --> 05:10.080]  need two things.
[05:10.080 --> 05:13.200]  We need a periodic interrupt, and we need a scheduling system.
[05:13.200 --> 05:16.560]  For this periodic interrupt, we use a hardware timer on the board.
[05:16.560 --> 05:17.560]  It's very simple.
[05:17.560 --> 05:21.120]  We set the interrupt to be the highest priority of the complete system, and we protect it
[05:21.120 --> 05:25.360]  from the normal world so that the normal world cannot disable it or reconfigure it.
[05:25.360 --> 05:30.520]  So when an interrupt is triggered by this hardware timer, it gets caught by OPTEOS.
[05:30.520 --> 05:33.880]  OPTEOS checks if it's a scheduling interrupt.
[05:33.880 --> 05:41.400]  If so, it passes on execution to Friartos, which is a well-known, relatively small real-time
[05:41.400 --> 05:49.120]  operating system, which supports task prioritization and preemption, which is very useful for industry.
[05:49.120 --> 05:54.640]  So whenever Friartos gets control, it will schedule its tasks, and after all tasks have
[05:54.640 --> 06:02.400]  executed, control will be given back to OPTEOS so that the system can function as normally.
[06:02.400 --> 06:08.240]  And then for requirement three, we have a – so this is obviously the normal way that
[06:08.240 --> 06:11.640]  an application on the user level would interact with hardware peripherals.
[06:11.640 --> 06:16.520]  However, these peripherals need to be in a secure world, so we also need to move part
[06:16.520 --> 06:18.240]  of the driver into the secure world.
[06:18.240 --> 06:21.680]  So this is called driver splitting often.
[06:21.680 --> 06:27.200]  We basically introduce a secure driver in the secure world at kernel level, which is
[06:27.200 --> 06:31.080]  the liaison between the normal world and the peripheral.
[06:31.080 --> 06:40.240]  So this secure driver then to keep the developer efforts minimal should not contain a lot.
[06:40.240 --> 06:41.480]  In fact, very little.
[06:41.480 --> 06:46.280]  Only hardware accesses can be put in a secure driver, but you can also put some security
[06:46.280 --> 06:47.880]  policies in there.
[06:47.880 --> 06:52.000]  So for example, if a user application in a normal world wants to read something, it
[06:52.000 --> 06:53.000]  will get allowed.
[06:53.000 --> 06:58.360]  But if it isn't allowed, for example, to disable the peripheral, the secure driver
[06:58.360 --> 07:03.880]  is able to just stop the request and nothing will happen.
[07:03.880 --> 07:10.440]  The secure driver may also include some logic to share the access between the normal and
[07:10.440 --> 07:11.440]  the secure world.
[07:11.440 --> 07:16.400]  For example, if you have a screen as a peripheral, the secure world's content of the screen
[07:16.400 --> 07:20.320]  will always be displayed on top of the normal world content.
[07:20.320 --> 07:26.400]  And the nice thing about creating such a system is indeed only the developers of the driver
[07:26.400 --> 07:30.320]  at the kernel level in the normal world need to care about any changes made to the system.
[07:30.320 --> 07:34.280]  As far as the user level applications know, nothing has changed, which is very useful
[07:34.280 --> 07:37.160]  for industry as well.
[07:37.160 --> 07:42.240]  Of course, you need read and write access, and this is given by a set of APIs included
[07:42.240 --> 07:45.520]  in OptiOS called the global platform APIs.
[07:45.520 --> 07:53.160]  These are a standardized set of function calls to facilitate calling into the secure world,
[07:53.160 --> 07:55.080]  providing data and getting data back.
[07:55.080 --> 08:00.760]  We've measured this to take on average 123 microseconds, which is plenty fast enough
[08:00.760 --> 08:02.360]  for industry.
[08:02.360 --> 08:06.680]  But of course, secure peripherals might also want to return an interrupt, might trigger
[08:06.680 --> 08:11.360]  an interrupt, and this interrupt must also be returned at some point to the normal world.
[08:11.360 --> 08:16.160]  So for this, we developed a notifier system that consists of two parts, one in the normal
[08:16.160 --> 08:18.160]  world, one in the secure world.
[08:18.160 --> 08:23.240]  So what happens is that if an interrupt is triggered at the peripheral, it will get forwarded
[08:23.240 --> 08:26.160]  to the secure world notifier by the secure driver.
[08:26.160 --> 08:29.760]  Then the secure world notifier will trigger an interrupt in the normal world, which will
[08:29.760 --> 08:34.680]  be caught by the normal world notifier, and this will forward it to any driver in the
[08:34.680 --> 08:38.280]  normal world that wants to know if such an interrupt has happened using a published
[08:38.280 --> 08:41.920]  subscribe system.
[08:41.920 --> 08:47.680]  So now we solved all the three requirements, but then we got on to thinking, what can we
[08:47.680 --> 08:48.680]  do with this?
[08:48.680 --> 08:52.880]  So we developed a use case where we tried to monitor the Linux kernel running state
[08:52.880 --> 08:54.920]  if it has crashed or not.
[08:54.920 --> 08:58.040]  So we adopted a very simple system to do this.
[08:58.040 --> 09:03.320]  We basically challenged the Linux kernel using a notification from the system we just built,
[09:03.320 --> 09:06.920]  and we expect the response back in a certain time frame.
[09:06.920 --> 09:09.800]  If we got the response back, Linux is alive, otherwise it's not.
[09:09.800 --> 09:13.080]  It's as simple as that.
[09:13.080 --> 09:18.200]  The things that we can do with this is however more interesting.
[09:18.200 --> 09:23.440]  Whenever Linux doesn't respond in time and we know it's dead, we can, from the secure
[09:23.440 --> 09:30.320]  world, we can dump the kernel state, normal world memory, and we can even reboot Linux
[09:30.320 --> 09:35.920]  kernel while still keeping the safety critical applications running.
[09:35.920 --> 09:36.920]  So we did that.
[09:36.920 --> 09:39.560]  It will show a demo where we reboot Linux.
[09:39.560 --> 09:44.880]  So whenever the monitor in the secure world notices that Linux kernel is dead.
[09:44.880 --> 09:50.680]  So first, to go back a bit, first we store the kernel image at boot time because then
[09:50.680 --> 09:54.480]  we know that Linux is in a good state and it's up and running because we need access
[09:54.480 --> 09:55.880]  to the normal world file system.
[09:55.880 --> 09:59.600]  So we get the image, we store it in the secure world, we protect it from normal world memory
[09:59.600 --> 10:04.680]  so that no access from normal world is possible anymore.
[10:04.680 --> 10:07.080]  So then when Linux crashes, we notice this.
[10:07.080 --> 10:12.280]  We disable all the cores because we are on a multi-core system.
[10:12.280 --> 10:15.000]  We disable all the cores except for our own.
[10:15.000 --> 10:19.800]  We write the image back again to the normal world and then we just jump to the kernel
[10:19.800 --> 10:20.880]  start address.
[10:20.880 --> 10:26.960]  I left some tricky things out because OptiOS needs to do some resetting of its own systems
[10:26.960 --> 10:30.040]  as well but that's not that important.
[10:30.040 --> 10:33.520]  So I have a demo that basically demonstrates this.
[10:33.520 --> 10:38.200]  So again on the left, if you can see it clearly, we have the normal world, isn't very important
[10:38.200 --> 10:39.200]  what you can see there.
[10:39.200 --> 10:41.640]  The most important thing is on the right in the secure world.
[10:41.640 --> 10:47.600]  You can see on the top that that's the output that the monitor is giving every 500 milliseconds.
[10:47.600 --> 10:51.880]  So every 500 milliseconds it's selling a challenge to Linux and getting a response back.
[10:51.880 --> 10:54.560]  If it's a response, it's obviously green.
[10:54.560 --> 11:03.200]  So now if we go into Linux and we make or we cause a crash in the system.
[11:03.200 --> 11:05.320]  Very simple crash kernel panic.
[11:05.320 --> 11:08.280]  We immediately see that the monitor notices this.
[11:08.280 --> 11:14.000]  It will start rebooting process and keep in mind that the secure world is still executing
[11:14.000 --> 11:18.080]  its task in a real-time fashion with a given known latency.
[11:18.080 --> 11:22.920]  And after Linux has rebooted, we again see that the monitor notices Linux is alive.
[11:22.920 --> 11:30.880]  And if after we wait a bit, we get again a shell which we can use like any other Linux
[11:30.880 --> 11:31.880]  system.
[11:31.880 --> 11:36.760]  Yeah, the demo.
[11:36.760 --> 11:42.080]  Thank you.
[11:42.080 --> 11:45.280]  So then to conclude, again, a research question.
[11:45.280 --> 11:48.800]  Can we ensure availability for safety-critical applications while running a commodity-OS
[11:48.800 --> 11:51.320]  on the same system with little developer impact?
[11:51.320 --> 11:53.200]  We do believe so.
[11:53.200 --> 11:58.160]  We did this by leveraging threshold isolation to isolate the critical applications.
[11:58.160 --> 12:02.600]  We introduced a secure scheduling system with freeRTOS.
[12:02.600 --> 12:07.320]  And we introduced also a transparent peripheral sharing system.
[12:07.320 --> 12:08.920]  We have some documentation online.
[12:08.920 --> 12:14.320]  I put it as a tutorial, but you need this board to be able to run it.
[12:14.320 --> 12:16.440]  So it's still ongoing research.
[12:16.440 --> 12:22.360]  And we will update this tutorial whenever we update, we get new stuff in our research.
[12:22.360 --> 12:25.160]  You can also look at the documentation for Opti as well.
[12:25.160 --> 12:28.520]  And if you have any questions at any time, just contact me at this email address.
[12:28.520 --> 12:31.480]  I'd be happy to answer them.
[12:31.480 --> 12:32.480]  So that was it.
[12:32.480 --> 12:34.080]  I hope you enjoyed the presentation.
[12:34.080 --> 12:36.080]  And if you have questions.
[12:36.080 --> 12:37.080]  Yeah.
[12:37.080 --> 12:56.840]  So one of the problems I see with this approach is that you move the device to the secure
[12:56.840 --> 12:57.840]  world.
[12:57.840 --> 12:58.840]  They basically have a seam layer to make the cabinet talk to the device you move to the
[12:58.840 --> 12:59.840]  secure world.
[12:59.840 --> 13:00.840]  The problem is, we've been discussing this for a while, but the problem is you expose
[13:00.840 --> 13:07.840]  a bigger back surface in both the, which is the drivers, basically breaking the main assumption
[13:07.840 --> 13:10.840]  in opting that we don't trust Linus, right?
[13:10.840 --> 13:16.840]  So you have a buffer that fits into your driver and you kind of start to trust that buffer
[13:16.840 --> 13:22.840]  because it ends up being hardware, so there needs to be some kind of arbitration or rationalization
[13:22.840 --> 13:24.840]  process during that thing.
[13:24.840 --> 13:26.840]  And how do you thought about this?
[13:26.840 --> 13:27.840]  Yeah, of course.
[13:27.840 --> 13:32.840]  It was indeed that if you move a driver into the secure world, we increase the attack surface
[13:32.840 --> 13:40.840]  considerably, of course, and we solved this, or we thought about it indeed, and we came
[13:40.840 --> 13:43.840]  to the conclusion that it is indeed a problem.
[13:43.840 --> 13:48.560]  However, if you get secure policies, which you know in advance, so for example, we know
[13:48.560 --> 13:53.280]  that a peripheral can be read only by the normal world, but not written because of course
[13:53.280 --> 13:55.560]  you designed a system like so.
[13:55.560 --> 14:01.880]  You can see, based on the actual requests that are sent by the normal world, if it is
[14:01.880 --> 14:02.880]  allowed or not.
[14:02.880 --> 14:06.560]  So if it's, for example, a write request to an address, we know we cannot allow this.
[14:06.560 --> 14:12.560]  However, if it's a read address, we know we can just execute it and return the data.
[14:12.560 --> 14:15.560]  We have a hardware vendor who will just listen and have a hardware that responds to do memory
[14:15.560 --> 14:17.560]  address cases and you should be fine.
[14:17.560 --> 14:20.560]  Yeah, but that's not the case, sadly enough.
[14:20.560 --> 14:26.560]  The thing is that there's an RFC that we haven't been able to reason about it, which
[14:26.560 --> 14:30.560]  we don't have a watchbook like you have an object that we do have is that we, once the
[14:30.560 --> 14:33.560]  camera comes up, we measure portions of the text area of the camera.
[14:33.560 --> 14:38.560]  We take a text and then we periodically randomly check if that hasn't taken.
[14:38.560 --> 14:44.560]  Now, arguably, that's not a very strong attack against recent, you know, rocks and stuff
[14:44.560 --> 14:47.560]  like that, but you should check that out at some point.
[14:47.560 --> 14:52.560]  Yeah, we are considering this for other research projects that we are running at the same time.
[14:52.560 --> 14:54.560]  It's a question that keeps coming back.
[14:54.560 --> 14:59.560]  How do we authenticate the normal world or the Linux kernel to the secure world?
[14:59.560 --> 15:01.560]  How do we make sure that it is running correctly?
[15:01.560 --> 15:05.560]  Because the kernel, when it comes up, we basically change the bounce of the muscle code.
[15:05.560 --> 15:06.560]  Yeah, indeed.
[15:06.560 --> 15:07.560]  Yeah.
[15:07.560 --> 15:10.560]  After some point, in this case, it's arguably trust what happens.
[15:10.560 --> 15:11.560]  Yeah, indeed.
[15:11.560 --> 15:16.560]  And there is some research going into attestation, so not remote attestation but locally.
[15:16.560 --> 15:22.560]  And also some continuous attestation, but it's still an Linux kernel, which is very difficult to attestate.
[15:22.560 --> 15:24.560]  The last thing is the kernel itself, right?
[15:24.560 --> 15:30.560]  So when you write it to memory and then reboot it, you need to have some kind of cryptographic
[15:30.560 --> 15:31.560]  set, right?
[15:31.560 --> 15:35.560]  Because the trending in the whole chain of trust is, you know, you boot with the effect
[15:35.560 --> 15:38.560]  that verifies your kernel and then you outestate it.
[15:38.560 --> 15:45.560]  But if you load the kernel and down to an entry point, first of all, you need to cryptographic
[15:45.560 --> 15:46.560]  verify what you're doing.
[15:46.560 --> 15:47.560]  Yeah, of course, yeah.
[15:47.560 --> 15:52.560]  And there's been some code and development going into EFI where if you down to the kernel
[15:52.560 --> 15:56.560]  entry point and not the EFI entry point, you use a bunch of security services.
[15:56.560 --> 15:57.560]  For example, ASL app.
[15:57.560 --> 15:58.560]  Yeah, of course.
[15:58.560 --> 16:00.560]  So this was a proof of concept indeed.
[16:00.560 --> 16:04.560]  If you just write the kernel image back to the normal world and jump to it, it's of course
[16:04.560 --> 16:06.560]  a big problem.
[16:06.560 --> 16:11.560]  So if you want to actually build such a system in a secure way, you will need to do checking
[16:11.560 --> 16:15.560]  your image at boot time when you store it in memory.
[16:15.560 --> 16:19.560]  Once you've checked it and stored it, you know that it's safe and then whenever you want
[16:19.560 --> 16:23.560]  to reboot, you can set up the normal world completely so that it is again in a well-known
[16:23.560 --> 16:27.560]  secure state like at boot time and then write the image.
[16:27.560 --> 16:28.560]  We can talk.
[16:28.560 --> 16:29.560]  Of course, yeah.
[16:29.560 --> 16:30.560]  There's more problems, right?
[16:30.560 --> 16:34.560]  Because for example, if you boot like that, ASLR won't work properly in our, at least in
[16:34.560 --> 16:35.560]  our system.
[16:35.560 --> 16:36.560]  Okay.
[16:36.560 --> 16:38.560]  Okay, we'll have a good discussion.
[16:38.560 --> 16:39.560]  Yeah.
[16:39.560 --> 16:40.560]  Yeah, go ahead.
[16:40.560 --> 16:45.560]  Maybe a follow-up question to this initial observation about the sort of security aspects
[16:45.560 --> 16:49.560]  of kind of sharing responsibility for the peripherals.
[16:49.560 --> 16:55.560]  Another reason why you would want to partition the peripherals rather than to give control
[16:55.560 --> 16:58.560]  competes with trust is also performance, right?
[16:58.560 --> 17:03.560]  Because essentially now you're saying that for any peripheral access, you need that to
[17:03.560 --> 17:04.560]  go through the...
[17:04.560 --> 17:05.560]  Yeah, so there is...
[17:05.560 --> 17:10.560]  There is some latency number, but did you evaluate the overall performance degradation
[17:10.560 --> 17:11.560]  on the Linux?
[17:11.560 --> 17:12.560]  Yes, indeed we did.
[17:12.560 --> 17:13.560]  I did not include the slide.
[17:13.560 --> 17:14.560]  Ah, yeah.
[17:14.560 --> 17:21.560]  So the question was, if we evaluated the complete latency of sharing peripherals between the
[17:21.560 --> 17:26.840]  two worlds, yeah, we did indeed verify, don't have a slide for the graphs, but if you look
[17:26.840 --> 17:32.400]  at these numbers, you can see that to go to the peripheral from the normal world, it takes
[17:32.400 --> 17:35.160]  around 103 microseconds.
[17:35.160 --> 17:40.080]  This is however in a standard call in OptiOS, and there is also something like a fast call
[17:40.080 --> 17:45.280]  and then you will get six microsecond latency, which is very fast, certainly fast enough
[17:45.280 --> 17:49.200]  for the requirements set by our industrial partners.
[17:49.200 --> 17:54.160]  And also the 68 microseconds to go back is also quickly enough for these systems, because
[17:54.160 --> 17:57.320]  these systems often have a control loop of one millisecond.
[17:57.320 --> 18:03.480]  So that means that, yeah, even with these numbers, you have like 95 or above of the original
[18:03.480 --> 18:06.840]  performance or time of execution in the normal world.
[18:06.840 --> 18:12.160]  So this is, we think this is a cost that we can totally take in developing the systems
[18:12.160 --> 18:17.160]  just because it gives us so many benefits on security level.
[18:17.160 --> 18:19.160]  Is that good?
[18:19.160 --> 18:20.160]  Okay.
[18:20.160 --> 18:21.160]  Yeah.
[18:21.160 --> 18:47.080]  So the question was, how does this system using a trusted execution environment compare
[18:47.080 --> 18:52.080]  to a hypervisor implementation?
[18:52.080 --> 18:57.320]  At our research group in this synod, we are working with very low-end embedded devices.
[18:57.320 --> 19:02.240]  So this is a proof of concept on quite a high processor, it would be possible to do it in
[19:02.240 --> 19:03.240]  a hypervisor.
[19:03.240 --> 19:07.280]  I don't know how to do it because I haven't taken a look at it that closely, but on these
[19:07.280 --> 19:14.520]  very low-end embedded devices, it's mostly not useful or it's even damaging for the lifetime
[19:14.520 --> 19:22.600]  of device to use a hypervisor because you have also quite some overhead and a very limited
[19:22.600 --> 19:23.600]  lifetime battery.
[19:23.600 --> 19:26.120]  You have a very limited energy budget.
[19:26.120 --> 19:31.800]  So on these lower-end processes, there is an arm trust on implementation that is also
[19:31.800 --> 19:33.840]  very energy efficient.
[19:33.840 --> 19:38.080]  So if we would, of course, not use Opti-Res and Linux, but take the same principles and
[19:38.080 --> 19:43.960]  apply it to such a chip, we believe we could stay in the energy budget that these low-end
[19:43.960 --> 19:45.280]  devices have.
[19:45.280 --> 19:50.200]  And we don't think it's something we can immediately do with hypervisors, but of course, that's
[19:50.200 --> 19:54.800]  not my research area, so that's something that can, of course, be very interesting to
[19:54.800 --> 19:55.800]  research.
[19:55.800 --> 19:56.800]  There was a question in the back.
[19:56.800 --> 20:02.960]  Is there an instance of this hardware that we can use on the cloud to try it out?
[20:02.960 --> 20:09.480]  I'm afraid not, so there is no instance in the cloud that is available to try right now.
[20:09.480 --> 20:17.360]  However, there is, I don't know if you know QEMU, possibly you do, so QEMU.
[20:17.360 --> 20:20.640]  It does support ARM virtualization.
[20:20.640 --> 20:25.360]  So we actually first started using that to develop our system, but we very quickly moved
[20:25.360 --> 20:28.640]  on to a hardware device because of our industrial partners.
[20:28.640 --> 20:34.200]  So the code, as is, won't immediately run on QEMU, but if you change the interrupt
[20:34.200 --> 20:41.080]  numbers and the things that are different, it should be relatively easy to reproduce
[20:41.080 --> 20:45.040]  the same results on a virtualized system as well.
[20:45.040 --> 20:50.840]  Just to continue on the question on virtual machines versus OPE.
[20:50.840 --> 20:55.880]  I think one key difference is that OPE is actually a real trusted execution environment
[20:55.880 --> 21:00.520]  in the sense that compared to a virtual machine where the hypervisor would have access to
[21:00.520 --> 21:08.520]  the address space of the protected application and through flow, with OPE, it doesn't.
[21:08.520 --> 21:13.520]  Anything that runs on the unsecured world does not see that the physical address space
[21:13.520 --> 21:14.520]  cannot access.
[21:14.520 --> 21:20.520]  Well, I guess, for example, our question is like the Siemens software controllers, actually
[21:20.520 --> 21:25.520]  the hypervisor is not Windows or Linux, it's the custom hypervisor, and that also has access
[21:25.520 --> 21:26.520]  like proper.
[21:26.520 --> 21:32.440]  So if it is an hypervisor that uses hardware virtualization, it does have access to the
[21:32.440 --> 21:36.840]  address space of whatever VM is running on the machine.
[21:36.840 --> 21:42.520]  If it's based on the ARM64's virtualization extension, it will have access to the address
[21:42.520 --> 21:43.520]  space.
[21:43.520 --> 21:49.280]  With OPE, the address space is only accessible to the secure world.
[21:49.280 --> 21:53.360]  It's controlled by the secure monitor, which is running at a very privileged level, which
[21:53.360 --> 21:55.520]  is more privileged than the hypervisor.
[21:55.520 --> 22:02.720]  So the hypervisor does not get access to the secure application, whereas with an hypervisor,
[22:02.720 --> 22:07.320]  the hypervisor could just mess with the nested page tables and do whatever it wants, access
[22:07.320 --> 22:08.320]  to the secure peripheral database.
[22:08.320 --> 22:13.120]  Maybe to kick in here then, I love this, so that's what the coffee break hours are like
[22:13.120 --> 22:14.120]  before.
[22:14.120 --> 22:18.120]  So please continue this discussion, but just for the general audience, would I have like
[22:18.120 --> 22:19.120]  a 10-minute break now?
[22:19.120 --> 22:22.120]  I won't call it a coffee break because there's not enough time to run downstairs, you wouldn't
[22:22.120 --> 22:23.120]  come back up.
[22:23.120 --> 22:28.120]  In 10 minutes, we will continue with the next talk, but exactly use it for these type of
[22:28.120 --> 22:33.120]  one-to-one break and continue the discussion in the next 10 minutes.
[22:33.120 --> 22:57.120]  One thing I wanted to pitch in.