Devroom kick-off talk: UKI? DDI?? Oh my!!!
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 |
| |
| Subtitle |
| |
| 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/61548 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
MeasurementBootingComputer-generated imageryMathieu functionComputer hardwareInformation securityFocus (optics)Field extensionKernel (computing)SpacetimeRootkitFirmwareChainLocal GroupSign (mathematics)Numbering schemeVolumeRun time (program lifecycle phase)Binary fileEmailBootingFile systemDistribution (mathematics)Physical systemFocus (optics)Library (computing)MereologyRootkitPersonal digital assistantProjective planeLatent heatCore dumpOpen sourcePartition (number theory)Different (Kate Ryan album)Ring (mathematics)Group actionSoftware engineeringMathematicsBitComputer fileModule (mathematics)Android (robot)MalwareNumbering schemeVirtual machineRun time (program lifecycle phase)Mathematical analysisKernel (computing)Self-organizationNetwork topologyGeneric programmingPatch (Unix)ChainPoint cloudArithmetic meanAdditionFormal verificationMultiplication signProcess (computing)WebsiteInformation securityTouch typingMeasurementView (database)Matrix (mathematics)Disk read-and-write headDirectory serviceCASE <Informatik>Logistic distribution
08:28
Kernel (computing)Computer-generated imageryBootingBinary fileMiniDiscRootkitPartition (number theory)Physical systemService (economics)Portable communications deviceExtension (kinesiology)HierarchyNetwork topologySoftwareDependent and independent variablesArmInformation securityRootkitDistribution (mathematics)BootingPublic key certificateMiniDiscComputer wormComputer clusterPartition (number theory)Computer configurationPoint (geometry)Information securityPolar coordinate systemCore dumpGroup actionPlanningPhysical systemFile formatDefault (computer science)Type theoryMeasurementLatent heatUniform resource locatorComputer fileContent (media)Medical imagingExtension (kinesiology)Sign (mathematics)Computer hardwareView (database)File systemHash functionSlide ruleRight angleMultilaterationInterior (topology)Direction (geometry)Kernel (computing)Portable communications deviceSelf-organizationSoftware bugSocial classNamespacePlastikkarteReal numberService (economics)Product (business)Equaliser (mathematics)Virtual machineVarianceCuboidReflektor <Informatik>Different (Kate Ryan album)Integrated development environmentOrder (biology)MereologyAbsolute valueComputer animation
16:50
Computer-generated imageryMiniDiscRootkitPartition (number theory)Computer fontBootingPortable communications deviceService (economics)Focus (optics)Information securityComputer hardwareMeasurementSpacetimeFirmwareField extensionKernel (computing)ChainLocal GroupSign (mathematics)Mathieu functionRun time (program lifecycle phase)VolumeNumbering schemeBinary filePhysical systemSlide rulePartition (number theory)Key (cryptography)Sign (mathematics)Electronic mailing listLatent heatElectronic signature
18:01
Program flowchart
Transcript: English(auto-generated)
00:05
Good morning and welcome to the very first image-based Linux and secure measured boot dev room. Bit of a mouthful, we'll try a shorter one next year. So let me start by introducing myself. My name is Luca.
00:21
By day, I am a software engineer in the Linux Systems Group at Microsoft where I work on the Azure infrastructure. And by night, I contribute to various open source projects. I am an assistant dev maintainer, dev dev developer, a dev dev maintainer, a bunch of other stuff that I forget and neglect. So I will give you the introduction to the dev room
00:42
and an overview of all the topics that we'll touch on to hopefully give you a holistic view of what image-based Linux is. So let me start by saying thank you to all the organizers and co-organizers for this dev room, especially to Thilo, who unfortunately could not make it to Brussels this year,
01:01
but he did most of the work on the FOSDEM website and CFP and so on. So thank you, Thilo, if you are watching. Now, some boring logistics. This dev room has a five minutes break between talks to allow to switch and don't spill over. We have a ten minutes break at ten past twelve and we finish at twenty past two.
01:24
Next dev room starts at half past two. Now, in case this is your first FOSDEM or it's not, but you never noticed, everything is live streamed and recorded. If you're not comfortable with having your back of your head recorded or live streamed, best I can suggest is to sit on the sides.
01:41
If you ask questions, remember, again, they will be live streamed and recorded. If you're not comfortable with that, there's a matrix chat. You can ask a question there and our dev room organizers will repeat it for you. We do want people to ask questions, please do so. Please do not just start shouting at the presenter. Raise your hand and then we will come to you with a microphone.
02:04
If you're a speaker and people shout a question at you, please first repeat it and then answer it. And I think that's it. Now, let's get into the interesting stuff. What is image-based Linux? Now, if you're an embedded person or addition to that word, you're probably thinking,
02:24
what are these guys talking about? We've been doing image-based Linux for 30 years. It's nothing new. And you wouldn't be completely wrong. Now, the difference is that our focus within this ecosystem is on the security aspect. Because let's face it, Linux runs everywhere.
02:41
Most of our infrastructure and economy runs on Linux today. All the public clouds run on Linux, even Azure. So, we want to get our security story straight. What does that mean? What are some of the basic concepts? First of all, we want to have first-class support for at least one, if not both,
03:00
of Eufy Secure Boot and TPM-based measurements. Hopefully both. Because the goal here is to extend the chain of trust at boot. Now, if you're using a generic Linux distribution like Debian or Ubuntu or Fedora, the story in your firmware-to-kernel chain of trust is pretty well buttoned up by now.
03:25
Because a lot of people did a lot of work in the past 12 years to get that story straight, and they keep doing that to maintain it. So, in your generous distribution, you will have your firmware, which verifies the first stage bootloader, which will be Shim, signed by Microsoft,
03:41
and then Shim, the first stage bootloader, verifies the second stage bootloader, and verifies the kernel, and the kernel verifies the kernel modules. So, if you are within ring 0, the chain of trust is pretty solid. There is this small little thing to the side called user space, where things are not so pitchy.
04:00
And that is what we are trying to improve. So, just a quick summary, we'll go into more details, but we want each of these to be signed. Each of these are completely unprotected right now in most distributions. They are built locally. If an attacker or malware can get right access to that, they can embed their malware in there and you will be known the wiser.
04:22
That's a bit of a problem. The same thing for your rootFS. It probably is encrypted these days, but that helps for offline attacks, not online ones. We want to do better there. One of the key requirements to use any of the specification infrastructure tools that we see is you need to have an hermetic zesh user.
04:42
What does that mean? It means your vendor tree must be within zesh user. If you are in one of those handful of distributions that still have the top-level BINs, BINs, or lib directories that are not symlinks, it's time to move on. Even Debian managed, finally, kicking and screaming, but managed to get into merged users.
05:02
That is a core requirement. The people who work on this stuff kind of got together from various distributions, companies, projects, and we created this UAPI group. We have a nice website. We have a GitHub organization with a discussion tab.
05:21
There's already quite some interesting discussions going on there, so I encourage people who are interested in these topics to check that out. Now, what does actual image-based Linux mean? This is my personal understanding and analysis. From my point of view, I see at least three different flavors of this. There's the pure image-based one.
05:41
It's the one that I do in Azure, where you build images, the whole images, and you ship to the machines. You have the n-verity to cover the root file system. I won't explain what that is. The next talk, we'll go into details. Then we have AB schemes for upgrade, upgrades. Nothing groundbreaking, right? Android has been doing this for 15 years or whatever.
06:01
The second camp is the OS3 one, pure or RPM-based, like federal core, for example. What they do there is they build either packages or OS3 snapshots, and then they apply them locally. And you reboot into the next snapshot or a different one. It's like a GitHub for your file system. The root file system there is either ephemeral or immutable at runtime.
06:25
I cannot remember. You cannot change it. You reboot into the new one. But the first camp, very similar. Instead of OS3, you use the butterfly snapshot capabilities. So you install a package. It doesn't get installed in your root FS. You install it into the new snapshot and then reboot into it.
06:42
The core thing I want you to take away from this is that there are different flavors, ways of stringing things up together. And that's okay. That's what Linux is great at, this diversity. But the core important concept is that we share goals, we share tools, infrastructure, and specifications
07:02
because we want the same thing in different ways. So let's look at some of these specifications. Fair warning, there's a lot of acronyms coming your way now. I apologize in advance. Now, UKI, you will hear a lot about this today. Unified kernel image. What is this? A UKI is a single P binary, a UFI executable.
07:24
Why is it good? Because you mix a UFI stub, a kernel, and an E3D. And then you can sign it for a secure boot. Remember I talked about the E3D being unsecure before? This is how we fix it. The E3D is no longer built locally.
07:40
It's built by the vendor and shipped inside the UKI. So it's signed and it's verified as part of the boot process. I won't go into details in this process because one of the next talks will tell you everything about this. So the UKI is dropped into the boot partition or ESP. And then it's out to discover by boot loaders implementing the BLS, boot loader specification.
08:03
What does that mean is that you don't need to configure your system to pick the UKI up when you boot. The boot loader will parse what's available, get the information out of it from the UKI itself, and present you a menu. It's dropped and plug-and-play, basically.
08:21
So this is supported by system reboot. And there are patches for Grub as well. I think Fedora will ship with those patches and hopefully they make it their way upstream. Another good thing about the UKIs is that not just we sign them and verify them as one, but also we can then predictably measure them into TPM in PCR11.
08:45
So the hashes will always match. If that doesn't make any sense to you, that's okay. And then later we tell you everything about TPM and measurements. I just mentioned it here, so you have an overarching view of why this stuff is good. And we want to do some future work here,
09:01
but the important thing is the specification is at this URL. And that's for UKIs. Now, next one. This is my favorite one. DDI, discoverable disk image. What is this thing? It's just our image wrapped into a GPT partition table. The good thing is that it is self-described.
09:21
Each partition is tagged with a UID that is fixed and tells you what the purpose of the partition is. You don't need to say root equal devsda5 because the partition is tagged with a UID that says I'm the root of this. So because security is important to us,
09:41
this natively first-class supports the N-varity for protection. Again, the N-varity will be delved into later. I won't tell you what it is. It's for securing the partition against tampering. All tools that support DDI support the N-varity natively. The other important thing is that
10:02
given they are self-described, you just pass them to the right tool and they do the right thing that you expect out of the box. If your disk, where the ESP was, is a DDI, systemd will automatically find the root partition by looking at UID and boot it from the inner D.
10:20
If you pass the DDI to nspawn, it will automatically use it for the root for the system or the container you're booting. You pass it to portable D or to a systemd service as root image, and it will be automatically used for the root for the system of that mount namespace. You pass it to sysext, and it will be automatically used to extend the root for the system.
10:42
We'll see in the next slide what that means. So one image format, self-described, give it to many tools, they do the right thing automatically. Security as first-class concept. Now, what's a sysext? This is important for the inner D talk later. So, it's a specific type of DDI.
11:01
It can be used to extend a root file system. So it will ship the user hierarchy, or the shop if you're a third-party vendor, and it's identified by the extension release file, which matches the format of the OST release file that you're probably familiar with. The specification of this is a dead URL.
11:21
So, you get a rootFS DDI, a bunch of sysext DIs, and, bam, you get another AFS, read-only, that sums the content of all those images. And, again, this is important for the later talk. Again, security, first-class citizen. The dmvar is supported for all of these,
11:40
and all the tools that use these sysext DIs. The same idea as before. You pass it to the right tool, it does the right thing by default. If it's your ESP, we'll see how it will be used to extend the inner D. If it's on VAR or ETC, system D will use it to extend your rootFS. You pass it to portable D or to a system E service,
12:02
it will extend the rootFS of the service or portable service, again, with security in mind, so it's all protected and read-only and enforced by the kernel. You pass it to nspon, and nothing happens because we don't support it yet. We should add that probably at some point. Specification of this URL.
12:21
Now, all of this might sound like the ingredient humbling of a raving lunatic, but I swear it's real. It exists. It's used in production. What you can see here is the stuff that I work on. It's a PCI Express card that, as an ARM64 system on a chip, it's used in the Azure hosts.
12:43
The machines that run Azure virtual machines have these cards plugged in, and the Linux R and OS provides offloading and acceleration for the Azure nodes. So if you use Azure, you already use this DDI stuff. You just don't know about it because we use DDI extensively,
13:02
and we are looking into UKIs as well. So this is all real. It's all true. Now, to conclude, come talk to us. We usually don't bite. Here's, again, the URL for the website and for the GitHub organization. So we want you to join us
13:21
and embrace some of the secure way of doing Linux. We want you to help us extend the specifications, and also we want to finally get the world class of security bugs extinguished. And any questions? Yes, microphone.
13:46
Hi. How would you compare UKIs to fit images from U-Boot, which also supports signing and packaging all of these parts into one single image? Yes, it is actually quite similar. Now, of course, the U-Boot team... So U-Boot is a firmware slash boot order environment
14:04
used by embedded devices, essentially. They support this fit format, flattened image table, and they have a very similar concept, absolutely. The main difference is done with TPMs in mind. I'm not sure U-Boot...
14:22
They don't support that and measure everything? OK, I'm not very familiar with that, but they are very similar concepts. I don't know what the main difference will be. It's just different environments, I guess. This is mainly for UFI. U-Boot is a specific boot-loader environment, right?
14:41
It can also run on the U-Boot. All right, OK. They are very similar, I guess, then. Thank you for the talk. From my understanding, we often in usual distribution have shim sign and grub sign,
15:00
but we don't have system U-Boot sign or EXT Linux sign or U-Boot sign. What is the plan in the future to have those signs, maybe? Excellent question. Now, there is a group of people working on this problem of UFI and UFI 2.0.
15:20
Everything that happened with the secure core PCs. Things are moving. I can't tell you much more than that right now. We do want to get SD-Boot sign for some internal use cases, so we want to get that allow listed to be allowed to be used as a payload
15:40
for a second stage loader for shim. We have not done that yet. We would like to have that done at some point in the near future. Thank you. A kind of intermediate option is to have it signed by a certificate
16:03
that is provided by the distribution and it's protected by the hardware security measurements and so on, but it's not trusted by shim. Then you can self-enroll on the first boot and have a trust on first boot thing.
16:20
We've done a bunch of work on SD-Boot to allow self-enrollment on first use. You can always do that. Of course, it doesn't work by default. You need to do the self-enrollment, but it's a step in the direction. Yes, thank you. Anything else? Can you pass? Please, thank you. If you compile yourself a Linux kernel,
16:43
what do you have to do then? In systemd253, we ship a tool called ukify, ukify, ukiify, whatever you want, and that will, this one, will allow you to easily put together a uki.
17:01
Of course, in that case, you cannot sign with your off-site key. You need to do self-key enrollment and whatnot, but it is possible to build a uki locally, absolutely. You need to sort out the signature by yourself, of course. I think there was, at the back, yeah.
17:21
You mentioned, well, I saw on one of your slides the abbreviation DPS. DPS, yes. What does that mean? Sorry, yes, I should have said that. Discoverable Partition Specification. Yes, I told you there were a lot of acronyms. So that is the list of all the UIDs and what they define. Rotafest, Averity, VAR, TMP, blah, blah, blah, et cetera.
17:41
Thank you. Thank you. I completely forgot about that. I think we are three minutes. Any more questions? Anything online? Nope. Going once, going twice. Well, thank you very much then.