If I were to hold a #SecureBoot talk in the #Distributions devroom at #FOSDEM.
What would you like to know?

@Foxboron Why is it still a thing? :D

(serious question, even if I'm also trolling)

@Foxboron I'm sure @jarkko and @mjg59 would be interested xD

@Foxboron how easy is to get access to a secure boot signing key, given infinite money (state actors and criminals)?

@portaloffreedom
This is probably not going to deal with questions like that. 20-25 minutes and should mostly be community/distro relevant.

@Foxboron a simpler question: a comparison between secure boot and a password encrypted drive. They seem to solve a similar problem, what are the advantages and disadvantages?

@portaloffreedom
Those sort of answers/questions would be more fitting for the security devroom. The point of secure boot for Linux distros is two fold.

1. Introduce a security barrier into your boot chain.

2. Ensure it's easier to onboard mom and pop onto Linux.

It's both a security measure *and* a usability measure.

@Foxboron
1. History of
2. What it's good for (the why)
3. Where it fails (limitations)
4. How would you design a replacement if you had a magic wand?

@achilleas
I'm probably not clever enough to answer 4 :p

@tris @Foxboron @mjg59

Actually the point of all this to be NOT interested what everyone is doing.

That's what standards are great for. We can ignore each other and still everything works together.

@Foxboron @achilleas I have defacto answer for question four: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

@Foxboron Just to clarify: this is a serious question.

My understanding is that measured boot is now more or less easy to get thanks to many recent development (in systemd and early boot software in general) and it can cover more or less everything that verified boot has to offer.
At the same time, verified boot requires signature keys and a PKI, as well as pre-boot key pining. Many things can go wrong with a PKI and it has. Some pre-boot (like bootguard) software have been compromised, with no possible coping mechanism.

So my main question is: is Secure Boot still relevant for distributions or should they move away from verified boot to the more secure and I dare say simpler measured boot? And if I am wrong, I would love to understand why :)

@x_cli @Foxboron secureboot can be seen as hardening in certain scenarios, incl. the scenario where you do not want to allow the attacker to run arbitrary code on your target devices

@x_cli @Foxboron and verified boot is far from being "easy" to implement on all OS contexts, highly customizable OSes have very difficult paths to measured boot

@x_cli
Yes.

If you want your parents to install Linux, you don't want to explain to them how to get into BIOS to disable secure boot.

@Foxboron I mean, we could have shim in disabled mode (mokutil --disable-validation), so that we boot on secure boot enabled devices while not bothering with secure boot at all for the remaining of the boot process.

@x_cli
Sure, but that's just an implementation detail.

You would still need to deal with Secure Boot, shim, signing, coordinated disclosure and improvements to the process that is being collaborated on with Microsoft

@x_cli @Foxboron With UKIs, it's much simpler to validate things (and thus do measured boot) if you sign them with Secure Boot.

@siosm
Yeah, by measuring the Secure Boot keys instead of the signed data. But by doing that, you implicitly trust SB to do a good job, which is doubtful in my opinion. We could have signed register values and a TPM policy installed along with the UKI instead. Not so different in the grand scheme of things, except that SB would be out of the picture.
That's what I did in a previous job.

@x_cli You have to trust the firmware to update the PCR values in the TPM correctly in both cases so trusting it to validate the signature of UKIs isn't that much more.

@siosm
Good point 😊