Ubuntu Core: a technical overview
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 542 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/61547 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Core dumpCanonical ensembleMiniDiscEncryptionBootingBootingComputer-generated imageryMeta elementPoint cloudConfiguration spaceConvolutionKernel (computing)Physical systemModul <Datentyp>Thermodynamisches SystemRootkitType theoryService (economics)Data modelSystem identificationMeasurementPartition (number theory)Key (cryptography)Data typeMiniDiscFile systemThermodynamisches SystemCore dumpPhysical systemInternet der DingeBootingSet (mathematics)Cartesian coordinate systemDepictionType theoryComputer fileAuthorizationFactory (trading post)Partition (number theory)MetadataColor confinementKernel (computing)Configuration spaceEndliche ModelltheorieModule (mathematics)FirmwareRun time (program lifecycle phase)InformationRootkitInstallation artService (economics)Revision controlEncryptionMedical imagingMereologyInformation securityComputer animation
07:48
MeasurementPartition (number theory)Key (cryptography)Data modelBootingKernel (computing)Core dumpDirectory serviceContent (media)Electronic mailing listRootkitFirmwareModul <Datentyp>Physical systemLatent heatLocal ringDefault (computer science)Canonical ensembleService (economics)Thermodynamisches SystemPartition of a setKey (cryptography)Time zoneFile systemKeyboard shortcutScripting languageComputer fileEncryptionElectronic mailing listService (economics)Installation artVarianceLatent heatTrailRootkitFirmwarePartition (number theory)Kernel (computing)Module (mathematics)Configuration spaceMultiplication signFlow separationBootingThermodynamisches SystemMiniDiscDirectory serviceBitCartesian coordinate systemDecision theoryParameter (computer programming)Execution unitProcess (computing)Computer animation
15:29
Gastropod shellCore dumpPasswordConvolutionCanonical ensembleRevision controlPartition (number theory)Integrated development environmentBootingContent (media)Meta elementKernel (computing)Scripting languageGastropod shellCodePasswordData recoveryWrapper (data mining)Medical imagingCartesian coordinate systemEndliche ModelltheoriePoint (geometry)MeasurementDefault (computer science)Touch typingKey (cryptography)Roundness (object)Figurate numberGraphics tabletCore dumpExtension (kinesiology)Public key certificateState of matterBitHash functionFiber bundleMultiplication signProof theoryKernel (computing)MiniDiscBootingIntegrated development environmentLatent heatScripting languagePlanningComputer animation
23:10
Program flowchart
Transcript: English(auto-generated)
00:06
Okay, we can start a bit early. So next speaker is Juan-Anton 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.
00:29
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.
00:44
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 Internet of Things for the month, so it's not a distro for desktop.
01:10
You can have graphical user interface, but it's not ready for desktop. Because it's targeting IoT, it supports lots of boot loaders, but in this talk I will
01:25
focus on UEFI because this is what is interesting, the rest is. Ubuntu Core has been doing a secure boot with full disk encryption with using the TPM for a while, and this was done before.
01:43
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?
02:01
A snap is, I mean, there is a difference, you will see that there is a different type of snap, but what is common for a snap is just that it's a squash FS image, and there is a specific file that is metadata that describe what this image is for, and then after they will be depending on type, there will be more information that you
02:21
can get on that. The type of snaps, the first is the application. So this shipped the application and its runtime, and it expects to have another snap
02:42
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 has the runtime for the application itself. Typically, application exports services or commands. In the desktop world, we have also applications, desktop applications, but for Ubuntu Core,
03:05
we don't care about these kind 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.
03:20
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 systemd in it.
03:43
An application that runs on Ubuntu Core doesn't need necessarily 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 snapd, because to handle the snap, how to unpack it, how to install it, there is a daemon, and this is distributed as a snap itself.
04:07
It's not an depiction 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
04:21
a UKI, so it's a UFI kernel that is signed and has the initrd in it. The snap also provides modules and firmware files. And then the final type is gadget.
04:42
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 in it, so some initialization, and then we have also, if you want to have extra command
05:05
line in your kernel. The disk starts, the image starts with just one partition, which is ESP, and we call it the seed. It contains grub and shim, of course, and it has the seed snaps.
05:21
It's like the factory snaps that you can revert 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.
05:40
And it has also another file that is a model assertion. 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
06:00
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. So the second one is the boot, which also contains a grub, and typically the grub will
06:20
change from the seed one, so it will always boot from the seed, and if it finds that it doesn't have to do recovery or anything, it has to do a normal run, it will go to the second one. And the second one will have the current active kernel that you have installed, and it will also have a silky for the data partition, because at that time, I think it was not
06:43
common to have this silky onto the header, lux2 header, so it was done like that. Then after, we have two partitions that are writeable, and they are encrypted. There's a set partition, basically it's to identify the device, it's not much on it, it's a very small partition, and then we have data which contains most of the writeable
07:02
data. To get to have a runnable system, we have to do things in a TramFS. So first of all, we use the systemd on both the TramFS and the main boot, but here I'm
07:26
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 mark all the disks that we have. And the first thing we do is measure the epoch.
07:41
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 set partitions, those are not encrypted.
08:03
From the set 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
08:21
open and mount the data partition. Then we will do the same with the set partition. The seal key for the set partition is on the data partition, so we have to mount the data partition before we open the save.
08:41
And last, we will find the base snap that we need to mount, and this will find it from the data partition, we will find a file that describes what is installed. And we mount the base, the kernel, and the gadget. So the base will be our sysroot, and the kernel is needed because we need the modules
09:03
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 later. And then there's some locking of the seal keys, so we don't unseat them again.
09:20
Once we have mounted all the disks, we have to prepare the file system. So first we bind mount the base into the slash sysroot, where we will do the switchroot. Then after, we have to bind mount the userlib modules and userlib firmware. We do mounting of the seed and boot partition within boot, there's a specific way to do
09:45
it. And then after, we have to, from the data, we have to do binding 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
10:01
your base snap is not writable because it's a squash fs, so you want to bind mount. We have a script for now that read a list of the path that we have to do bind mount, and we also can configure, saying that if it's not, if it doesn't exist, we initialize
10:22
with the data that is on the base snap, or have it empty. This script will probably be replaced by using tmv files, d and fstab, but it was
10:42
written like that, but it was done. We don't bind mount slash var and slash etc directly as writable, because most of it is not writable. This is to ease the update, because we can't track everything that needs to be updated
11:03
in etc, and if someone modifies a file in etc, 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 etc-systemd. This one, we need to install services and mounts for all the snaps.
11:29
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
11:42
etc hostname, because systemd does some atomic write, so that means that it will make a temporary file in the directory slash etc slash hostname, some temporary name, and do a switch, but it's not possible if slash etc is not writable, so there's
12:04
some patches for that. And etc local time is even worse, because it's a symlink that has to be rewritten, and we need to follow the symlinks until we find the symlink that is writable.
12:21
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 interclimbFS, and then after we switched to the normal boot, and most of what happens is just systemd.
12:43
There's two main thing that will happen is, done by snapd, is mounting the active snap, and starting the snap service, the service from the application that are installed, and those are just units in systemd, so they are installed by snapd inside slash etc slash
13:02
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, so that means that we have something special for the first boot where we find that snapd is not installed,
13:24
so we have this process where we have to find a snapd that was mounted from the interclimbFS, run it to tell it to install itself, so that we can just continue. So this is what's called the ceiling of the snapd.
13:45
So the disk are encrypted using lockstooth, we use a TPM, and the thing that we, the policy are 4, 7, and 12, if you don't know what 4 and 7 is, it's from the system, you
14:05
don't have to worry about that, 12 is something that we deal with, so we do our measurements, and we might have several values, expected values, because we have parameters that change
14:22
if we want to do a recovery, or some other things that need to still mount 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
14:44
we use for evocation. This is because we need to reseal our keys every time we change what the values of the PCR can be, and to not allow all the values to be able to boot again, there is also a
15:06
non-volatile counter that is used, that we increment each time we have to change. What we measure in PCR 12 is, one is done by the systemd stub, because we use the systemd stub for, to make the uki.
15:23
This is a kernel command line, and it's important for us, because, yeah, yeah. And then we have, as I said before, we have the epoch and the model. There is some interesting things that we have.
15:42
What happens when you have a failure, that happens, and you want to have the emergency shell 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 have the initremfs that is built for all, that has to be signed
16:07
in the uki, it can be only built for, one built for everybody, right? So that means that there is no, the initremfs, there is no password, but we still need
16:23
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
16:44
the kernel command line in PCR 12, that means that you will not be able to unlock with a 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.
17:01
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 to unlock, to use a TPM. But maybe there is other things, the other ways we could have done things, maybe we could
17:21
have done some specific measurement for when there's a need for emergency, I don't know. Oh, yeah, yeah, let's see quickly. When we update the gadget, the interesting thing to know is that the gadget provides
17:47
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
18:00
to do the seed, which does the recovery, there is some versioning that we use to do that, not 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
18:22
is something to try to boot, and if it found that it did try to boot and it didn't work, it will roll back, then 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.
18:40
If you have any questions. So I'm from the Ubuntu Touch team, and the Ubuntu Touch team still use the writable pad
19:03
system, the same thing that is still using Ubuntu Core today. My question is that, does Ubuntu Core have any plan to move on from this system, or are you still planning to be using this system in the foreseeable future, or any update
19:27
on that? Are you talking about the writable paths? Yes, the writable paths. Yeah, my plan is to move to tmp files and fstab, so use just tools that comes from systemd, because we can do those things.
19:42
It means there is a bit of duplication in how you write the things, but that means we have one less shell script to maintain, that is not maybe the nicest thing. But there is no, I don't think there is any data or when it will happen, it's just
20:00
there is, we know it works, and we have to decide when we move to that. Thank you.
20:21
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.
20:42
I mean, what I showed you is how the state is now, and it would be better not to have terrestrial, but we didn't have the, there was not that much experience, I think, in the community at that moment, that we could just do that, which was better.
21:03
So when it's been designed, I think people didn't realize that it could do something better. But yeah, I mean, at some point we would get there, but I don't think we have any proof of concept on bundle core using this, yet we have talked about it, that's it.
21:25
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
21:45
like systemd sys extensions that were talked about earlier today? You mean those, because the point is that the application snapped is the important thing
22:00
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.
22:27
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
22:47
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 deals with, it's much better. But for the user, I believe that it has to look like a snap.
23:03
Okay, round of applause.