Hello and welcome. My name is Andrin. I'm a PhD student in the secure and trustworthy
systems group at EKH Cirque. And today I'd like to introduce you to open CCA, a framework
or a tool that we've been building to help you to research on RMSCCA and existing hardware
before CCH is actually available. So quick spoiler, I brought the box, this thing here.
And later in this talk we'll attempt a live demo and put a confidential virtual machine
on open CCA and run some cheaper workloads on it. But more on this later. So the main challenge
today with RMSCCA is really that for most of us there is no CCA hardware yet available
you can just buy and tinker with it. The first rollouts, if you check online, they're likely
data center first. So if you check, you'll see that a bunch of companies, including which
it's Microsoft and also likely in video, they all have announced to provide CCA capable CPUs
for the cloud. But even then it's unclear how open affordable and heckable those platforms
will be. And so if you want to do research on CCA, you typically have two choices today.
One choice is software simulation. So you're thinks like the RMSCCA or QMU. This system
is simulator and entire CCA, you're at the hardware stack in software. And this is great
to validate the correctness of your new research design and also great to validate the compatibility
of how your camera code will run on the next generation of hardware. But what software simulation
is not good at is that it does not tell you anything about how fast your camera code actually
runs. All you know is that you run your instructions correctly, but you let any further insights
into micro-architectural effects like cycles. And so since people also care about cycle, performance
and overheads, what they typically do, and this is also in the context of research, is that
they use their design. They have now run on software simulation and they transplanted
to arm-version aid boards. So the current iteration of arm hardware. And the inside here is,
in many ways, CCA hardware will run similarly to how existing hardware works. So this
can be used to estimate the performance overheads. But this comes with its own set of challenges
because typically these performance prototypes that people are building, they are not open
sourced, making it difficult for others to reuse, re-reproduce their work and in general
which is ways a lot of engineering, since everyone sort of builds their own thing. And
yeah, that does not open sourced it. And so with open CCA, we tried to solve some of these
pain points of these performance prototypes that people are building. By providing some sort
of open baseline to measure and run research designs on open CCA, along existing hardware.
And so at the high level we are trying to accomplish the following goals. So first, we want
to keep the changes to the RCCA reference stack as minimal as possible, while also ensuring
correct functionality on arm-version aid hardware. So this means we want to run confidential
virtual machines on existing hardware. Second, this is very important. So we cannot
give the same or we cannot give security claims of RCCA. This runs on non-CCA hardware and so
this is only for benchmarking and synchron with real devices. Third, we tried to target affordable
and open arm-version aid boards. So the barrier to entry is low and everyone can try to replicate
our setup. And fourth, we tried to focus on the reusability aspect of a framework
in the sense that we tried to be not forged specific as far as this is possible, so that our
work can also be pointed to different boards. So now that we've seen some high level goals, let's
take a look at how we actually building this. And for this, let's recap a bit on on CCA background first.
So you probably noticed the 14 introduction of arm-version 9 we had trust zone that divided
compute into the normal world and the secure world. And now with the introduction of arm-CCA
or in particular a hardware feature called the realm management extension, the architecture
introduces two mobiles. So we have the realm world for CCA's version of confidential virtual machine
machines and we also have the root world for the most privileged firmware code.
Now what's great about the arm architecture is really that it's very explicit.
So we can write firmware in codes and most things are not hidden in closed microcode.
So in open CCA we tried to reuse the reference deck as much as we can while also keeping the changes
small but how do we actually do this? Since we only have the normal world and the secure world
on arm-version 8 hardware, we emulate the realm worlds within the architectural normal world
and the secure world within the root world, sorry within the architectural secure world.
And so at first glance this might seem straightforward but things can get messy quite quickly
because CCA firmware expects certain hardware features to be available and while these are clearly
not present on version 8 hardware. And so this essentially boils down to how do we emulate enough
of these missing hardware features in software to make the firmware believe it's actually running
a real CCA environment while also keeping the changes small. And this essentially means in code
this that we got missing hardware features in in codes and either re-implement them
in software if they're strictly needed to boot confidential virtual machines or we forced
disabled them if they're not strictly needed. And so in our paper and also in code we're going
to much more details how we actually do this but let's take a look at one of these missing hardware
features that are not available on this board. And so this is a hardware feature called TTSC
stands for short translation tables. It's an optimization for the MMU. If your address space is
small with this hardware feature the MMU does not have to do as many page table walks
and so the the page block is faster. And for this let's take a quick look at the memory layout
of the trusted type of devices as the RMM. So on ARM we have two translation table base
registers. We have TDBRC or N1. This is similarly to MCO3 on X86 and the memory layout of the RMM
decides to use TDBRC or things that are mostly identity mapped and shared across course.
And TDBR1 for things that are not identity mapped and per CPU. Thank you.
And so the inside here is in so the RMM only touches a few megabytes in size for TDBR1.
So they use hardware feature so this TTSC. And so the challenge here was that all this feature
is not available on 8.2 so the version that we use. And so the challenge was how to find this
this since the TDBRC crashed and it was only shown in the way out the page structure was filled.
And so the work count here is that we exploit what ARM version 8.2 has which means we increase
TDBR1 to spend to a larger virtual memory size and then we can exploit what the hardware has to
actually make the memory work. So in 2025 we looked into around 40 different boards for this project
and we picked the RK3588 by a rock chip in particular the rock size B model. It's a great
as a season. It has open EL3 so we can flash VMware code. It has good documentation and it's also
somewhat affordable with the 16 gigabyte version starting around 250 US dollars but I think for
gigabyte RAM starts at around 100. And so as I said it's based on 8.2 architecture has
Cortex A76 and A55 course and yeah this is also what I brought today with me.
So currently we are able to boot confidential virtual machines on a stack that's maybe a year
old so it's based on TFA version 2011 and the RMM version 0.5. We have someone that looks into
pulling in the latest changes I think currently it's 0.8 for the RMM and totally we touched around
2.5,000 lines of codes and only enlighten at the FA and the RMM so we don't need to change the
guest or the host or the VMM and so in this 2.5,000 lines of codes this is mostly or to a
large percentage it's board definitions in the RMM and also I think reported the console drivers
of the effective change is actually much smaller than this. Now the OpenCistware project went
for several iterations you're now at the point where we have these stacked boxes in our
lab that include the Raspberry Pi to streamline the firmware flashing and power management on the board
and the edges making working with the platform more easily. Okay so this brings me to
the live demo and the way I want to structure this is so in two parts first that will show you
what the demo will show and then I will tell you what I had to change on top of OpenCCA to make
the demo work. So in the demo we'll boot the confidential version of machine on OpenCCA
I think with one VCPU and 512 mbps of RAM and then we'll attach the Mali G6010 so there is
an integrated GPU on the board we'll attach that and then in the CVM we'll start X and run some
OpenGL benchmark on the GPU and so the purpose of this demo is really to show how easy it is to
prototype systems research ideas on OpenCCA so disclaimer this is not trusted I.O. on purpose we
leave the GPU MMIO hypervisor shared so this is mostly so I think I have to change the ARMM
this uses Mali-LAR ARMM APIs your mathematics goes to the hypervisor and yeah so I had to prototype
and VFI were inspired into app routing and then also create a Stage 2 mapping for the GPU so
the driver can actually talk to the GPU in the CVM yeah so there's a QR code for all the demo code
that I wrote on top of OpenCCA here in this QR code all right so now let's see if this works
so first I will mirror my screen okay so what we're seeing here is I have now UART output and
I mean the normal world in the untrusted hypervisor so this KVM Linux and so as a first step
I will detach the GPU and see and then I will now use KVM tool to boot around the end
with these changes that I introduced before so we create Stage 2 mapping of the GPU MMIO and we have
an introproctor that now forwards the physical introps of the GPU into the CVM if they're
right we also changed KVM tool okay this to create a device to entry for the GPU for the CVM okay so
we are now in the CVM and we we see that it did a bunch of random management interface and
random service interface calls okay let's go on and so as the next step now in the GPU
and so in the CVM I will attach the Pantro driver and use TigerVNC server to spawn X
so you can see here since we created the mapping the the Pantro so that's the GPU driver can actually
talk to the the GPU and TigerVNC server now exposes VNC over TCP IP so now on on my laptop
I can now connect to the CVM or over VNC so now we are in X in the real VM and I sketch some
OpenGL demo for fasting if we take now a look at Proc introps so this does
cat on Proc introps we see that the Pantro driver receives introps to submit or complete
a GPU rendering drops and so if actually now hides this window we see that in no longer
it's been no longer received introps since GPU is no longer used for this open shell rendering
and so so now we are in the in the CVM so this runs a 612 kernel with I think CCA
guest enlightenment version 7 and in our D message we'll see that the RM explosives
to interface version one on the CVM
So, if you work with RMCC, and I'm going to talk about RMCC, I'm going to talk about RMCC,
my talk. So, if you work with RMCC, and are currently constrained by some of the limitations
that self-dress emulation gives you, or want to think with real devices in the context of RMCC,
please check out OpenCCA. We have documentation on how to build one of these boxes online,
and our forks of the upstream wrappers on GitHub. We also have an academic publication that goes into
more details how we build this, and if you're excited about this, please reach out. So, thank you very much.