Welcome, everyone, to the computer-intercom-puting dev room for this year in Fosnum.
I'm happy to have a bigger room this year, and we also can fit more folks, so hopefully
there's not going to be any occupancy problems.
But yeah, so welcome.
Who are we?
I am Flitz.
This is Jo.
And we have a third member Fabiano, who has not managed to come here, but to help organizing.
For the disclosure, I'm at NVIDIA, yours at Kalevun and Fabiano at Intel, but this is,
of course, the private thing that we organized.
And I want to use this welcome session for basically two reasons.
To welcome you to the dev room, give you a little bit of the idea of what we're going
to have to expect today.
But as a second thing, also give a quick background information for combat energy computing.
What is it?
So that not every speaker has to recap the same thing on and on again, so that we can
save some time for every speaker.
So there is the Linux Foundation's computer computing consortium.
We had a nice social event yesterday.
If you haven't heard of that, please look them up, get involved into what they're doing.
It's a great thing.
And at this point, we're going to use their definition.
I think there's many definitions of combat energy computing out there.
There's many ways to see what it's doing, what it's not doing.
There's many opinions to be had, I think, about it.
But we're going to take the definition from them here now.
And we can always have discussions about if that's a sensible definition or not.
And according to that definition, combat energy computing is the protection of data
in use by performing computation in a hardware-based, attested trust execution environment.
I highlighted the things that I think are relevant here.
For me, personally, hardware-based makes a lot of sense, or is important.
Initially, actually, this dev room was called hardware-aided trusted computing dev room.
And now we only renamed it to combat energy computing dev room last year.
Attested, maybe you've heard of it, maybe you haven't.
I think some folks will talk more in depth about attestation later on.
I don't think I will cover it really here in the welcome session.
And then trust execution environment, TEEs, are the things that basically guarantees you this thing,
guarantees you all of these properties.
And data in use is this protection of data in use.
It's one of the lenses to view combat energy computing.
This lens is basically the lens of saying we have data protection at rest by encryption in transit by TLS.
And now we also have it in use by TEEs and combat energy computing.
Now, I'm listing some key properties here just so that you get an idea of what are common between TEEs.
There's still space here, you can come in.
It's not that full, there's more space here on the side.
There are some common properties between TEE implementations, and then there are some contextual properties between TEEs.
So, commonly, most of them, or all of them I think, have data confidentiality.
So they encrypt your data and they keep your data confidential.
They have data integrity to ensure that your data cannot be changed.
And they also have code integrity so that the code that you're running is also the code that you expect to run.
So it's not being changed by the environment.
On top of that, there are contextual properties.
Not all of them, not all of the TEEs have them.
Not all use cases need them, but I think these are properties that make sense to at least the subsets of folks doing these definitions.
With the notable exception of code confidentiality.
Code confidentiality is always, I think, was initially, has a big DRM label on top of it, I think, to me at least.
Of course, maybe not everyone agrees to all of these use cases being good, but I think when looking at TEEs,
these are definitely some properties that are common.
So code confidentiality has been one use case that has been tried in the past.
Authenticated launch.
Now I'm kind of booting up something that you can authenticate.
A programmability that you can change what's running in the system.
It's not locked in.
It's the beginning of launching it.
Attestability again here.
The thing that we can make sure that what is running in there at runtime.
I can also verify that it is running.
And recoverability in case something breaks, I can recover from issues.
All right.
And now I modified one figure from one of their nice white papers.
You should read the white papers if you want to hear more and learn more about that.
Where let's take a look at kind of the common software stack and see what is shielded by what type of computer computing technology.
So for example, Intel SGX is something that many of you may have heard because it's the oldest that has been commercially available.
And that historically, the idea has been that the app data and the library is shielded.
So only kind of the application is shielded.
While the OS and the process and the TSM is kind of in the untrusted part.
So you only draw the protection boundary around the application itself.
That's a good example for that idea or for this like shielding level is Intel SGX.
And then I'm trust on, I said, Intel SGX is the oldest, but I'm trust was actually way older.
It has just been not very accessible to kind of the developers that want to play around with it.
I'm trust on has had this, I think, for over 20 years already.
Not sure.
Maybe always almost 30 years now.
Where you draw the protection boundary around the OS and in the US in a trust zone,
you have a secure world and a not secure world.
And then you suddenly can say, look, I have a switch over to secure world and I have my own whole OS running there.
And I can have multiplications that run on top of my OS.
And this is actually now being picked up, picked up by the next generation of TEs in computer computing,
where we now have, for example, I'm CCA with AMD, SVS and P into DX.
I think you will hear about these technologies a lot also today.
Where we draw the protection boundary again around the virtual machine.
And then we have some, some machine monitors, some hypervisor.
And on top of that, you then spawn up multiple machines, realms, enclaves.
However, you may name them to call it a technology.
And then inside your area, you have your guest OS, maybe some container runtime.
On the top, you have some, some applications, right?
So these are, let's say, multiple levels of depending on how big you draw your box in your technologies that you're using.
But all of them have the idea that you cannot access from the lower levels the data that is running in the higher levels.
So here, for example, the OS or the normal world OS or the TSHIM or VMM,
also don't have access to application data.
And I think that is the core idea for all this confidentiality.
And you can also have a station on top of that, that you can convince remote people that, yes, this is the case,
my host OS does not have access to my data.
And taking a lens at, taking a look at how are we doing this today?
We have three talks that are in this right column.
TDX Deep Dive, and we talk about SV Step and about Mushroom.
Then we have two more talks that are in the other domains.
It's one about FTPM, one about databases.
And then, of course, we always have talks that are really cross-cutting,
that don't really fit into these type of boxes.
That are also about attestation and how do we work with this?
Now, our dev room is, fortunately, unfortunately, has become very popular.
I thank all of you for submitting great talks.
We could only fit eight, and we were hurting for that a lot.
So I want to give some honorable mentions here to folks that we could not fit today.
So there were quite some talks about Project Verizon.
There was a talk by Thomas also last year on that.
Check it out if that sounds interesting to you.
We had suggestions about connected containers, connected clusters on open stack,
about remodestation in telecom, and about formalizing remodestation.
And I put the links here.
The slides are on the schedule.
Check them out.
I think that these are all great.
And we also didn't feel that it's justified to have our own talks up here
if you already had to reject talks.
So we did cool stuff on SGX, some small execution.
And you was trying to build some bare SGX enclaves for the community.
You can also check out these.
If that sounds interesting.
And I hope that we can start some community building around the times
when we are not all here together.
Maybe also keep submitting your talks next year.
We are trying to get a full day dev room.
I think this year didn't work because of all the dev rooms.
But in the apparent success, I think we will get there at some points.
And keep submitting talks and we'll try to get more space from the full-dom organize.
Exactly.
So we hope to have more engagement in the next years
and move bigger to a full day so that we can have more of these talks at the same time.
So this is just a schedule in short.
How do we work for the speakers?
So we always have a five-minute switch over.
And for people to have some breathing room to go in and out,
maybe have some side discussions.
And at the same time, please also leave some room for Q&A.
And so yeah, I think that's from my side.
Welcome.
Not sure if you want to see.
Maybe just a couple of practicalities.
So the room is limited rights.
But there are still spots here and there.
So people who are standing, please feel free to take a spot.
And the logistics are not ideal here.
But if maybe if you see people coming in tight to move to the middle,
or if there is like spaces left, we're not sure.
But the previous deaf rooms were really full and it would be a bit sad to kind of put on the door
that people cannot come in if there is still seats left.
So as long as there is seats left, we will not close the room.
Also in those five-minute breaks, if you want, you can go in and out.
Again, the logistics are not ideal, but we'll make it work.