Music
Piccadron is done, who's going to tell us
everything about what we need to do
to be the zenarch of the traditional
Ashillis, that's up to it!
There ya go!
That's right.
junto with Ashillis
h
Hi!
Uh… hello?
So, leave us into the video
questions questions.
We.
Alright, inn
not great. So then let's go to who wants their distribution or themselves to use all the
stuff that Lena was talking about in a C-TM dog. All right, that looks pretty good.
Who is actually using this stuff that Lena is talking about in a C-TM dog?
No, not very great. So lots of you want to use it, not many are using it yet, but before
you actually start using it, we need to talk. We need to have a chat. We need to talk about dog
fooding. What is dog fooding? It's the act of using your own software. What is the state of
dog fooding in system D then? It's a good question to ask, right? And so let me start with just a picture.
Right from the secret internal system D maintain a chat. Like this comment that you're using
Rm0 and not Sudo anymore. 18 fat only one of them actually liked it, which was mean. So we have
this Rm0 thing to replace Sudo, but is any system D maintain actually using it? I don't know.
There we go. Not yet. Of course, Rm0 is one tool. So it's not a proper measurement of
whatever dog fooding correctly. So there's a list of Linux inventions. Right, there's unified
kernel images, the old stuff, GPT Auto and then the new stuff, PCR log and all the other stuff,
Linux has invented over the years. It's not all of them. And the list might have been chosen
to make them look bad, but we'll see that in the next slide. So let's take a look like what is
Linux actually using according to my guess. I think it looks like this. So Linux runs stock for
door workstation installed last time I asked, which is sure Yavkrab setup because for
door doesn't encrypted with this. He uses HomeD, he didn't know that. And he gets rid of Krab as
well and replaces it with system D boot. So that are the good things, but then the other stuff
is not really used at all. Yeah, to develop, but not to manage your system.
Yeah, and then let's do it. Yeah, so 1.0 PCR like a unified kernel image, so I wasn't sure. Are
you using unified kernel images? For the actual, yeah, for the list for door, it doesn't do it, right? So
that goes rather PCR log, I guess, isn't used either. So that's for that as well. But 1.0 is green.
So the overall conclusion is like, there's a lot more red than there is green, right? Which is
not not great. Of course, we can just single a lot at Leonard. So I asked or I'm first
or some other system D maintenance as well. Look, I'm using unified kernel images on a slaptop.
I know that Zibigno is using make-or-side inner ID, so make-or-side becomes yellow because
make-or-side inner ID is only a little bit of the all the stuff you can do with make-or-side.
I know Mike is using system the GPT operator and credentials. So it's a little better, but still
a lot of rats, right? Nobody's using gravity. Nobody's using signed PCR policies on a laptop.
And the extension stuff isn't really being used either, because again, by would you, you have
like a rideable user partition, so you just DNF upgrade to get your updates. There's no need for
all the extension stuff. Why is this problem? So what happens is we merge a lot of new stuff with
public APIs, but there's nothing immediately using that stuff. The public API then goes into
this in a stable release. And we guarantee backwards compatibility, so once that happens, we can't
change it anymore. We wait a little while. Someone tries to actually use the interface and it turns out
it doesn't exactly do what's needed or needs changes or it's just incomplete. It's not often that
like the interface is wrong. Most of the time it's just incomplete and there's like, you find out
some important thing is missing for you to be able to use it effectively. And then we have to figure
out how to either fix the interface or just complete it. This is pretty generic, like what
it actually ends up looking like in practice, is that Lana, this is one merging all this public APIs.
I'm the one trying to use them. I find out they don't work, and I have to complete them. Not
amazing. So how do we make Lana talk with system D or in other words, how do we make Lana
to his own consumer of his own stuff? It seems that the duration is fine. It seems that the situation
is fine. Yeah, yeah, yeah. So all we need to do, of course, is create system D's own distribution
rights. Like we reject the Unix philosophy, right? We've stolen DNS, we've stolen that work,
we've stolen in it, we still have everything, so why not steal the distribution as well?
That was a joke.
Yeah, this slide is the one I expect to come on for our next. We'll see.
We can't reinvent the entire real one we do this, right? It's just me. I don't have time to
repackage the world. So we need to reinvent the real a little bit, but not completely otherwise
that we'll never get done. It needs to be known because Lana is a known person. So if it doesn't
have known, we'll never get Lana to use it. It has to use as many system D tools as possible,
because if we're not using system D tools to build it, then we're not getting the dog feeding
in the first place. The more system D tools we use, the more we exercise the interfaces and the
implementation, the more bugs we find, which I hope we've fixed before it gets into the hands of
users instead of after it gets into the hands of users. Using all the system D tools
is in itself not enough, because if we package this with a system D, or if we use a system D
stable release in this distribution, or at least in the version of it that Lana will run,
it's too late, right? The public APIs we've been merged already, backwards combatability
guarantee, and we can't fix them. So it has to run system D from straight from get main,
so that we can immediately start using the new public APIs in the distribution,
exercise them, make sure they work, fix them if they don't work before we're tied by backwards
compatibility. And we have to enable easy acting on system D and the distribution itself, because
we run Lana to run this, Lana needs to be able to behave on system D, so this needs to make that
possible. We also run Lana ideally, not to just work on system D, but also implement all the
stuff he adds to system D in the distribution, so that we have the end-to-end thing
completed, and he gets to immediately consume the API C adds instead of waiting for any distribution
to eventually hopefully picked out. And as for because the mice will, I don't pretend to know
what Lana needs on his laptop, so, right? Yeah, I mean system D, yeah, needs to be on there,
I don't know what packages he needs or whatever, so I'm not going to pretend I can know,
so it's just needs to be customizable, so that if anything's missing Lana can just add it himself,
customize whatever it wants, so that he's happy with the system. And of course, while Lana
does extremely afraid of evil mates, he says, so we need to do the secure measure, put it to make
sure that he can sleep soundly at night. So then we get to particle of us, which is basically
the implementation of all this requirements. It's in a mutable image-based distribution,
like, again, all the stuff, Lana wants really. It's a mutable in the way that slice user is
immutable, at sea, and the root partition is the encrypted, of course, but writable, and then
slice user is redownly the invariant, like the way Lana has described it in countless of talks,
as well using make-away size, so like why it's a system D tool, it uses a bunch of other
sets in the tool, so we use it, because we know it, and it forces us to do extra dark fooding.
There's an odd version, because I like arch, there's a fedora version, because fedora,
a letter of likes fedora. We have GD and no, again, Lana likes no, I like GD, so there's still other
versions. And then it's self-signed, so this is where it starts to differ a bit from the regular
or other immutable distributions. The other immutable distributions are very much focused on being
something that is built somewhere on a built machine in the cloud, or like on a server somewhere,
and then you download it, with, I don't know if any, in the world's version already completely
does this actually, but the idea is that you get the key from the fan there, the sine and key,
you enroll that into your UEFI firmware, or you get these small quinnets, like with the whole shimting.
Which is not great, but the problem with that is that you can control what goes into the
image that way, because it's all signed by the distribution. With this, with this, we do self-signing,
so that you sign it, which means you control what goes in it. So you get full control,
like you customize the image, however you want, you sign it yourself, and your computer will only run
the stuff that you sign, and not whatever the distribution sign. So you get back some, I think you
get back on troll, I don't think when we, like the whole world seems to be moving towards
immutable distributions, but I don't think we want to end up in a place where we're all using
distribution keys in our emrolling distribution keys. I think we always want to make it possible for
users to sign things themselves, so that they retain full control if they want to do so.
I don't think the vendor provided key sting is bad, I just need to think we need to make sure that
the other way is also always possible, otherwise you can end up in like awkward and not great situations.
And so, like I said, you build it yourself. So you don't download the image,
when there's an update, you build the update yourself on the system, and then install it, reboot,
and you get into the new version. That's where we're developing this stuff.
So basically, it's a wrapper with a giant make or second configuration that sets all of this up,
and with a documentation on how to install it. So let's take a look at some workflows
to make concrete how you would start running this stuff. Installing make a size as simple as
clone the wrapper, put it in your path, and you can use it. Free deployment. So you have an existing
laptop, you want to build the image to install on any device, right? Let's stop laptop or whatever.
Clone particle OS added make or set a local account, that's where you can put all the
customizations. So any make or size setting, you can just configure where you add packages,
you add files, you switch the file system, whatever you can think of, you can do it.
Build the image, then you end up with DDI with three partitions. So the ESP is there with the
signed UKI in it. You have the Verity partition for slash user, and you have the actual slash
user partition itself with your image in it. No route partition or anything that's created on
first boot and locked against the TPM the way, let us like once it. And then we have like a
burnt command to just like it's basically, it's a DDI but a little smart. And then you get it on
you to your USB right away. Actually installing it the first thing you do is you set a UFI password.
If you don't, the entire thing is pretty much useless because like an attacker will just
go into the BIOS disabled secure boot and what's the point. So you need a UFI password.
You need to put secure boot and set up mode. Set up mode is basically, it gets rid of the existing
keys and puts the secure boot and a state where new keys can be enrolled.
Once you do that, you boot from the USB. There will be a, you'll get it to a system
deboot. There will be a very nice and roll secure boot keys menu entry. You select that
and system deboot will automatically, well, not automatically. The other one will roll the secure
boot keys for you into the system. Again, do this automatically, but there's a lot of horrible
UFI firmware out there. So we don't do this by default, right? We make it a explicit choice.
It will tell you that this might break your system. In this case, it won't, but I'm going to be safe.
And then you have secure boot setup. That means you can select the install of UFI for
FunX and it'll load. The installer mode is basically meant for USBs, like it's not. So the
image is on a USB, but it's not to find all destination where you want to install it. So you boot
into the installer UFI profile, which means that wood partition all that stuff doesn't get created.
You just get into a shell where you can actually install it to the disk you want it to. So
it'll auto lock you in this route and you can just run system deboot after that to actually deploy
the image to the disk that you want to own. That is right because that array is your drive. We don't
tool boot yet. They're installing to existing systems. So currently you have to erase what
is on a disk to be able to install this. And then you reboot. And then this is what your
disk will look like. So we have those first three partitions that are
were in the image. Those just got copied to the target disk. And then we created the whole bunch of new
partitions. A very partition and another use partition. So those are the B partitions. Right,
this is an A, B setup. You install to the B partition, the update. And now you switch to it.
So our partition I created, I created it against the TPM wood partition. I created it against the
TPM and the separate home partition to be used with not encrypted but to be set up to be used with
the system deholding. First boots, I mean pretty simple. You select the regular UKI profile
system de first boot runs, asks you a bunch of questions, a couple first boot runs and sets up your
home for your regular user. You log in. You change your bunch of home de-settings because the
defaults will horribly break and absolutely not work at all. I got locked out of my home five times
trying to get this to work. So there's some bucks to face there. But for now we change all
bunch of settings and then it does work. And then you enable your display manager of choice. So
SDDM for KDE or KDM for dome and then it's installed. Then you log in and you get into your
desktop environment and you can set up the thing the way you like it. How to hack on system de.
So the base image is immutable. So no compiler, no mess on or whatever in there. The bigger the
base image get, the longer update stake. So you don't want to make it too big. So what other
immutable distributions do is like this for a box or containers or whatever to do all their
development. That means OCI, if you say OCI, Leonard runs away. So that doesn't work. So I
implement something and make our site to basically do the same thing. Right. It's a sandbox where
you can install all the development tools you need. So it does it automatically. So if you
do run that in the system de-repo, it'll just download all the stuff you need and you can run it from
there. And then right, you do development with make our sciences in the S usual. You spawn
of the M and then you can test changes. And then the final one is update. So you added that
make us add a local confer file again. At the back of the package, you want to build the update
and then you want to make our sciences update updates, which will install to the B partitions.
Right. We are empty on the first update and then the old version on when you do it the next time.
It will copy the UGI to the ESP. And that's it. That's the update. So it should be a
very atomic. And of course there's a B partitions. So if the new update doesn't work,
you can always go back to the old version. And report a book or I don't know.
Then yeah. So reboot to get into the update. So this is like important. It's not like the
enough of great where you're just upgrade and then continue using it. Each update requires a reboot.
So what I've noticed is that I update last because of the means means reboot. Like I don't know.
We probably need to do something about this eventually. But because having to reboot for each update
is kind of annoying. But it works. You just end up updating less than usual.
So what do we end up with on this laptop? Of course because it would be extremely
hypocritical to be able to hack a laner about not using all of this stuff and then do this presentation
from a laptop that's not using all of this stuff either. So this is running quite a close.
It has been for a few months and we end up using all of these things. So no piece of our
yet because I have no clue how to set it up. Later it needs to tell me. Then we can probably
enable PCR log as well or at least I hope. And then we don't use all the extensions stuff yet
either because you built the image locally and you are full control over it. So there's no real
point in the extensions. So like we still need to figure something out for that.
Does it work? Yeah. I find for questions insist and the I report them and they get fixed. So that's great.
Not really. There's also a lot of questions that are stuff that doesn't work that doesn't get fixed.
So that's whatever. But I have found regressions and they were fixed. So it is helping that way.
Call to action for laner. Let's focus on building end-to-end solutions. Don't just merge the API
insist and also get it running a particle of S so that we are actually using it.
Let's make sure we consume our own API immediately. Edo ourselves or a user.
Switch to particle OS. What's missing? Luca is working on building these images in a build system.
Still needs a lot of work. But then you could actually download the update instead of building it yourself.
That's the part that's going to for stock footing of all the extensions stuff because then it's
signed by a vendor key. You can modify it locally immediately anymore. So that will help us get
to stock footing for that part. Right? PCR log I mentioned. Add more distributions. We have
action for Dora. But of course I want to add more if I'm sure some people would love a
double inversion. Desktop environments eventually do a boot and get laner to use this.
Basically the stock is this.
That was the end. Happy to answer any questions.
This is probably a question for laner more than me.
I mean you can do that but I think ultimately the wallets should probably be unlocked by
some key that's derived from here from directory and I've been talking to
people about this. What they wanted to do is that they're in a very ideas.
But it's more important that you haven't even talked earlier than that where it was talking about
user credentials. It doesn't make sense. That's kind of what they want to use that.
It doesn't should have happened.
Is there any pre-boots and integration?
Like the effects of the system like the system failed and then the first time to deal with it?
So there is a target. Is there any automatic rollback?
Yes. I know there is a target for this and system the first.
Which one was the name again?
The last boot. Yes. So you can order stuff before that and then if it fails it'll do the rollback.
And we have boot counting set up. In part of the OS but we don't order anything before
boot again already. So I don't know if we have any stuff already that is order before that that
will rollback if it fails.
So it's there but it's probably pretty basic and could be extended a lot more.
But you can always do it manually of course.
Yes. So that's the part that looks like the system and so if you win you as an update on the
update system you will be able to do it after that and you can do the update.
And so we use those things to move into the course as we use for the judge's decisions.
So the first one is if you have an infected commutable system then if you build the update on
the system itself it'll also be or there's a good chance it'll also be infected.
So how do we get rid of that?
So that first and then we'll get to the second part. So I think the idea there is that we have factory
reset. So if you have an infected system then in this case you would have to do a complete factory
reset to get rid of all state but keep the you can keep the all the measured or all the trusted
stuff like your slash user but all the rest goes away and then you start from scratch.
And then the second question was does it also make sense to get a default version that is
provided by the distribution of the or an image that's provided by the distribution and so the
answer is yes and that's basically the part that look as working on. It's not trivial for existing
build systems to actually be able to do this signing. So we're trying to get this working in the
open-suced build system which is offline signing so you can sign when you're doing the image
it's a completely separate async process. So the entire build process has to be modified to
extract all the data that needs to be signed without actually signing it then get it signed by
completely different thing. Get those inputs back and then insert them into the into the image.
This is a very different workflow than what you usually do which is you sign when you need to
in the build process itself. So we need to do quite a few horrible changes. Yeah he is doing all
the hacks required to make that work but we'll get that eventually I think.
So the use case is when you have the vendor signed image. Oh yeah the
well how do it says x fit into the to the picture presented here was the question. So
says x are for like when you build like I said with OBS. If you build it on OBS then the key
then you have vendor signed key or vendor provided key. So then you can modify it all locally.
So then you're kind of forced to use the extensions because you can sign those locally with your own
key which then has to be enrolled with markers something like that and then that's where those things
become required. That's for if you want to build your own additions locally but what's also possible
of course is that the distribution itself provides a pre-build set of says x which are much more
coarse than packages. So there would be a lot more in each says x you would have a lot fewer of them
but you could then install instead of installing your package you would install a says x for
the specific functionality you need and that allows you to keep the base image small because you don't
have to put everything in it but then you can apply specific says x to get the functionality that
you need as a user. So it's kind of similar but it would never be as fine grain as packages. You're
never going to have like thousands of bag out of says x you would have the idea to have much for you.