Hi everyone, welcome to the first them Devroom of this year and very happy you all could make
it, it's cool to see that the room now filled up even like half an hour before, while I think
four years ago we were happy if we could fill the room, but it's really nice to see everyone.
Quick introduction to us, maybe it's definitely for beyond or you can stand up.
So I'm Fritz, this is Fabiano, this is you, this is Stefan.
Elario also joined our team, Elario did a lot of work for the social events, but I don't see her right now here,
but she'll be at some point and then she can wave at everyone.
And last year or last year it was just Fabiano and you and me, but now we got Stefan in Elario to help,
which has been great, so it's really nice to not have everything on one or two people here.
So I'll be quick, with some quick introduction and then we'll start today,
because I want to just level set everyone and help us all understand the kind of common scene,
so that we don't have to reiterate the same thing at every talk.
So we here for confidential computing and there are many definitions,
especially now that it has become a little bit mainstream,
many CSPs are using it, many folks are using it from all of the marketing people.
We'll use the terminology from the confidential computing consortium,
that is not out of nothing, we also partially involved with that consortium,
so it makes sense to be close to that terminology.
According to that definition,
your computing is the protection of data in use by performing computation in a hardware based,
a tested trusted execution environment.
Now I highlighted some pieces of this because if you remove one of them,
it's not confidential computing anymore.
For example, a station is a core part, hardware based,
hardware root is also a core part in this definition of confidential computing.
You can't just do something in software and pretend now it's committed to computing,
you need the hardware, you need to root it in something and have it.
And kind of this TE term, of course, is the end result of that.
There are multiple properties,
some are shared between all of them,
and then depending on what the use case you have,
you may have some additional properties, right?
So data confidentiality and integrity is the core piece of it,
and then also code integrity.
You don't want your code to be tempered with,
or your data to be tempered with,
and also you want your data to be secret.
Depending on what use case you have, this scenario.
You like it when you see it, you can hear it.
Thank you.
Depending on the use case you have,
you may also want to have code confidentiality,
but that is not the property shared by all of the confidential computing solutions that we have,
right?
Some people may probably see that, but that doesn't mean it's always existing.
Same like a testability actually,
you can have some variation of this,
and so that's why I put it into contextual,
it may depend on what you want to test, et cetera.
And so I'll leave it in the new that at that,
and I will just now go on to saying a little bit of what different technologies we have out there,
to give you a quick overview of the landscape,
and then you'll see in a minute why I do that,
because we can map it nicely onto the talks.
So there's different technologies that do isolation on different levels of the software stack,
right?
So in the last JX, it's the thing that has been,
or the enclave technology that has been out for quite some years nowadays,
and that's isolation on a library and application data level,
where you build on top of an untrust of the OS,
and then you only shields the core enclave,
the core application data.
A different technology is untrustable,
which has existed for quite some years already,
and here you have the SQL address type of shielding,
where you have a secure route that you switch to,
when you want to go into your secure states.
You have one untrustable and one secure one.
And now similar to kind of this VM or world,
like view we have new technologies,
like RCCA, AMD, SCVS and P, or JTDX,
that do the shielding on a similar level,
but you can do multiple of these secure routes at the same time.
So you have a whole guest address in your shielded environment.
You can have container run times on top.
We have lots of talks today on that,
and then you can run applications on that.
So these are different levels of isolation that you can spin up.
And let's try to map that now onto our devrim schedule.
Now I did this last year and it worked great,
because we had a little diversity stack,
but you can already see a little bit here,
what I needed to make most space for,
because most of the things we do today,
and the most of the talks we have today,
are on the VM type level.
And I think that just shows a nice trend,
and I guess next year I will need to find a different way
to depict them to differentiate ourselves,
because most of the talks we have are on that.
And we only have two talks this year,
one on the SDX level still.
And then I was told,
Spock risk 5 doesn't really fit anywhere,
so I'll just put it squarely.
And let's see, let's see,
let's see the talk yet.
So let's see where it fits.
I'm actually a little bit faster, that's good.
So that gives me some time to just take a look at,
wow, we're going with this, right?
So last year, we had 25 submissions,
and they accepted.
That was, we were happy to see that we were growing.
This year we had 15 submissions, and I accepted.
This first glance looks less submissions than we had last year.
But we were also working together with the
a station bedroom, right?
And we were able to kind of separate talks
between the station and conventional computing,
and they had 23 submissions and they accepted.
And nightly enough, we also had at least two hours
to see where the talks are listed in a second.
In the rooms that are not in hours, right?
So I'm very happy to see that we're growing.
We have 40 submissions related to
computer computing at least.
And somehow for them now, who's 19 talks,
and maybe more than I didn't quickly be able to find
based on some common keywords.
So that's really cool, and I'm really happy to see that the community
seems to be growing, and I'm really happy to see that
also the open source experience isn't
diminishing and slowing down.
So this is the station bedroom schedule.
Check it out.
It's tomorrow at 8 a.m.
I think 9 a.m.
9 a.m.
And you can also see it just in the schedule track.
So go there.
It's going to be some really cool talks here.
I have some quick on other dimensions,
because I just wanted to list these two talks that I did find
that I'm not an hour at every room.
So there is enabling a NVSEV technology in the
Xeniprovisor.
It's in the virtualization and cloud infrastructure
at every room on Sunday.
And then there's also a latest implementation of
NVSEV S&P and OVMF.
That's actually today, but you can always check out
the recordings once they become available.
And also, I wanted to give a big thanks
in our class, or also people that submitted
but couldn't be couldn't fit, because it's always a hassle.
And then we always feel bad about rejecting some talks,
but we're happy to have also some of them
in the lighting room today.
Thank you.
Finally seeing how he's also presenting tomorrow
in the virtualization direction.
Great.
Okay, so there's some overlap here between the
Fookie here we have, and the virtualization
developed tomorrow, that just shows that our community
is starting to breach out into other domains,
and it's not just us security nerds doing stuff anyway.
Was that?
This is a quick schedule, while Sal can come over here
and get situated.
And I'm very happy to, yeah, start the day with this.
And we'll have, I think, around,
let's see, ten minutes, always five to ten minutes
between every talk.
So the Q&A can reach a little bit into it,
but then please give the speaker some,
space to, to set up while we set up some QA
and move in and out.
And we'll also make sure that these five minutes
people can freely move in and out
because we also don't want to hog your hog our seats here.
Okay, thanks everyone.
Thank you.