So, I think I'm supposed to start right the second. So, hi, I'm Leonard. I'm going to
talk about multi-profile APIs and otherwise to supercharge your unified kernel images.
I only got 20 minutes, like everyone else here. I have some slides here to keep myself
short, but it's not a disaster if we don't go through all of them. I really like questions,
but I don't hesitate to ask them. I mean, don't ask them this. I have to answer
the novel, but please interrupt me. So, UKIs. What's that again? UKIs is an acronym
short for unified kernel images. I hope that most of you given that you came to this
devroom already know what that is roughly, but if you don't remember, it's a single
of IP binary consisting of the system you stub, if I stub, a kernel image, a traditional one
and an inner ID, a kernel command line, a device tree, if you need that, a boot
splash, if you want that, and maybe a couple of other things. But the gist is all that
together, and one of the e-binary that's a unified kernel binary. We've wrote a
spec about that. In particular, look at that. You show that it kind of formalizes
a little bit, all of this, and how the sections, like the PE sections,
P-binary sections are supposed to be called. What's the benefit of having UKIs?
Of course, robustness. There's only going to be, like if you boot, the firmware
only needs ultimately, in the best case, only read a single file of the USB
and can boot it, so that's very easy. You can update it very easily, right?
Like because you can put the file in place on a temporary name, and then sync everything
to disk and then rename it and sync it again, and that's a very simple, robust way
how you can update your kernels, which is quite beneficial. So yeah, it's also secure
in the sense that, yeah, if it's one file, you can sign it as a whole, you can
measure it as a whole, and it can be authenticated by regular firmware,
UFI firmware, authentication, like secure boot stuff, and maybe even
shim them if you have them in between. So, this is all as great.
I think I did talk about this last year or something, so I kind of hope that
everybody knew everything I had on my slides here before already.
So, what I'm going to talk to today about is about the issues with that design,
right? Like I mean, it's a fantastic design, gives you all the
reproducibility, all the business, all the security, and things like that.
But it comes at a certain drawbacks. It's not really locally,
locally, modifiable. It's a strictly uniform image.
Like, whenever you deploy this, it's going to be the same thing everywhere,
and because of all the security properties of the measurements and of all the
the authentication by a circuit boot, local modifications are not possible.
That's great for many use cases, but it's tellable for many others.
In particular, like, people on, like hackers in particular,
are kind of more used to changing things locally. So, yeah, we try to figure out.
So, yeah, in one hand, we have this beautiful uniform thing, but on the other hand,
people want to make modifications, how do we kind of make that possible?
We came up with a couple of solutions.
Like, the first one is, yes, I add-ons, like Luca added that mostly.
On the EFI add-ons, basically, these little P files that look like executables,
but actually do not contain any code. They are just envelopes with all the other stuff
that had on the earlier slides. Like, for example, Nickstra in it already.
Nickstra, kind of command line. It's mostly about the kind of command line,
but it can also carry the other stuff.
CPU microcode or whatever else.
They are authenticated because they are P binary.
They are authenticated, like, like, any P binary, like, second blue version.
Yeah. So, this is a solution number one to this problem.
There's another solution that we came up with. It's called system decradentials.
They are not authenticated by second blue and shim, but by TPN.
And it's for parameterization of systems and services.
Like, this is inherently a system to be concept.
We basically have this little bits of data that have name,
and that can, like, you lock to the local TPN.
And that can, like, they are encrypted and authenticated by the TPN.
And then they are unlocked.
The moment the service that consumes them is going to start.
This is great for stuff you need later, right?
Like, because you need a system D instance running.
And the authentication and decryption happens at the moment.
This is used, right? Like, or the service that actually wants to consume them is used.
Which is different from the EFI add-on stuff, which is authenticated during early boot when it's first loaded.
And then solution number three is also a system thing.
This thing is a system with context and system usage,
which are, like, authentic and kernel keering.
And they are basically little disc images.
And you can overlay over that scene user.
And where you can not just have little bits of information,
but you can actually add, like, a bunch of files,
autonomically to that scene user tree.
So, I'm not going to talk much about this here,
but I want to talk to those to be about this.
It's about what the other stuff.
So, this is all great.
Conceptually, all of these are side cars.
If you're so well, right? Like, you have your UK.
That's nicely uniform in a single file.
And then you drop next to it in a sub directory that is named exactly like the UK.
Just with the D at the end, the side cars.
And then the SD stub thing that is glued in front of the UK.
Goes and looks next to itself, basically, for these files, loads them into memory.
If it's the EF, I add on it.
Pull a sandicate them by a regular second boot.
The other stuff it puts up in an inner audience,
a positive crown.
So, yeah.
They extend your kind of pretty flexible session.
Like, a second boot chim kind of means that everything is bound to your distribution keys.
So, and the system credentials are kind of authenticated by,
by inherently local stuff.
And we confess this stuff by whatever is in the kernel curing.
So, these are different, like, owners of the authentication mechanisms.
But, yeah.
Still, it's pretty flexible.
This stuff, inherently local, this stuff, then a bound.
Yeah.
Might talk today, so far any questions.
So, now we're going to start with the actually interesting stuff.
Okay.
So, multi-profile e-cards, something I recently added to system D.
I mean, I think the year ago something I started working on this,
which is the fourth solution to this.
And it's new.
The idea, basically, is that we can have a little bit of variability
in what you actually boot there.
But, you still do it within that single e-KI.
So, you do not have side cards for the first time,
but you actually do it within the e-KI.
So, you basically have multiple profiles.
And the sense basically is that you have operative sections,
like previously traditional e-KI's.
You have one of each.
Like, you have one internally, one kernel command line,
one device, three and so on.
With multi-profile e-KI's, we basically allow you to have many of these.
And then you glue them together in a profile,
or in another profile, or in a third profile.
So, yeah.
Not a side card, but all inside of the e-KI.
It's still authenticated as one.
It's copied in as one.
It's just one file.
It provides a much more limited flexibility,
like because the person,
who, or the vendor who puts together e-KI,
I need to just think about all the options beforehand.
And then define a few blessed configurations,
basically, that are a combination of kernel,
in a dirty kernel command line and so on.
I think most of the time profiles are probably going to be used
for the, just for the kernel command line,
like so that they all share the same kernel, same inner dirty,
same everything else, but then have a separate kernel command line
that is a little bit different from the others.
But yeah.
Primary use case is that you have one UKI,
that with a couple of different kernel command lines,
one for regular boots, one for recovery mode,
one for factory set, one for storage target mode,
and these kind of things.
Like so, where you basically boot the OS,
mostly the same way,
except that you actually boot it to a different target
that has a different purpose.
It could be also installed or stuff, whatever else.
Like what people will come up with,
how they want to use this up to them.
Of course, these are just the obvious ideas
that came to my mind.
Systemly boot, you know.
Systemly stuff is that if I stop that I talked about,
systemly boot is the boot menu thingy that runs before it,
if you want this,
it has been updated to understand these profiles, right?
So if you, like traditionally,
if you drop a UKI and then one directory,
systemly boot will find it and put it in the boot menu,
it can choose from the menu and boot it.
System boot has now been updated to understand the profiles.
So you drop in that one file,
it has five profiles or something like this,
and SD boot will understand and create five menu entries from that, right?
One for each of the profiles.
These profiles come with a little bit of metadata,
so that you can actually put a nice string on the menu item
that is called actually recovery mode,
instead of profile time a suite.
Which profile you actually choose to boot is measured to a TPMPCR,
so that we have all the security properties, right?
This slide might be a little bit confusing.
It's the SD stuff, not SD boot that actually does the measurement of the profile, right?
So you can actually use profiles even without a systemly boot.
If you do direct firmware to UKI,
I would mention being because that in the command line and then load options,
then you can configure in UFI.
Because this is just one UKI,
you get the regular authentication by a secure boot,
and stuff like that,
and you get the measurements of the PCR,
like in PCR4 and things like that.
The measurements that SD stuff does will only cover the profile,
they actually choose though, right?
It's important so that, yeah, only the stuff actually consumed
is the stuff that actually shows up in the measurement logs,
and you can very clearly distinguish which of the profiles was actually chosen.
This kind of stuff matters because you, like for example,
for storage target mode, right?
Like this mode where basically,
like mecos had that for a long time where you can boot into a mode where
your heart is exposed as ice-cuzzing in that case,
but it's like system natively supported by NVMe because it's very easy to do that
with a kernel.
But in that case, you don't want that full description work, right?
Like you want to expose the disk as the disk,
not as a decrypted disk, right?
So it's important for different profiles,
you can have different security,
policy objects that you can bind to,
so that you can say, yeah, if I put in storage target mode,
do make it impossible to unlock the disk,
but if you boot in regular mode, make it possible.
Systemly measure, like that's this little tool that can pre-calculate
the measurements that booting a UKI will result in natively support set.
UKI, like that's our tool,
Python tool, a part of system,
that helps you with building UKI's,
has been updated to support these multiple profiles.
UKI's, and I already mentioned that profiles carry this
extensible descriptive metadata.
It's used for many items rings,
but we can later use it for other stuff as well.
Like, for example, there are some ideas about adding a little bit
of matching to that too,
so you can suppress a couple of menu items that are applied
to the local system, or something like that.
So much about profile, UKI's,
anyone has a question about this port, you have.
The profile is the section in the,
is it a combination of six sections?
So the question was regarding what a profile is,
is it is a section itself in the executable or a combination of sections?
So it's a, like, there is a section type called .profile,
and it carries the metadata,
but it just combines a couple of other sections
that are exactly like the previous, like,
a highlight at all always was.
So, basically, if you have three profiles
that all want to use the same kernel,
the kernel's only their ones.
So, yeah, it's about like,
you only have additional copies of the stuff
that you actually want to change in each profile.
There is another question.
So the question was like,
how do you actually pick the profile from system to boot in the firmware?
Like, from system to boot, I already mentioned this,
like, you just have five menu items,
and pick the one that you want,
because, yeah, one UKI will create five menu items.
This is then propagated to the UKI via the load options thing,
so basically the command line, if you're so well.
And, but it's actually a little bit tricky, right?
Like, because we don't necessarily want,
like, we don't want to measure it together with the command line,
so we actually chop it off before the measurement
and think like that anyway.
It probably, the details are a little bit too complicated,
this question.
But, long story short,
if you want to select it from directly,
if you do not use SD boot,
but want to boot directly from firmware into a UKI,
you also put it in the load options, right?
But it doesn't look like a command line switch on purpose,
like with the add symbol,
so that I make very clear that this is not considered
a regular command line option, right?
Like, it's a psychological thing.
Anyway, no more questions about there's another one.
So, do you mind to imagine being kind of scared about
that is independent of this?
Yeah.
So, the question was regarding whether
the advisory matching is independent of this,
obviously you know this.
Yeah, it's entirely independent, right?
Like this is mostly about selecting
like the focuses on giving the user a choice of different profiles.
It's not so much about making automatic choice,
we have some other stuff in store for that.
So, my next slide is actually about this.
Otherwise, do supercharge UKI.
So, this is something that we recently added as well
as an automatic choice of device trees, right?
Like, because on ARM devices, you usually want to support
more than one ARM device,
and they all need slightly different device trees.
So, somebody whose name I forgot added this logic
to SD stuff to actually do allow you to have multiple device tree
blobs in the same UKI.
And then at boot, we calculate a hash from DMI data
like the Microsoft hardware ID stuff,
CHID, is used for this.
And that picks the right one for the local system.
So, that you can basically have one unified UKI,
the carry 77 device trees, if you're as well
and the right one for your local system is actually used.
The sections, called differently than they were traditionally,
these ones called DTB author instead of DTB.
I forgot DTB, right?
To indicate that there's only one of them
chosen and it's automatic.
There's a second section type called HWIDs.
That's the part that actually contains the tables
like based on which hardware IDs pick which device tree.
Yeah, it's basically really stupid mapping from the Microsoft
CHID.
I don't know how I'm pronouncing it.
CHID, like from the Microsoft shed to the device tree
compatible string.
This is automatically selected by boot by system DTB.
It's not a user selection in this case.
This guy, I'm on here, who just asked this question,
then it's adding something right now,
like he got the most, like the key part's merge,
but it's not completely yet.
I'll bring you on firmware.
This is for confidential computing and stuff.
They kind of want us that the firmware,
like the UKI, can have control about the firmware
that's actually used.
So, the idea is basically that you leverage
the same logic as the device tree selection.
And that I firmware in UKI.
You drop that on your confidential computing VM.
When it boots out of the checks,
the firmware is actually running on the same one as
the one that it carries.
If so, it's just continue booting normally.
Like it always did.
If not, it will issue those EFI calls to update the firmware.
We'll reboot.
We'll come back and then we'll have the right firmware.
So, this is basically the idea is that if this is in place,
you can have your UKI for some,
confidential computing VM.
And you, afterwards, have the guarantee and the TPM measurements.
And so, prove this to you that you're running only the software
that you wanted to run on it, including the firmware.
So, it's kind of nice that we can reuse the same thing
that the device tree people did for embedded devices
for bringing it on firmware.
This is basically a new section called .EFI,
FW, which carries the firmware.
And then we use the .HW IDs that we already have
for the device tree stuff to do the mapping again.
And as automatically chosen,
so that you can actually have one UKI that works on the
confidential computing environments,
both of AWS and Microsoft or something like this.
Yeah.
But also interesting about this is that you can now
it is directly booting the UKI on a QMU command line,
so that you can actually test this really nicely.
Because then you basically have one UKI.
You specify the QMU command line,
confidential computing environments,
and boots up, and everything.
There's no other complexity involved anymore.
And you get the perfect guarantee that
yeah, everything inside of the VM, you can trust.
Yeah, there's another talk.
But I'm here in, yeah.
Click on that.
I mean, I'm not sure how you can do this,
but yeah, click on that.
And I follow that targets.
What is it?
Tomar.
Anyway, I only go like,
how much time left?
Two minutes left.
I have some more slides, but I don't matter.
Let's prefer, I would prefer,
for each still use the last two minutes for questions.
There's a question.
Yeah.
How do you experiment with this as a public pilot plan?
A cool bit.
If I have experience with this as a corporate,
I have no experience with this corporate.
You know, I'm this guy who runs this PC.
I only do you if I'm very boring.
Is this what the useful one has to do?
It's like, it's a long split.
I'm pretty sure.
But I have no idea.
So, I mean, the key here is really,
you know, with this stuff,
you don't really need,
like you have basically one file,
particularly the bringing on firmware,
that boots like the whole shit's right.
And that's kind of nice.
I think we have time for one more question.
No one has a question.
Was I so clear?
Come on.
No one has a question.
Nothing.
Did nobody understand what I was saying or what?
No.
I'm a little bit disappointed in you.
Okay.
Then, I guess.
Thank you very much for your time.
I have some other talks.
Yeah.
There's one about,
yeah, that where we will talk about some more stuff.
So, anyway, look at everything schedule.
And yeah, thank you very much.