So before the 35 minutes, you mean?
So you have your schedule to stop at 14.45.
So you give me a give me a heads up.
You can do it at 35.
OK, yes.
Sounds good.
OK.
All right, people.
Let's do the second vlog today.
I'm very happy.
I'm actually excited about this talk.
So Samuel from the RISC-5 company
will talk about what's going on in the RISC-5 landscape.
And I think, yeah, I'm excited for the next big step
in our community, right?
From open source software, open source hardware.
So take that away, Samuel.
Thank you.
So yeah, I'm Samuel.
I work for a company called RISC-5.
It's a startup that does RISC-5 things.
And today I'm going to talk about confidential computing
with RISC-5.
And how do we do want to implement, well,
an open source implementation of confidential computing?
The previous talks I've mentioned are things like OPTIE.
Some of them I've mentioned things like SGX or SCV.
Those are all hardware implementation
of the security attributes that the first talks about.
Confidentiality, protection of memory,
confidentiality of data in use.
And this talk is really about how we want to achieve that
with RISC-5.
And the difference between the RISC-5 implementation
and all other existing implementations
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.
OK.
Who was on the RISC-5 dev room before?
OK, so that's needed.
RISC-5, what is RISC-5?
RISC-5 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 free.
Everyone can use it, can build a CPU out of it
without paying in license, 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 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 frozen, that's ratified
and accepted by the RISC-5 International Foundation.
They're ratified and some modification can be added to it,
but 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 quite interesting.
And yeah, the specifications are released under an open source license.
There are two volumes for the specification.
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 move instruction.
So it's a good comparison.
So yeah, it's very small.
It's easy to read.
Just go ahead and grab it.
And yeah, the spec is split into the unprivileged
and privileged specification.
And I'm going to talk about this next.
Why is the RISC-5 ISA interesting?
So first of all, it's simple, as I just said.
If you look at the 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 actually 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, Multicore,
SOCU actually massively Multicore, SOCs, it's the same spec.
So 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 UCPU
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 the backward compatible way.
And extensions are optional.
So 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 very small.
It's easy to read.
Oh, kind of.
Not on that slide, but it's easy to read and it's small.
I talked about the spec being split between privilege
and unprivileged parts.
And I'm going to talk about privilege mode, which is what is
defined in the privilege specification.
I'm going to talk about this because it's relevant, really
relevant to the confidential computing implementation.
So there are three basic privilege 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 M-Ret and S-Ret.
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 CIS-Call, basically.
So to implement CIS-Call, you're going to use the E-Call instruction.
And if you're in the kernel and you need firmware services,
you're going to make another E-Call,
and you go down in the privilege level and you're more privileged.
To go back, to go up and move to a less privileged world,
you're going to call M-Ret from the firmware world,
from the machine mode.
And you're going to call S-Ret to get back from a system call.
And as I said, those mode actually maps to real use cases,
what we typically use 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,
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 that have been added
with the hypervisor extension.
So there is an extension to the base RIS5 ISA.
It's called the H extension, H as in hypervisor.
And this is an extension that's been added and is frozen.
So it's something that is not going to change
for supporting virtualization.
So the mode that I've been adding is the HAS mode,
the VS mode and the VU mode.
So you can see in this diagram,
you can run your application as usually in U mode.
And then you're going to have your hypervisor,
your host kernel when the extension is enabled,
it's going to run not on S mode but on HAS 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 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 did like a scratch course in five minutes of RISC-5.
So I hope this makes sense.
But anyways, I needed to do this to kind of explain
where we want to go with confidential computing on RISC-5.
So what we're defining currently in RISC-5
for confidential computing is called the AppTE RISC-5 specification.
AppTE as in application, processor, trusted, execution environment.
So it's a technical group where everything, again, is open.
So there's a GitHub repo for this technical group.
All specifications are there, the discussions, the minic nodes, everything.
And it is not ratified yet, not frozen.
So this is a work in progress.
So again, feel free to come and join and help
and provide some feedback on that specification.
But it is aimed at becoming the reference
confidential computing architecture for RISC-5.
So it's currently in a pretty late state.
It's going to be ratified, not ratified, but accepted pretty soon in a few months.
But it's going to be the reference confidential computing architecture for RISC-5.
It's not an ISA specification.
So we don't add to the RISC-5 set of instruction and architectural definitions.
But we do identify a few ISA gaps.
For example, what we call the confidential memory attributes,
which I'm going to talk about later.
And just to clarify things, because we talked about OPTE,
for example, there's an implementation of OPTE for RISC-5.
The OPTE specification for RISC-5 is not aiming at the same set of use cases.
OPTE is really trying to do and support the same use cases as TDX,
for those who are familiar with TDX, or SCV, for those who are familiar with this AMD technology.
And basically, this specification is defining a new class
of trusted execution environment for RISC-5.
And these new class are trusted virtual machines.
So same as TDX, so same as SCV.
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 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 SCV or TDX.
So there are really two different set of use cases,
and OPTE is aiming at this specific set of use cases.
So there are a few architecture components that I'm going to talk about.
An OPTE beats per heart, sorry, I didn't mention this, but a heart,
HRT in RISC-5 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 security manager, the TSM driver,
there's a dependency on the hardware root of trust,
and there's a structure,
a non-ISA-specified structure called the memory tracking table.
And to go through all these components and kind of explain what they are
and how they're put together to reach 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 call start of a RISC-5 SOC,
we could actually build a trusted virtual machine
with the confidential computing architecture that I'm trying to describe.
Okay, so we have a RISC-5 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-5.
It's basically RISC-5 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-5 SOC that's running there with an IOMMU.
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 thermal 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-5 SOC,
the apt-e bit, to tell if the heart is currently running in confidential mode
or non-confidential mode.
So there is apt-e bits that is part of the specification
that tells at any point in time if a specific RISC-5 core, RISC-5 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 does that.
And basically, 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 TEE call, which is 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 apt-e 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 TEE security manager, sorry.
And to do that, it calls the MRET instruction and moves 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 memory tracking table is not specified
in the confidential computing specification.
It is up to any implementation to decide what it puts in this memory tracking table.
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 to take back,
the memory tracking table lives in confidential memory.
So the memory tracking table lives in a piece of memory that is protected
from the non-confidential world to actually see or temper with.
So it's encrypted, protected, integrity-protected memory.
So the memory tracking table enforces the confidentiality memory attribute
for each and every page on the system.
So 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.
So with this memory tracking table, anytime you want, for example,
the non-confidential world is trying to access physically a page,
the memory tracking table 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 QMU, from your KVM, then the memory tracking table is going to tell you
this is a confidential page, and that's going to generate a CPU fault.
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 physical page.
And you can decide how you want to implement this, how many keys you want to support,
if you want to add one key per TVM or multiple keys,
or it's up to 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 integrity.
And 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 the last privileged mode,
the TSM, the TE Security Manager.
The TSM lives at the same level as the Linux kernel, as KVM, as the IPervisor, basically.
But it lives in confidential work.
It lives and runs out of confidential memory,
and it's only run when the RIS5 CPU is running with the apti bit on,
which means it's running when it's in confidential mode.
So the TSM, I don't know if people here are familiar with TDX,
but there are some similarities here for those who know TDX, unfortunately.
So TSM, it's the TE Security Manager.
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 nothing from the confidential world can actually touch a trusted virtual machine
without going through the trusted, the TE Security Manager, the TSM.
One very important thing that the TSM does is it manages all the second-stage page tables.
So the page tables that allows you to translate TVM physical addresses to host physical addresses,
those 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 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 going to be called by the host VMM.
It doesn't run by itself. It's not something that schedules TVM or handles interrupts
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 host,
from the host VMM, and replying to it.
And we do have an open source implementation for this.
So it's called Salus. 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 TSM also manages the entity.
So whenever the TSM adds a page to a trusted virtual machine,
it's going to add entries to the entity and it's a little bit more complicated than this
because it needs to go through the TSM driver.
But basically the entity is something that is owned by the TSM driver and by the TSM.
Okay, so TSM driver started.
It loaded the TSM.
At some point we have a host OS, a Linux kernel with KVM that starts.
It puts some non-competential virtual machine.
And at some point someone is going to be starting a trusted virtual machine,
a virtual machine that runs in confidential world.
And to do that, there's a set of ABI's between the host VMM on the left,
the non-competential world, and the TSM.
And that goes through the TSM driver.
The TSM driver is the trusted piece that actually proxies each and every request
from the non-competential world to the confidential world, to the TSM basically.
And those are called the TE host ABI's because there are, it's a set of binary interfaces
that are called from the host to actually manage and request security features from the TSM.
Everything is proxied through the TSM driver.
So the TSM driver traps the host sending E-calls, SBI calls,
and basically it traps the calls from the host VMM, from KVM, for example,
and it then schedules the TSM to actually run and handle those calls.
So a few examples, creating and destroying a TVM context,
converting confidential memory to, non-competential memory to confidential and vice versa,
mapping pages from non-competential 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 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 ABI, the ABA between KVM and the 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 then start configuring the TVM.
The next thing a 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 for the TVM that it's going to create.
Those second-stage page tables are living in confidential memory,
so they cannot be handled, they must not be handled by KVM, by the host VMM.
So KVM donates pages to TSM, and the TSM is going to use that to build those page tables.
It's not meant to be used by the TVM memory,
it's meant to actually track the second-stage page tables for the TVM.
Then KVM is going to tell TSM that some memory region needs to be reserved for the TVM.
So that's basically 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 creation in step number three.
The last and next thing that KVM needs to do is to create TVM CPUs,
because basically all the CPU state is contained 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 ATVM 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 TSM.
The TVM never talks back directly to the host VMM.
It only talks back to the TSM.
The same way a non-confidential VMM exit would be trapped by the host VMM.
A confidential TVM VMM exit, for example, or any service that the confidential VMM needs will be managed by the TSM driver or the TSM.
So there are a set of ABI's between the TVM and the TSM.
And, for example, a thing 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 ABI's here between the TVM and the TSM.
So the TVM asks for an attestation report, a signed attestation report, an evidence that is going to send to a lying party to run the full attestation dance whenever it wants to do that.
And part of this specification, the confidential computing specification, defines how this attestation flow is 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 SGX or SCV, we do use a standard format.
We use X509 certificates for building an evidence.
So each layer on the chain here from the hardware that will touch up to the TVM loads, measure, and certificates the next layer.
So this is based on a specification called TCG DICE.
It's a layered specification for building attestation evidence.
And this is what we use with the RISV confidential computing implementation.
Eventually, the TVM, when it asks 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 exception.
And this certificate is routed back all the way back to the hardware world trust for a relying party to then verify and attest or not.
The last thing I want to talk about is IO.
I didn't talk about IO because it's a chapter on its own.
There are two kinds of virtual machine IO.
There's the power virtualized IO, also known as virtual IO most of the time.
Doing virtual IO with confidential computing, a confidential VM, TDX, SCV, or RISV is challenging
because basically the virtual IO device implementation is done by the host VMM.
So typically your virtual unit 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 complex.
It's actually not very efficient because you need a software IO TLB and you need to do a buffer bouncing between confidential and non-confidential to be able to share stuff.
You need to harden your guests so that you can actually somehow trust 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 mailing list.
There's a lot of heated discussion right now.
And the other IO, surprisingly, 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're going to say, I want my NVIDIA GPU to be part of my trusted virtual machine.
And to do that, you basically need to attest and authenticate the device that you want to plug into your TVM.
So there's a lot of specification, well, not a lot, but a few specifications, PCI specification called T-DISP and IDE for protecting the IDE link between your device and your TVM.
You need collaboration from the IOMMU.
It's a very complex topic.
The first one, Vert IO1, is very much in progress. The direct assignment want, it's still being defined.
So I rushed that through. I'm done.
Thanks a lot for listening. I hope it was useful.
Thank you so much.
And I have time for questions.