 Good afternoon, everybody. My name is Eddie Dong from Intel Open Source Technology Center. In this session, I will talk about ACON, a big little hypervisor for IoT development. In this morning's keynote, we must also from Intel unveil the ACON Hypervisor Open Source Project. In this session, I will talk a little bit more details. Here is the agenda. OK, we will start from the ACON overview and then followed by the security concern in ACON side and the virtual mediation we implemented in ACON and why we call it big little hypervisor. OK, so what's ACON? ACON is a big little hypervisor for IoT development. Little means like the footprint is pretty small. Biger means the functionality is pretty large. As Seema mentioned in this morning's keynote, ACON is a scalable, flexible, lightweight reference hypervisor design with real-time behavior and safety criticality in mind. So let's look at the ACON architecture. So ACON is a type 1 hypervisor running on top of bare metal hardware and firmware. ACON relies on the service VM to manage the hardware device so that ACON itself can be very small and simple. So that this is particularly important for embedded ecosystem because in some situations, some users, people may require the function safety certification. Or in some cases, people may want to use the different service OS for a specific purpose. For example, to run a small RT OS service OS. ACON supports apocalyptic now, but will support more platform soon. The platform has a converged security engine called CSE, which provides a root of trust. In firmware side, ACON can support the UEFI, which is widely used in PC platform. As well as the SBL slim boot load firmware, which is usually designed for latency-sensitive users. ACON hypervisor utilizes the hardware versioning technologies, such as the VMX for the CPU virtualization, EPT for the memory virtualization, and VTD for DMA protection. ACON deprives all the guests to learn in VMX non-root operation mode. This is prevalent with people usually call it as guest mode, including the service OS. This is slightly different with what Zen did in Zen side. The service VM is called Domain Zero, runs in the VMX root operation mode. ACON created the first virtual environment for the service OS. In service OS side, today we learn the Linux service OS and use the native device drivers in Linux side to manage all the hardware devices. So the service OS can provide our mediator to guests. To support the more VMs, ACON learns a device model in user land. It's called ACON device model. ACON device model creates a virtual platform for guests so that the guests can learn on top. For performance consideration, ACON also implement a so-called para-virtualized our virtualing technologies. In here, we adopt the industry standard virtual specification, because this way we can reuse a lot of the existing virtual drivers in today's Linux community, in Linux source code. For performance reason, ACON also implement support in kernel mediators for the performance-sensitive usage. For example, the latency-sensitive audio virtualization, and also like, for example, the NPU NPU means the embedded processing unit is kind of a camera driver for their purpose. The guest in ACON starts from the virtual SPL with the virtual device driver and some the legacy device drivers. The guest can fully reuse the existing virtual drivers and also the security features like a key store and includes. This is particularly important in the client users. It's not that obvious in the server side, but in the client side, it's very, very important. ACON device model, for the ACON device model, and one thing I want to highlight is that for safety, criticality, reasons, we didn't use the well-known QEMU device model because QEMU is so big, I think it have around a couple million lines of source code. We use a brand new device model in kernel from BSD. Our ACON device model is only around like $25,000. Around $20,000 to $30,000 lines of code. This is very important for certification. In the meantime, ACON also implemented some performance-critical RL devices in hypervisor side, including the virtual RL epic and the local epic and MSI. Because as you know, the interrupt controller is frequently used by the guest OSes. So that part is performance-critical. And we have to emulate in ACON hypervisor itself. OK, so in security side, to support the key store and the includes, we actually have ACON implement a lot of additional things comparing with those server hypervisors. One is that is a seed virtualization. So in all the Intel platforms with the CSE, where the CSE will provide a unique seed for OS to manage the key store. So that the OS itself can use the seed to encrypt the keys in the key store. This is a very important feature in Khan side. And also, in Intel platform, we have one so-called hacky hardware. It's called how host embedded controller interface to communicate between CSE and host CPUs. ACON virtualizes a hacky device driver for tools provided and virtual hacky for guests so that the existing key store and the includes can run on top. Today, ACON support Linux OS and Android OS. We will support more OS soon. In Android VM side, the Android VM is a little bit more slightly different with traditional VM. In Android VM, it's one VM with two world. They're called the normal world and the trusty world. The trusty world can see all the memories of normal world, but normal world cannot. So we ACON provide the one VM, two-word concept and so that the trusty OS can run in trusty world and the security sensitive applications can run inside the trusty. OK. As a device hypervisor, ACON is very small. It's only around 25,000 lines of code. That's, well, if we compare that with other open source project hypervisors, for example, then the KVM, then it's very similar. From an architectural point of view, very similar with ACON. Then today has around 290,000 lines of code. That's around more than 10 times bigger than ACON. KVM is much bigger because KVM is a table two hypervisor. It has to rely on the host OS to complete the entire virtual reality functionality. ACON uses a BSD license. This is to fulfill the requirement of the embedded ecosystem. Because embedded systems side, many different uses requires different customization, requires different, I think there are a lot of relatively small companies working in embedded systems areas with different proprietary software. For example, even in some cases, people may use their own hypervisors. There are many embedded hypervisors in the world. Well, if you look at the server side, it's probably just a couple, less than five hypervisors. So we use the BSD licenses to help them in case the customers or even the OSVs or OEMs want to partly reuse our code. They can just use the BSD code and incorporate those codes in their hypervisor or in their solution or in their customized software. ACON supports security. I think one of the key considerations is that in embedded systems, in many cases, there are a lot of requirements, not only security, but also safety. So for that purpose, I think we needed to create an environment with trusted environments. So we supported the verified boot all the way to the guest so that the critical software can ruin a safe environment. We will talk about the details later on. ACON is big because from a functionality point of view, we can provide almost even more functionalities than the server hypervisors. ACON implemented a bunch of new Android device drivers. So here is a list. It's not a full list, but just a list of what we are working on at the moment. For example, I think if you compare with the server side, you can see, like, the IMPU image processing unit is kind of a camera driver. So IMPU usually is never sought in the server side. TSM, time-sensitive network, this server side is not as well. TSM is mostly for audio and video. CSE, as I mentioned, this is a converted security engine. This is also a client device. So we needed to provide all these kind of emulations. USB maybe is server also use that one, but different. We will talk about later. Audio device is more a client device. IOC is called IOController. This is also a client device. So it's usually not used in server side. So ACON implemented all these kind of virtual devices for the embedded usages. OK, now let's talk about the security side. First of all, we want to talk about the verified boot sequence. ACON support the verified boot all the way to the guest. With different firmware, the mechanism is slightly different, but mostly the same. So in these foils, I will talk about the ACON verified boot sequence with SBO firmware. The hardware boot starts from the CSE, the converted security engine, because CSE is the root of trust. CSE will measure the SBO, the slim boot load. This is a firmware. If the measurement passes, then the control will go to the SBO. SBO will initialize the hardware like a traditional firmware does. But then the SBO will load and verify the OS image or VMM image. In here, we are using a stitched image to stitch the ACON hypervisor and service with kernel together. So SBO will load and verify the stitched image. And once the verification passes, then the control will jump to the ACON hypervisor. ACON hypervisor will initialize the hypervisor itself, and then create the VMM environment for the service OS and jump to the service OS kernel. The service OS kernel will boot like a normal Linux does. And it will start all the applications, including the device model and other services. One thing I need to highlight here is that in ACON boot flow, all the applications needed to be integrated and protected. So this can be achieved through, for example, like a DM variety to make sure all the applications we learn in the user land is integrated. The device model will then load the virtual SBO. That kind of load will be also protected by the service OS DM variety kind of mechanism. And the virtual SBO will start to boot in gas side. And here, we are using Android as a sample. So in Android side, the virtual SBO will load the trust OS first, match the trust OS, if it passes, and then will jump to trust OS. And trust OS will do something similar to load the Android OS. So gas side verification boot flow is completely following the gas OS mechanism itself. For example, Android is following the Android verified boot mechanism. OK, so here is a verified boot sequence with the UEFI firmware. Mostly, it's the same with that in SBO, but slightly different. In UEFI side, because usually, people using UEFI cares about the other functionalities. For example, the flexibility to choose the boot media or how to update the OS kind of thing. So we want to remain the existing OS boot flows. The existing OS boot flows start from the OS boot loader. So in here, like that, with SBO platform, the boot start from the CSE. But the CSE here will verify the UEFI. And once UEFI is verified, and then the control will go to UEFI. UEFI will provide the UEFI boot time service and the runtime service. So UEFI service itself can provide the verification mechanism. So UEFI will load the ACON UEFI application and measure the ACON application. Once ACON completes the initialization, and the control will go back to the creator VM, and the control will go back to the service OS VM. Then the UEFI flow will continue, and it will load the OS boot loader. The way UEFI to load the OS booter is following exactly how UEFI is implemented in native side. So the UEFI will also verify the OS boot loader. And once OS boot loader handles the control to service OS kernel, same thing. Service OS kernel is also an UEFI application. So UEFI itself will load and verify the service OS kernel. Service OS kernel will then load the application. That's same with that in SBO side. So service OS kernel will verify each application loaded using the integration protection mechanism, such as the VM variety. And the device model will then load the virtual SBO and the guest, the same thing with that doing SBO. The only difference is that in here, I think we are booting from, how to say, from ACON. We need to boot the OS boot loader. And also those are all UEFI applications, not a law image. OK. Another important security feature, as mentioned previously, is called seed virtualization. The Intel platform with CSE provides a unique seed. That seed is used by OS to manage its key store. In here, with the virtualization, we need to provide a virtual seed to guest OS so that each guest can have their own virtual seed and manage their own key store. That virtual seed must be different because we don't want to leak the key store from one VM to another VM. So for that purpose, we provide an ACON provider and seed virtualization mechanisms. We deliver virtual seed from the physical seed plus some additional information. In here, to distinguish each VM, we introduce a UUID for per VM. We bind an UUID with each VM's image. And when the VM is launched, we will get the fixed UUID for that VM. And the seed virtualization can use the physical seed and the UUID together to deliver the virtual seed. In this way, if the VM is started later on, we get the same virtual seed. This is exactly what the guest OS is expected. And that's what hung the physical platform performance. With seed virtualization, the key store can be maintained. OK, hacky virtualization. Yeah, I slightly mentioned it previously. But here, we want to talk a little bit more details. Hacky is a PCIe device. It's hosted in better controller interface to support the communication between the host CPU and the CSC. CSC is also an MCU inside. So usually, when the host CPU does the security-sensitive operations, it will use the hacky interface to communicate with the CSC and let the CSC do that for the purpose. For example, the seed. If the host's CPU wants to access the seed, it needs to go through the hacky interface. And also to support a lot of different security features. For example, the manufacturing key, debug key input, all those kind of keys are managed by the CSC hardware. If host OS wants to set the CSC, it needs to go through the hacky interface. So here, we need to support the seamless user environment with that of native side. We need to provide a hacky virtualization. In Linux side, they are called an MEI driver, Management Engine Interface Driver, and MEI Subsystem. That is used to manage the entire hacky software stack. So we provide a virtual hacky device to guest and implement a virtual hacky front-end driver in guest side so that the guest MEI Subsystem and the MEI driver can ask for the CSC service through the hacky front-end driver. The hacky front-end driver will forward the request to the hacky back-end driver. We implement the hacky back-end driver in the device model side in user land because usually, this kind of operation is at the startup time. It's not a performance-critical. Usually, it's one-time operation. So the device model running the hacky back-end service will then use the existing host OS, MEI Subsystem, the MEI interface to ask the host OS to operate the real hacky hardware through the native OS driver interface. It's called a char device. In this way, CSC can receive all the commands. Of course, in the back-end side, we may do some kind of virtualization, kind of mapping and security check kind of things. For example, each VM may have a different identity. So we need to make sure the physical data knows the command comes from which VM. OK. So let's talk about more on the IoT virtualization side. Why we say this is a big high-five. So we started the IoT virtualization from storage virtualization because even in the project side, when we start the IoT virtualization, we start from the existing server IO. Storage virtualization is very similar with that in the traditional server side. The guest OS will have a so-called front-end driver, the storage front-end driver. When the guest accesses the block devices, the front-end driver will forward the command to the back-end side, the back-end service side. And the back-end side, using the shared ring, the back-end side will intercept the command and do the emulation correspondingly. So in here, we will map a host disk or a host partition or a host file to a guest disk in the back-end side. One additional feature Icon implemented is that we can, Icon can support to map from a portion of a host disk or a portion of a host partition or a portion of a host file to a guest disk. That's to provide the most more flexibility. Network virtualization is also very similar with that in the service side. The guest will have a virtual network driver. And in the service side, we do the virtual back-end service by intercepting the command from guest side. And we rely on the service side network software stack to do the packet classification and packet forwarding. In here, we use either a virtual bread or a virtual switch to load the packet. For the incoming packet, the packet arrives in the virtual bread first. And the virtual bread will load the packet to the corresponding VMs. Same thing for the outgoing packets. This part is very similar with that in traditional Zen KVM kind of things. ROC is different. ROC is a client device. It's called ROController. ROC is a hardware in the platform used to communicate with the whole CPU through UART interface. And controls a lot of devices through Canvas in the instrument devices. So in the virtual side, we needed to provide ROC virtualization as well. So one example is that ROC can be used to control the pulse lifecycle of the entire system. And also can be used to control, for example, air condition of the car, for example. So for that purpose, the way the guest ROC, when the guest send an anchor, because it uses UART, so we can easily intercept the command from the guest side and through the UART virtualization. So in the backend service in device model side can easily intercept the message from the guest OS side and do the filtering, do the checking to translate or to emulate the command. Here, actually, from the real hardware point of view, the command, the ROC process probably can be classified into two. So one is a kind of privileged command. For example, the command used to turn on the power of the entire system or turn off the power of the entire system. This kind of privileged command can only be handled by the service OS itself, because the service OS is a privileged VM. That message can never goes to the user OS. But some other message, for example, the maybe like a turn on radio, that is an entertainment component. It can be controlled by the user OS. So we need to forward that kind of message to the user OS. So GPU virtualization. GPU is one of the most complicated IoT devices in modern computer system. So ACON do provide the GPU virtualizations. And ACON runs the native GPU driver in the guest side to pass through the performance critical, but non-provided operations from guest to the real hardware for performance reason. That can be how I say that the technology is self. This is well known even in the server virtualized side. It's called the mid-data pass-through technologies. It's something between full pass, complete pass-through, and the parallel virtualization side. So we call it the mid-data pass-through. So for performance critical resource access from guest is pass-throughed. But for the privileged command access, it's chopped and emulated. The performance of mid-data pass-through is usually much, much better than parallel virtualization itself. It's very close to the pass-through operations. So in ACON, when the guest access to the provided resource, the access is chopped into hypervisor first. And the hypervisor will forward the access to the device model, the backend service in service side, so that the service can provide the emulation to generate a virtual GPU instance. The entire flow follows the same with other virtual devices. But I think the key difference here is that we learn the native GPU driver in guest side. That's the difference between mid-data pass-through and parallel virtualization or virtual. You have better performance, but it's not a free launch. We have to pay with the complexity of the solution. When the hardware evolves, the entire solution needs to evolve because the device model is emulating a real hardware. So if hardware changes, then the device model has to change as well. Audio virtualization. So in server side, some cases it may use audio, but typically people don't care about audio. But for embedded systems, for client systems, audio is very important. In ACON, audio virtualization relies on the existing OS sub-system architecture. So in Linux, it's an advanced Linux sound architecture. It's called OSA and the sound open firmware soft architecture. For the soft, I think in the morning's keynote, Ima just talked to that one. Soft is a kind of new audio hardware implementation kind of firmware implementation framework. So ACON implement audio virtualization based on both the OSA and the soft. In native audio system, the OSA application will invoke the OSA library to involve the kernel. And the kernel will then use the soft framework to involve the hardware through the NPC command. NPC means inter-processor communication. That's because the sound hardware is another separate processor in the system. So this is called, like, is communicated between the soft NPC driver and the DSP platform driver. With the virtualization, in the guest side, we provide a virtualized audio DSP device. And then learn the virtual audio device front-end drivers in the guest side to talk with the soft NPC driver. So that when the guest application sends a stream, the stream will go to the front-end driver. And then the front-end driver will forward the packs to the back-end driver learning service side. This is, today, the kernel mediator. So that one learns in the kernel side. The audio back-end service will then get the stream data through the interpreter, interpret the shared ring and get the data, and then send the data to the real hardware, the real audio DSP device through the host side of the software architecture. This is the soft NPC driver where has the interface for the additional back-end service to register its APIs to involve. So through this way, the entire system can support the audio playback. Another important device in kernel side is USB. When we're talking about USB, many of you probably are already aware if you ever try the service side of the USB version side. So USB virtualization is not new, but I can't extend the USB virtualization to support a lot of new users. For example, the CarPlay. In this case, for example, CarPlay, not only USB host controller, but also USB device controller are involved. So in here, the USB virtualization solution covers both the host controller virtualization and the device controller virtualization. For the host controller, the controller icon provides a sharing among multiple VMs. And we can assign the USB port to each VM, different USB ports to different VMs. So that means from a port point of view, it's a kind of dedicated access as an assignment. But from a host controller point of view, it's shared. USB device controller is different. Device controller usually means it's just one device. The entire physical system is one device. And the device controller needs kind of anti kind of things. So in here, I think usually when we use the device, it's just one VM needed to use that device to play the CarPlay, to learn the CarPlay application. So we assign the XDC Android device to guest. This is the XDC Android driver in the guest side. So that way, the guest can have both host controller access and device controller access. But that's not enough. To support CarPlay, the USB port behavior like an USB on-the-go device. The same part needed to behave as a host controller or device controller per internal software control kind of things. CarPlay will configure the port to behave as a host controller or device controller at runtime. So for that purpose, we need a mechanism to control the real hardware to behave as a host controller or device controller. In real hardware, in native side, this is controlled by the DRD driver. Due to low device driver. But the hardware resource the DRD driver access is usually in the XHCN host controller side. So we cannot pass through the DRD driver to guest. We have to run the DRD driver in service side because the hardware resource is in service side. For that purpose, we need to provide a virtual DRD front end driver to guest so that when the guest application want to configure the port to work in device mode, the front end driver can forward the request to the back end side. And the back end side can involve the native DRD driver to control. This way, we can provide the CarPlay support. OK. Oh. There are a lot of other mediatas in developing Aircon side. And I don't want to talk too much today. If you are interested, please join us through the Aircon community. Yeah, that's all for my talk. Any questions? OK, good question. So at the moment, we just launched the Aircon Hypervisor yesterday, or the day before yesterday. So at the moment, we're only about 64-bit OSs against it. But yeah, 32-bit is in our plan. I guess it will come in one or two months or something like that, other architectures. Currently, we only have x86 64-bit architecture. We would like to support it as well. But at the moment, it's not. Aircon is very young yet. So far. You mean the user case? The service case to address in Hypervisor, that's very clear. For example, this Hypervisor is pretty small. It's like 1-pence of sand code size. So that's for safety. Service OS is not limited to Linux. You can use whatever RTO is certified. For example, Selfa, or VxWalks. That's where you just provide the order. Yeah, but for example, VxWalks is already safety-certificated. So still a lot of work. Yeah, I agree. But anyway, it's comparing with existing server Hypervisor. This one is much simplified. How do I feel? OK. I think I can say something. So actually, one of the requirements of the certification is to handle the highway failure, so-called a photo model. Yes, this is the basic architecture. Besides this one, we need to add a lot of the kind of failure processing. It's so young. At the moment, it doesn't have this one. But the architecture itself opens the door for these kind of things to add on. So you mean the GPU rendering failure, right? So yes, GPU sometime may. OK, so here's saying the GPU application, if running the i9-15 driver, in some cases, may trigger the highway failure. Yeah, I understand that in native site, that kind of case may happen as well. This is mostly for the rendering command, because if the command used to submit to the GPU is too complicated, or for some cases, it will trigger some software bug or a hardware bug, the GPU may harm. That's true. So in native site, how is this problem solved? I think that today, the solution is that the hardware will provide timeout mechanisms. Once the timeout is detected, the driver will reset the hardware. In our case, for safety reason, if the failure comes from the guest, we can stop the reset the engine working for the guest at the moment. But in service-wise, assuming if the safety application runs in service-wise, or runs in a separate VM, in that case, we need to isolate them. So I think the first one, to report the failure today, we can do that, because timeout mechanism can be used here. But to recover from the failure, there are a lot of things to do. From certification point of view, what we are saying is a typical solution to the hardware failure is to reboot. So-called watch time doggie, watch time doggie. Memory leakage. If the hypervisor can use the EPD to protect the- if the hypervisor don't have a bug, then EPD can solve the problem. But if the hypervisor has a bug, that's another story. So suppose the certification process will do that kind of code sanity kind of things. Of course, even sanity code is not 100% correct. It may have a bug as well. But that's at least from engineering point of view, we can have a way to do that. Try to use EPD to protect. Yes, password device is about, sorry, I forgot to mention. Yes, that's one of the key features. That's same with that in service-wise, the way to support the password. Actually, for the embedded systems, it's more challenging to support the password, because embedded systems are usually very small, and all the devices are in the SOC side. The SOC design is slightly different with the server. Server side, the device is a PCIe separate card. So that card, the driver and the card itself will, how to say, is kind of safe content. It will never assume what kind of resource it can access beyond the card itself. But in the SOC side, it's slightly different, because SOC put everything together. So they may have some kind of interdependency. We do support the device password, and that's one of the key features as well. Any more questions? Okay.