Okay, we can start a bit early.
So next speaker is Vananthau David.
He will give a technical overview of Ubuntu Core, so thanks for having me.
Yes, so this will be a very deep technical talk about how we do things in Ubuntu Core.
Ubuntu Core is a distro. It's based on Ubuntu builds, so the Ubuntu packages,
but you can't install or remove packages because we removed APT and DPKG and everything.
The system is split in four atomic snaps, so there are four parts that you can upgrade independently.
If you want to install anything on it, you need to install it as a snap.
Ubuntu Core targets internal things for the month, so it's not a distro for desktop.
You can have graphical isn't your first button, but it's not ready for desktop.
Because it's targeting IoT, it supports lots of bootloaders, but in this talk,
I will focus on UEFI because this is what is really interesting the rest is.
Ubuntu Core has been doing a secret boot with fuller disconscription using the TPM for a while,
and this was done before. SystemD had lots of nice tools to do that,
so this is why I thought it was interesting to talk about how things were done because
they might seem peculiar or it was a different approach.
So what is a snap? A snap is, I mean, there is a different, you will see that there is a
different type of snap, but what is command for a snap is just that it's a squash fs image, and
there is a specific file that is metadata that describes what this image is for, and then after
they will be depending on the type, there will be more information that you can get on that.
The type of snaps first is the application, so this ship, the application and its run
time, and it expects to have another snap to run on top, which is the base,
which is the root file system, so it doesn't have the root file system, it just have the run time
for the application itself. Typically, application exports services or commands. In the desktop
world, we have also applications, desktop applications, but for Ubuntu Core, we don't care about these
kinds of things, and those applications run confined. There is all type of application in
Snap that we don't support in Ubuntu Core, which are not confined. We only support confined in
Ubuntu Core. Then after, we have the base snaps, and those are the root file system,
and they are used for the applications, but they're also used for the bootable system,
so it has system in it. An application that runs on Ubuntu Core doesn't need
necessary to have the same root file system as the host itself, it can just use a different
version if it was built for another version. Then we have a snap D, because to handle the snap,
how to unpack it and to install it, there is a demo, and this is distributed as a snap itself.
It's not an application snap because it has specific things, so it has its own type. Then for
Ubuntu Core, we have the kernel snap, which provides the kernel, which is a UKI, so it's
a UFI kernel that is signed and has the entity in it. The snap also provides modules and firmware files,
and then the final type is Gadget. I don't know why Gadget, but it provides the bootloader,
so in our case, it's shim and grub, and it has also lots of configuration for snapd,
how to make the image. Cloudy needs some initialization, and then we have also,
if you want to have extra command line in your kernel. The disk starts, the image starts with
just one partition, which is the ESP, when we call it the seed, and it contains grub and shim,
of course, and it has the seed snaps, it's like the factory snaps that you can reverse to if you
need it. It also has a seed kernel that has to be unpacked from the seed kernel snap, because
grub cannot read from there, or I don't know, and it has also another file, it's a signed metadata
file. How to explain, it explains how to update things, and it's some authority file. Once you
have done the installation, I will not explain how the installation happens, because I don't think
it's fun. I will explain how we run normally, but once it's installed, we have three other
partitions that will appear in your disk. The second one is the boot, which also contains a grub,
and typically the grub will change from the seed one, so you will always boot from the seed,
and if it finds that it doesn't have to do recovery or anything, it has to do normal run,
it will go to the second one. The second one will have the current active kernel that you have
installed, and it will also have a seal key for the data partition, because at the time I think
it was not common to you to have this seal key on to the header, looks to header, so it was done
like that. Then after we have two partitions that are writable and they are encrypted,
there's a safe partition, basically is to identify the device, it's not much on it,
it's a very small partition, and then we have the data which contains most of the writable data.
To get to have a runnable system,
we have to do things in a trimfs, so first of all we use the systemd on both the trimfs
and the main boot, but here I'm going to show the few things that we do that might be different
to other systems, so one of the first steps that we have to do is mount all the disks that we have,
and the first thing we do is measure the epoch, for now I think it's always just
measure zero, it's something that has been done probably for revocation, if we need to revoke
the code we can just increment that, but I don't know how useful it is because I don't think it
has been touched. Then we mount the boot and seal partitions, those are not encrypted,
from the seal partition we find the model and we will measure it in the PCR.
After that we will find the seal key from the boot partition and we'll unseal it and open and mount
the data partition, then we will do the same with the safe partition, the seal key for the
safe partition is on the data partition, so we have to monitor the data partition before we open
the safe, and last we will find the base snap that we need to mount and this we find it from the
data partition, we will find a file that is described what is installed and we mount the base,
the kernel and the gadget, so the base will be our sysroute and the kernel is needed because we need
the modules and firmware and the gadget, there's some configuration there that we need,
optionally we need snapd to be mounted also, but I will talk about this after, and then there's
some looking of the seal keys so we don't unseal them again. Once we have mounted all the disks
we have to prepare the file system, so first we'll buy mount the base into the slash sysroute,
where we will do the switch route, then after we have to buy mount the user-lib modules and
user-lib firmware, we do mounting of the seal and boot partition within boot, there's a specific
way to do it, and then after we have to, from the data we have to do bind mounting of specific
paths onto the root file system, so typically for example you want the slash of wire to be mounted,
to be writable and your your your base snap is not writable because it's a squash fs, so you want
to want to buy mount, we have a script for now that reads a list of paths that we have to do
buy mount, and we also can configure saying that if it's not, if it doesn't exist we will initialize
with the data that is, that is on the base a snap, or have it empty. This script will probably be
replaced by using tmv files d and fstab, but it was written like that, but it wasn't there.
We don't buy, we don't buy mount slash var and slash atc directly as writable, because most of it
is not writable, this is to, here's the update, because we contract everything that needs to be
updated in atc, and if someone modifies some file in atc we don't, it's very hard to track,
so we have a specific list of paths that are bindable that you can write.
So an example is atc systemd, this one we need to install
services and mounts for all the snaps, so this needs to be, this path needs to be writable,
but there are some things that are really annoying for us doing this, for example slash
atc hostname, because systemd does some atomic write, so that means that it would make a temporary file
in the directory slash atc slash osnab does some temporary name and do a switch,
but it's not possible if slash atc is not writable, so there's some patches for that,
and atc local time is even worse because it's a sim link that has to be rewritten, and we need
to follow the sim links until we find the sim link that is writable,
so it's not, all these things are a bit confusing and it's a bit annoying, so
yes, and this was the initial decision during the initial time of fs, and then after we
switched to the normal boot, and most of what happens is just systemd,
there is two main things that will happen, is done by snapd, is mounting the active snaps,
so and starting the snap service from the application that are installed, and those are
just units in systemd, so they are installed by snapd inside slash atc slash systemd,
and systemd will just start them for us, we just have snapd installing those things there,
but the problem is that in the first boot snapd is not installed,
that means that we have something special for the first boot where we find that snapd is not
installed, so we have this process where we have to find a snapd that was mounted from the inner
trim fs, run it to tell it to install itself so that we can just continue, so this was called
the the the seeding of the snapd, so the disks are encrypted using lockstove, we use a tpm,
and the thing that we the pcr that we use for for the policy are four seven and twelve, if you
don't know what four and seven is, it's from the system, you don't have to worry about that,
twelve is something that is that we deal with, so we do our measurements, and we might have
several values, expected values, because we have parameters that the current parameter that change
if we want to do recovery or some other things that needs to still mount the the five systems
that are encrypted, so we have I think there's a policy or there's several values for the pcr,
and then we have another in the policy, another thing is that we have a counter
that we use for evocation, this is because we we need to reseal our keys every time we
change what the values of the pcr can be, and to not allow all their values to be able to boot
again, there is also a non-volatile counter that is that is used that we increment each time we
have to change, what we measure in pcr12 is one is done by system distub because we use a system
distub to make the uki, this is the kernel command line, and it's important for us because
yeah, and then we have as I said before in the try my first we have the epoch and the model,
there are some interesting things that we have, what happens when you have a failure that happens
and you want to have the emergencies a shell to to happen, there is two things, first Ubuntu
Core doesn't have, we try to not have password, you can have password but by default you don't
have password, but even if we add we don't we have the intramfs that is built for all
that has to be signed in the uki, it can't it can be only built for everyone, one built for
everybody right, so that means that there is no, in the intramfs there is no, there is no
password but we still need to have an emergency shell if we want to be able to debug things,
to allow that we only have this emergency shell if we have a specific kernel command
line parameter which is dangerous, and you have to remember that since we measure the kernel
command line in pcr12 that means that you will not be able to unlock with the tpm your disk
if you are in that shell, so you will need to use a recovery key to be able to unlock if you want,
but we can do this, I mean we can do some debugging and figure things but you have to
change things and to disallow you do, to unlock, to use a tpm, but maybe there is all the things,
the other ways we could have done things, maybe we could have done some specific measurement for
when there is any form of emergency, I don't know, oh yeah, let's see quickly, when we update the
gadget, the interesting thing to know is that the gadget provides, the gadget snap provides the
shim and grub and we might want to update it in different partitions, so the seed or the boot,
usually we want only the boot, but if we might want to do the seed which does the recovery,
there is some versioning that we use to do that, that's very important, then when we upgrade the
kernel snap, we copy the new kernel in the specific way, in the boot partition we update a grub environment
file, the grub will boot and see that there is something to try, try to boot and if it found
that it did try to boot and it didn't work it will roll back, then after if snapd found that it
managed to boot with the new kernel that it knows that it has finished the update and will update
everything, this we can skip, this is not that important, if you have any questions.
So I'm from the Bluetouch team and the Bluetouch team still use the writeable path system,
the same thing that is still in use in Mudu core today, my question is that does Mudu core have
any plan to move on from the system or are you still planning to use the system in the foreseeable
future or any update on that? My plan is to move to TMP files and fstab, so use just tools that
comes from systemd because we can do those things, it means there is a bit of duplication in how you
write the things but that means that we have one less shell script to maintain that is not maybe
the nicest thing, so but there is no, I don't think there is any date or when it will happen,
it's just there is, we know it works and we have to decide when we move to that.
Thank you. You mentioned resigning or resealing on updates, could you do away with that and use
the trick with binding to a hash of a certificate and then using the certificate to sign whatever
needs to be signed? Yeah, I mean that would be better, I mean what I showed you is how the
state is now and it would be better not to have to reseal but we didn't have the,
there was not that much experience I think in the community about that at that moment
that we could just do that which was better so when it's been designed I think people didn't
realize that could do something better but yeah I mean at some point we will get there but I don't,
I don't think we have any fourth concept on Ubuntu Core using this yet, we have talked about it,
that's it. We still have time for questions? Yes, last question.
So it feels to me like using SNAPs in this way is a bit complicated, my question would be
what benefits do you get from this approach compared to something like system D, CIS extensions
that were talked about earlier today? You mean those, because the point is that
the application SNAP is the important thing for the user experience because they want to have
their own application and they can do quite a lot of things and this is very interesting and having
everything to update in the same way makes things simpler for them, I mean it might not, because I
showed you what was the complex things behind the curtain but I think the point of having
SNAPs there is just for the simplicity of the users, people who make image for their applications
they have to deal just with SNAPs and not many different technologies.
Yeah, we could probably, I don't know how to use all the things and make it look like it's a SNAP,
I'm not sure, maybe there is a way but which would be nice, I mean because if we have less
code to maintain and we just have a wrapper to something that something else is with,
it's much better but for the user I believe that it has to look like a SNAP.
Okay, round of applause.