We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Open Source Confidential Computing with RISC-V

00:00

Formal Metadata

Title
Open Source Confidential Computing with RISC-V
Title of Series
Number of Parts
542
Author
Contributors
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Standing on the shoulders of the TDX and SEV giants, the RISC-V AP-TEE Technical Group is currently defining the threat-model, the reference architecture and the interfaces to support confidential computing use cases on RISC-V. All the TG discussions happen in the open and all the related reference implementations are open source, representing a unique opportunity for interested contributors to participate in the elaboration of such a fundamental piece of technology. During this presentation we will describe the currently proposed architecture, highlighting how it is focusing on multi-tenant, hardware-virtualized workloads. We will also explain how both the guest and host APIs will support this architecture by stepping through a few concrete confidential computing use cases. Next we will present Salus, the reference Trusted Security Manager (TSM) implementation. The last part of this talk will go into the short and longer term tasks the TG is going to tackle, like e.g. trusted IO and attestation. During this last section, we will try to highlight where and how new contributors could help the RISC-V community design and implement this confidential computing architecture.
14
15
43
87
Thumbnail
26:29
146
Thumbnail
18:05
199
207
Thumbnail
22:17
264
278
Thumbnail
30:52
293
Thumbnail
15:53
341
Thumbnail
31:01
354
359
410
Asynchronous Transfer ModeIRIS-TOpen sourceFreewareOpen setReduced instruction set computingSelf-organizationVolumeModul <Datentyp>Web pageFingerprintExtension (kinesiology)Standard deviationVirtual machineFirmwareKernel (computing)HypercubeLocal GroupComputer architectureIntegrated development environmentVirtual realityCoprocessorSimilarity (geometry)Personal digital assistantIntelShift operatorComputer hardwareAsynchronous Transfer ModeWeb pageLatent heatBefehlsprozessorComputer architectureOpen setSet (mathematics)Semiconductor memoryService (economics)MappingCASE <Informatik>FirmwareCartesian coordinate systemImplementationKernel (computing)System on a chipComputer architectureModul <Datentyp>DiagramReal numberStandard deviationExtension (kinesiology)Integrated development environmentHigh availabilityVirtual machineCoprocessorNeuroinformatikSocial classVirtualizationSystem callOpen sourceSoftware repositorySoftware developerWhiteboardFeedbackArithmetic progressionGroup actionMulti-core processorState of matterComputer hardwareInformation securityPairwise comparisonGoodness of fitDampingMultiplication signEntire function2 (number)Disk read-and-write headMereologyDifferent (Kate Ryan album)Volume (thermodynamics)Mechanism designComputer animation
Local GroupReduced instruction set computingComputer architectureIntegrated development environmentCoprocessorVirtual realityExtension (kinesiology)Virtual machineIntelSimilarity (geometry)Personal digital assistantHypercubeShift operatorComputer hardwareTable (information)Video trackingRead-only memoryComponent-based software engineeringComputer architectureInformation securityDevice driverRootStructural loadEuclidean vectorAsynchronous Transfer ModeSystem callWeb pageAttribute grammarAddress spaceData integritySpeicherschutzEncryptionService (economics)Level (video gaming)ImplementationOpen sourceInterrupt <Informatik>Broadcast programmingData managementWeb pageDevice driverAddress spaceTable (information)TrailSemiconductor memoryKernel (computing)RootComputer hardwareConnectivity (graph theory)Game controllerINTEGRALBefehlsprozessorLatent heatAsynchronous Transfer ModePoint (geometry)Attribute grammarNeuroinformatikIntegrated development environmentVirtual machineCASE <Informatik>Computer architectureService (economics)Information securitySeitentabelleImplementationRight angleBitData structureFirmwareEncryptionExtension (kinesiology)MereologyInformation privacyMultiplication signSpeicherschutzComputer architectureSoftwareLevel (video gaming)Similarity (geometry)Workload2 (number)Set (mathematics)Different (Kate Ryan album)Forcing (mathematics)Key (cryptography)MultiplicationScheduling (computing)QuicksortSystem on a chipSystem callBeat (acoustics)Computer animation
Information securityWeb pageLevel (video gaming)Table (information)Euclidean vectorRead-only memoryService (economics)Attribute grammarInterrupt <Informatik>Broadcast programmingOpen sourceImplementationRootReduced instruction set computingInterface (computing)Binary fileDevice driverSpacetimeAddress spaceBefehlsprozessorContext awarenessPublic key certificateComputer architectureStructural loadComputer hardwareMeasurementComplex (psychology)Extension (kinesiology)AuthenticationInflection pointLink (knot theory)Process capability indexCollaborationismData bufferTraffic reportingDataflowLatent heatLine (geometry)Kernel (computing)Web pageElectronic mailing listDevice driverEmailComplex (psychology)Process capability indexContext awarenessFile formatForm (programming)Public key certificateTable (information)SpacetimeMereologySemiconductor memoryNeuroinformatikLink (knot theory)Information securitySeitentabelleAddress spaceFerry CorstenVirtual machineImplementationService (economics)Interface (computing)Binary codeExtension (kinesiology)Entire functionShared memorySet (mathematics)MeasurementRootProcess (computing)WeightMultiplication signComputer hardwareSoftware testingVirtualizationSoftwareScheduling (computing)System callBefehlsprozessorNumberPhysicalismState of matterOperating systemChainBitOpen sourcePoint (geometry)Intrusion detection systemCollaborationismBootingProxy serverArithmetic progressionComputer animation
Program flowchart
Transcript: English(auto-generated)
And then, you know, so before the 25 minutes for me, so if you have to stop at 1445, so you give me a give me a heads up Okay, yes
Let's do the second book today, I'm very happy actually excited about his talk so Samuel from Company will talk about What's going on in this fight landscape? I'm excited for the next step in our community, right?
Thank you, thank you, so yeah, I'm Samuel I Work for a company called rivals. It's a startup that does risk five things and today I'm going to talk about confidential computing with risk five and How do we do want to implement well an open source implementation of confidential computing?
The Previous talks have mentioned things like up to you some of them have mentioned things like SGX or a CV those are all hardware implementation of the security attributes that the the first one talks about confidentiality protection of memory confidentiality of data in use and
This talk is really about how we gonna why we want to achieve that with with risk five and the difference between the risk five implementation and all other existing implementation is that Everything is done in the open. Everything is open source and Everyone here in that room is free to come and help and contribute to that implementation So that's why I think it's interesting. Hopefully I'm not wrong
Okay Who was on the risk five dev room before? Okay, so that's needed huh risk five what is risk five Risk five is a free and open ISA not open source ISA because there's no source It's an ISA an instruction set architecture
So it's it's it's free as in you everyone can use it can build a CPU out of it Without paying in license any any fees or anything like this actually everyone is free to take half of the specification implement some weirdos CPU it doesn't matter you you can take whatever you want out of this specification and it's open in a sense that
Everything is defined in the open So all the specs are all the specs that are frozen that's been ratified and accepted by the by the risk five International Foundation, they're ratified and some modification can can be added to it, but it's it's more difficult But between the time they start to be specified and the time they are ratified
Everything is open. So it's on github. You can go and put some comments and some pull requests on CPU specifications that are actually used in the real world. So it's it's quite interesting And yeah, the specifications are released in under a an open source license There are two volumes for the specification. It's it's fairly small
It's actually 300 pages, which is I think almost the same amount of pages that x86 uses for documenting the movie instruction So Good comparison So yeah, it's very small. It's it's easy to read just go ahead and grab it
The spec is split it into the unprivileged and privileged specification and I'm going to talk about this next Why is the RISC-V ISA interesting? So first of all, it's it's simple as I just said if you look if you look at a specification if you read the specification There is no micro architectural dependency
So the specification tells you how the ISA must look like it doesn't tell you how it must be implemented So everyone is free to go and implement the ISA the way they want There is no dependency on a specific implementation and probably this is why it's small or at least smaller It is modular. So
it's the same specification for everyone RISC-32, RISC-64 and It's the same implementation for the developer boards that you can find in the market and the upcoming like the Ventana Multi-core SoC you actually massively multi-core SoCs. It's the same spec So it's it's modular everyone uses the same thing and it's stable. So there's a base ISA and a
Set of standard extensions that are frozen That means that you can rely on this to implement your CPU and you'll be able to use whatever application Are running and using those extensions. Those are frozen. They're not going to change and if they change they change a
Backward compatible way and extensions are optional. So you you don't have to implement all extensions to be called a RISC-5 CPU And this here is the base ISA. So that's the entire base ISA. This is small. It's it's very small Okay, it's easy to read. Well kind of, not on that slide, but it's easy to read and it's small
I talked about the the spec being split in between Privileged and unprivileged parts and I'm going to talk about privileged modes, which is what is defined in the in the privileged specification I'm going to talk about this because it's it's Relevant really relevant to to the confidential computing implementation. So the the the there are three basic
privileged modes for a RISC-5 CPU to run on the user mode, supervisor mode and machine mode and You switch between those modes through two mechanisms actually through instructions E-call and MRAT and SRAT. So if you're in user mode, if your CPU is running in user mode
Which is typically an application, you make an E-call, which is a syscall basically So to implement syscalls you're gonna you're gonna use the E-call instruction and if you're in the kernel and you need firmware services You're gonna make another E-call and you go down in the privileged level and you're more privileged To go back to go up and and move to a less privileged world
You're gonna call MRAT from the firmware world from the machine mode and you're gonna call SRAT to get back to from a syscall and as I said those mode actually maps to Real use cases what we typically used to so the user mode is the application mode
Supervisor mode is where your kernel is going to run and machine mode is where your firmware EFI Kind of thing is UFI kind of thing is going to run One very important thing for the confidential computing implementation is
The two additional modes actually three additional modes have been added with the hypervisor extension So there isn't an extension to the base RISC-V ISA It's called the H extension H as in hypervisor and this is an extension that's been added and and is frozen So it's it's something that that is not going to change
for supporting virtualization So the the mode that I've been adding is the the H-A mode the VS mode and the VU mode so you can see this in this diagram you can run your application as Usually in U mode and then you're gonna you're gonna have your hypervisor your host kernel when when the extra extension is enabled
It's gonna run not on S mode but on H-A mode so hypervisor Supervisor mode This is why your Linux KVM or Zen kind of thing are running And then when you're going to create the virtual machine the virtual machine is going to be split if it's a it's a full Linux virtual machine it's going to be split into two different modes the
VU mode the virtualized user mode and the virtualized supervisor mode So your guest kernel is going to run in a virtualized supervisor mode and your guest Applications are going to run in a virtualized user mode, okay? All right So confidential computing. I just I just did like a
Scratch course in five minutes of RISC-V, so I hope it makes sense but anyways, I needed to do this to kind of explain where we want to go with confidential computing on RISC-V, so the what we're defining currently on through RISC-V for confidential computing is called the AppTE RISC-V specification
AppTE as in application processor trusted execution environment So it's a technical group Where everything again is is open so there's a github repo for this technical group all the specifications are there the discussions the minic notes everything and It is not ratified yet, not frozen, so this is this is a work in progress so again
Feel free to come and join and help and and provide some feedback on that specification But it is aim and and is it it is aimed at becoming the reference confidential computing architecture for RISC-V, so this is it's currently in a pretty late state it's going to be ratified not not ratified but
Accepted pretty soon in a few months, but it's it's going to be the reference confidential computing architecture for RISC-V It's it's not an ISA specification, so we don't add to the RISC-V set of instruction and architecture architectural definitions
but we do identify a few ISA gaps for example the What we call the confidential memory attributes, which I'm going to talk about earlier later, sorry and Just to clarify things because we talked about AppTE which then there's for example. There's an implementation of AppTE for RISC-V
the AppTE Specification for RISC-V is not aiming at the same set of use cases AppTE is really trying to do and support the same use cases as TDX for those who are familiar with TDX or SEV for those who are familiar with this AMD technology and and basically this specification is defining a new class of trusted execution environment for RISC-V and these new class are
Trusted virtual machines so same as TDX so same as SEV the goal is really to run Full-blown virtual machine in a confidential computing environment where you will have memory and data Confidentiality and integrity as explained in the first first talk and the goal is really for people to take their existing workload
their existing virtual machine their existing Kubernetes nodes and Move that into a confidential computing TE The same way they're doing this or they aim at doing this with SEV or TDX Okay, so it's they're really two different set of use cases and AppTE is aiming as this specific
set of use cases So there are a few architecture components that I'm going to talk about an AppTE beats per heart Sorry, I didn't mention this but a heart
HART in RISC-V Terminology is actually a CPU core. It's a core. It's called a heart There's a few components that I'm going to go through the the security manager the TSM driver there's a dependency on the hardware root of trust and there's a there's a structure non ISA specified a structure called the memory tracking table and
to go through all these components and and kind of explain what they are and how they're put together to reach the the goal of memory and data protection and integrity Guarantees when it's in use I'm going to take an example of how from a
cold start of a RISC-V SoC we could actually build a trusted virtual machine with the confidential computing architecture that I'm trying to describe trying okay, so We have a RISC-V SoC with a few Components that are mandatory. We need an IOMMU. We need a root of trust
We need an MMU obviously this is all dependent on the H extension on 64-bit RISC-V It's basically RISC-V GC which is the general purpose Specification plus compressed, but we don't need compressed. It's just the G part But yeah, it's a full-blown 64-bit RISC-V SoC that's running there with an IOMMU
we do and we do need and mandate the presence of a hardware root of trust and We need some sort of memory protection. So an MMU a memory checker something like this the first thing that The root of trust is going to measure and load is called the TSM driver. So that's the first component of this
Confidential computing architecture and the TSM driver is the component the trusted component that runs in M mode in firmware mode That's going to split the world in non-confidential and confidential. Okay, and the TSM driver is
Yeah, a confidential world switcher and it's the component that basically Toggles a bit in the RISC-V SoC, the AppTE bit To tell if the heart is currently running in confidential mode or non-confidential mode So there is an AppTE bit that is part of the specification That tells at any point in time if a specific RISC-V core, RISC-V heart
Is running in confidential mode or non-confidential mode and the TSM driver is the component that's going to Make that switch is the component that is going to toggle that switch. So it's part of the TCB. It's a trusted component it's a software trusted component and that runs in M mode and it does that and basically the
the TSM driver is going to switch from for example non-confidential to confidential when something in non-confidential like a VMM or KVM or your Linux kernel is sending a specific TE call, which is a an E-call basically a call that allows you to move from supervisor mode to machine mode
So basically from Linux kernel to TSM driver The TSM driver is going to trap this And then it's going to toggle the AppTE bit Which means it's going to atomically switch the CPU into confidential mode and then it's going to move to something called the TSM
The trusted security manager the TE security manager. Sorry and to do that It calls the M-ret instruction and move to TSM So we are in the kernel the kernel makes an E-call the TSM driver toggles the CPU from non-confidential to confidential and then starts running the TSM and we're going to talk about the TSM next
And this is what the TSM driver is mostly about the TSM driver I'm going to talk about the TSM right after this But the one very important thing that the TSM driver manages is called the memory tracking table. The memory tracking table is a piece of memory and the structure of this of this memory tracking table is not specified in the in the in the
confidential computing specification It is up to Any implementation to decide what it puts in this in this memory tracking table what the what the specs? Tells is what this memory tracking table is for and this is what I'm going to explain now. The memory tracking table is
enforcing and Just a step back the memory tracking table leaves in confidential memory So the memory tracking table leaves in a piece of memory that is protected From from the the non-confidential world to actually see or tamper with so it's in encrypted protected
integrity protected memory so the the memory tracking table and forces The confidential confidentiality memory attribute for each and every page on the system So it's a it's what we call a PMA page tracker So it defines if any memory page is confidential or not
So you take a physical address you give that to the MTT to the memory tracking table and the MTT tells you if this Address belongs to a confidential page or non confidential page, okay So with this memory tracking table anytime you want the for example non-confidential world is trying to access physically a page
The memory tracking table is going to is going to be used by the CPU to actually check if this page is confidential or non-confidential If you're trying to access a confidential page from a non-confidential world if you're trying to read memory from your trusted virtual machine from your VMM from your QEMU from your KVM then the memory tracking table is going to tell you
This is a confidential confidential page and that's going to generate a CPU fault Okay, and it gives you memory protection Depending on how you want to implement memory encryption basically to protect your memory The memory tracking table will be able to tell you which key
You need to use to encrypt or decrypt that that physical page and you can decide How you want to implement this how many how many keys you want to support? if you want to add one keeper TVM or Multiple keys or it's it's up to you the micro architectural implementation of the specification to decide what it does with it
Okay, so the TSM driver managed the memory tracking table which gives us memory protection and an integrity and The the next thing the TSM driver is going to do is going to load and measure The next component the next trusted component that now runs in a less privileged mode the TSM the TE security manager
The TSM leaves at the same level as the Linux kernel as KVM as the I provides are basically But it leaves in confidential work It leaves it leaves and runs out of confidential memory and is only run when the when the when the the the RISC-V CPU is running with the with the apti bit on which means the
It's running when it's in confidential mode. So the TSM I don't know if people here are familiar with with TDX There are some similarities here for those who know TDX unfortunately So the TSM it's the TE security manager
It's a trusted intermediate. It's a trusted piece between the host VMM and the TVM so the TVM is a trusted virtual machine that we're trying to build through those steps and the Nothing from the confidential world can actually touch a trusted virtual machine without going through the trusted
the TE security manager the TSM One thing that one very important thing that the the the TSM does is it manages all the second second stage page tables So the page tables that allows you to translate TVM physical addresses to host physical addresses Those are manages are managed by the TSM in confidential memory. So with the confidential computing implementation
KVM no longer manages the second stage page tables for the the trusted virtual machine It's all handled by the TSM, which is trusted in confidential memory so that's a very important piece of TSM and
Something really important to understand is that it is a passive component So it implements security services that are big that are going to be called by the host VMM. It doesn't run by itself It's not it's not something that schedules a TVM or handles interrupts or or It doesn't do anything like this. It just replies to security requests that are coming from the host
The host is in control of the machine. It's not in control of the trusted virtual machine It needs to go through the TSM and the TSM is only responsible for this getting security requests from the from the host from the host VMM and replying to it and We do have an open source Implementation for this so
It's called Salas. It's on github again And it basically implements everything that I just described plus a lot more different things It's all in the specification and it's all open source. So Go there The the yes, the the TSM also also
Manages the the the entity. So whenever the TSM adds a page to to a trusted virtual machine It's gonna add entries to the to the entity and it it's a little bit more complicated in this because it needs to go through The TSM driver, but basically the entities is something that is owned by the TSM driver and by the TSM
okay, so TSM driver started it load it loaded the the TSM at some point. We have a host OS by Linux kernel with with KVM that starts it boots some non-confidential virtual machine and It's Gonna be well at some point someone is going to be is going to be starting a trusted virtual machine a virtual machine that runs
In confidential world. Okay, and to do that There's a set of ABIs between the host VMM on the left the non-confidential world and the TSM Okay, and that goes through the TSM driver The TSM driver is the trusted piece that actually Proxies each and every request from the the non-confidential walk to the confidential wall to the TSM basically and
Those are called the T host ABIs because there are It's a it's a set of binary interfaces that are called from the host to actually manage and request security security features from the TSM
Everything is proxy through a TSM driver. So the TSM driver traps the host sending equals SBI calls and basically, it traps the calls from the host VMM from KVM for example, and It then schedules T at the TSM to actually run and handle those calls. So a few examples
creating and destroying a TVM context converting confidential memory to non confidential memory to confidential and vice versa and mapping pages from Non-confidential world to a TVM all those security features They are requested from the host VMM from KVM and they are managed by the TSM. So
KVM itself Obviously, we don't want KVM to actually take a page and add that to the TVM a trusted virtual machine address space It has to go through the TSM which manages all the page tables for this TVM And for example if we if we want to create if we want to create a TVM
Which is what we're aiming or trying to do here It goes through a few steps and all those steps here map to an actual T The host VBI the ABA between the between KVM and TSM and there are basically seven steps The first one is to create a TVM context So KVM will ask for having a context so that it can use that context and and then start
Configuring the the TVM the next thing the the KVM needs to do is to allocate some memory from physical pages to the TSM so that the TSM can actually build the second stage page tables from TVM for the TVM that is Going to create those second stage page tables are living in confidential memory, so they cannot be handled
They must not be handled by the by KVM by the host VMM So KVM donate pages to TSM and the TSM is going to use that to build those space tables It's not it's not it's not meant to be to be to be used by the TVM memory It's meant to actually track the second stage page tables for the TVM
Then the KVM is going to tell TSM that it some memory region needs to be reserved for the TVM, okay so that's basically the the TVM address space and Then KVM is going to allocate pages and move those pages from non confidential to confidential and ask TSM to map those pages in the memory region that it just asked for for creation in step number three number three
Next the last and next thing that that the KVM needs to do is to create TVM CPUs because basically all the CPUs CPU state is contained and and managed in confidential memory as well all the CPU state that the TVM is going to run on top of is
managed by the TSM in confidential memory so that KVM does not see a TVM general-purpose registers values and cannot mess with it obviously, so this is all handled by the TSM as well and the KVM finalized the TVM and
Eventually asked TSM to start running the TVM And this is where your TVM is starting to run off confidential memory with a vCPU Which state is also kept in confidential memory and protected so we have this TSM just created a TVM upon the host VMM request and
The TVM can also talk back to the to the to the TSM the TVM never talks back directly to the host VMM it only talks back to to the TSM the same way a non-confidential VM VM exits would be trapped by the host VMM a confidential TVM VM exit for example or any service that the that the computational VM needs will be
managed by the TSM driver or the TSM So there is there are a set of ABIs between the TVM and the TSM and for example but I think that I didn't talk about but Attestation is something that is being requested by the TVM
So the TVM is going to ask for an attestation evidence, and this is going to be serviced by the TSM through those ABIs here between the TVM and the TSM So the TVM the TVM asked for an attestation report and assign attestation report and evidence that is going to send to a line party to run the full attestation dance whenever it wants you to do that and
the part of the specification the confidential computing specification defines how this attestation flow is Going to be going to be running and more importantly How the attestation evidence is going to be built out of which measurements and how this is going to be formatted
unlike TDX or ZX or SEV we do use a standard format we use X509 certificates for building an evidence so Each layer on the on the chain here from the hardware trust up to the TVM
Loads measure and certificates the next layer. So this is this is based on the specification called TCG dice It's a layered specification for building attestation evidence And this is what we use with with the RISC-V confidential computing implementation Eventually the TVM when asked for when it asked for an attestation evidence
It will get a certificate from the TSM. So the TSM builds the certificate with the entire attestation evidence that is part of the certificate as an X509 extension And this certificate is routed back all the way back to the hardware root trust for a relying party to then verify and And a test or not
Last thing I want to talk about is IO. I didn't I didn't talk about IO because it's a it's it's a chapter on its own There are two kind of virtual machine IO. There's the paravirtualized IO also known as virtual IO most of the time doing virtual IO with With confidential computing a confidential VM TDX, SEV or WIS5 is
Challenging because basically the virtual device implementation is done by the host VMM So typically your virtual net is going to be done by QMU or by an external process running out of the host user For example, so you must share memory between your TVM and your host VMM. So it's it's complex
it's it's actually not very efficient because you need a software IO TLB and you need to do a Confidential to be able to share stuff You need to harden your guests so that you can actually somehow trust the the host implementation, etc
So there's a lot of discussion around this if you go to the Linux cocoa mailing list It's a Linux kernel mainly see if there's a lot of discussion right now and the other IO surprisingly There's the the other IO Form is direct assignment That is even more complex direct assignment basically means you take a PCI device
That you don't know that you know nothing about and you add that to your TE trusted compute base basically, you you you're gonna say I want my Nvidia GPU to be part of my trusted virtual machine and to do that you
You basically need to a test and authenticate the device that you want to plug into into your TVM So there's a lot of specification Not a lot but a few specification PCI specification called t-disp and IDE for protecting the the IDE link between your device and your TVM You need collaboration from the IOMU. It's it's a very complex topic
The first one virtual one is is very much in progress the direct assignment want it's still being defined so I Rush that through I'm done. Thanks a lot for listening. I hope it was useful
And I have time for questions