Release Engineering

This project is intented for all release related issues (isos, installer, etc), under the umbrella of the ArchLinux Release Engineers
Tasklist

FS#53864 - Support Secure Boot

Attached to Project: Release Engineering
Opened by mirh (mirh) - Friday, 28 April 2017, 10:58 GMT
Last edited by Gerardo Exequiel Pozzi (djgera) - Saturday, 03 March 2018, 17:37 GMT
Task Type Bug Report
Category ArchISO
Status Assigned   Reopened
Assigned To Pierre Schmitz (Pierre)
Gerardo Exequiel Pozzi (djgera)
Jan Alexander Steffens (heftig)
Dave Reisner (falconindy)
Christian Hesse (eworm)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 11
Private No

Details

Bug report instead of feature request because it used to work until https://git.archlinux.org/svntogit/packages.git/commit/?h=packages/prebootloader&id=88bac02c2d44724a4684b06aa38e0add11161cd7

Ideally, if somebody could get to ping Jejb for updated signed binaries it would be best.
Another alternative (as mentioned on Arch Wiki) is Fedora shim, but I haven't tested this directly and I wouldn't know whether it offers a worse or better OOTB experience.

This issue is getting more and more severe with time, since (putting aside 99% of computers are sold with SB enabled by default), W10 certification requirements dropped the "can be disabled" criteria and most OEMs are getting quite lazy.
This task depends upon

Comment by Gerardo Exequiel Pozzi (djgera) - Monday, 29 May 2017, 23:05 GMT
Did you read this? https://lists.archlinux.org/pipermail/arch-releng/2016-October/003748.html Nobody answer I guess there was no interest.
Comment by mirh (mirh) - Tuesday, 30 May 2017, 11:55 GMT
I don't find really surprising that the set of people using Arch *AND* also keen on checking its mailing lists, aren't really bothered by the lack of SB.
Thing is, besides nevertheless the little annoyance of "figuring out what's the matter" and tinkering with bios, as I was saying many newer computers cannot even disable it.

Then, I'm not sure how's Arch's financial situation, but the neatest solution would be to acquire a certificate, and use it to sign officially built binaries (which together with avoiding package duplication, would also finally bring-in a 4 years newer preloader)
Comment by mirh (mirh) - Saturday, 02 December 2017, 18:40 GMT
Seems like you don't even need a penny to jump aboard.
https://mjg59.dreamwidth.org/47438.html
Comment by mirh (mirh) - Friday, 23 February 2018, 13:24 GMT
  • Field changed: Percent Complete (100% → 0%)
Signed binaries with a key recognized by 99.9% of hardware is still missing. And you don't need to get in touch with microsoft. See my fedora shim link.
Comment by Gerardo Exequiel Pozzi (djgera) - Friday, 23 February 2018, 13:33 GMT
what is the difference between the current preloader/hashtool (efitools) vs shim? also shim works with systemd-boot? I can just replace preloader/hashtool with shim executables and that is all?
Comment by mirh (mirh) - Friday, 23 February 2018, 16:55 GMT
Current shipped preloader/hashtool aren't worth a thing basically.
Since the commit I mentioned above.
It eventually was even for the good, since that old version of the tools was creating problems on pre-secure-boot-specification UEFI systems.

Unless jejb puts out a newer signed version, I regret they don't look like a viable solution.

Shim on the other hand, yes, it's grub based.. *but* AFAIU there should be no problems to just use it to install arch's key (if not already rolled out), else just chainload whatever else you want afterwards.
And since at least v234 I'm kinda on the sure side systemd-boot should be totally fine with it.
https://github.com/systemd/systemd/pull/5702
Comment by Gerardo Exequiel Pozzi (djgera) - Friday, 23 February 2018, 17:19 GMT
Ok, then all things to do to make things working is:

0) move shim-signed from AUR to [extra]
1) install shim.efi in ${work_dir}/{iso,efiboot}/EFI/boot/bootx64.efi
2) install MokManager.efi in ${work_dir}/{iso,efiboot}/EFI/boot/MokManager.efi
3) install fallback.efi in ${work_dir}/{iso,efiboot}/EFI/boot/fallback.efi
4) install systemd-bootx64.efi in ${work_dir}/{iso,efiboot}/EFI/boot/grubx64.efi

correct? Or I am missing something
Comment by mirh (mirh) - Friday, 23 February 2018, 19:59 GMT
I.. think that should do it?
(and I guess like arch userbase won't mind to manually press a couple of buttons, instead of getting the thing to work automatically - albeit just know that still leave room for improving)

You'll have to also add Arch's key to the boot media though. Otherwise mokmanager is kinda on the useless side.
And behind the scenes you'll have to use it to sign bootloader/kernel/modules.
Comment by Gerardo Exequiel Pozzi (djgera) - Saturday, 24 February 2018, 03:16 GMT
are you sure that these extra steps are needed? I am unable to test restricted secure boot. if shim and mokmgr are signed with M$ key, why another key (from Arch) is really needed? is not supposed that mokmgr enroll needed hashes or I am missing something?

I remember these steps working with older prebootloader (signed by M$).
Comment by mirh (mirh) - Saturday, 24 February 2018, 17:00 GMT
Yes, and I think shim should support enrolling of just specific hashes too (I don't personally have a computer new enough to support 2.3.1 Errata C to test it either though)
The thing is, that it becomes very tiresome to have to enroll a newer one, every time kernel or bootloader gets updated.
Also, you'd have not only to modify boot iso, but also add a newer dependency/step to final installed images boot chain (to account for this last occurance)

If you want to test Secure Boot, I think latest VMWare 14 should support it (I'm not sure if microsoft public key is automatically added or not though)

Also, just for the records of your seemingly spite, shim (let alone anything microsoft-related) isn't needed at all to "take control" of one's own platform or add/modify keystore.
You wouldn't respect UEFI specification else (maybe you could spend some time reading Matthew Garrett blog if interested about details)
Just everybody use to rely on shim now, because vendor interfaces to do so are such various, random and sometimes lackluster that it's way better to better this last step onto something "common" whose code you even have at hand.
Comment by Gerardo Exequiel Pozzi (djgera) - Saturday, 24 February 2018, 17:23 GMT
So this is more beyond archiso scope, or at least to avoid duplicate work, since the kernel image of linux package must be signed and also systemd-boot from systemd package (and other bootloaders / bootmanagers)
Comment by mirh (mirh) - Sunday, 25 February 2018, 00:56 GMT
Indeed.

Sbsigntools and aur's sbupdate-git may help with that btw.
Comment by Gerardo Exequiel Pozzi (djgera) - Saturday, 03 March 2018, 17:37 GMT
Assigning relevant people related to "linux" and "systemd" packages. Looks like this feature needs changes in these pkgs, at least to be seamless.
Comment by mirh (mirh) - Saturday, 16 June 2018, 20:55 GMT
So.. I'm not sure how much bumping could be against etiquette, but has somebody currently at least _planned_ to work at this?
Comment by mirh (mirh) - Monday, 07 January 2019, 22:50 GMT
Again, I wouldn't want to push anybody...
But it's starting to become a bit of a shame to see *even* Debian getting there before of us
https://wiki.debian.org/SecureBoot
Comment by Dave Reisner (falconindy) - Monday, 07 January 2019, 23:41 GMT
Yes, "even Debian" who has at least an order of magnitude more headcount than us. Such a sad day for Arch when its volunteers can't pull it together.

I personally have no interest in working on this. It seems like you do, though, and as such you're in a great position to scope out the work and propose changes. I await your patches.
Comment by Jonas Witschel (diabonas) - Tuesday, 22 January 2019, 14:50 GMT
I have sent an email to the arch-releng mailing list, summarising and comparing the possible approaches to support Secure Boot and describing the necessary changes: https://lists.archlinux.org/pipermail/arch-releng/2019-January/003891.html
Comment by mirh (mirh) - Tuesday, 22 January 2019, 17:10 GMT
Thank you for the very detailed write-up.
I would also find reasonable every step of your plan.

The only thing I believe you have missed, is that shim would *always* allow keys enrolling, in addition to hashes.
It's just that if you haven't your very own (something that every big enough distro should have, still, imo) that cannot be unattended.
Comment by Jonas Witschel (diabonas) - Tuesday, 22 January 2019, 21:14 GMT
True, that's another advantage of using shim over efitools, which can only enrol files based on hashes. So in theory, Archiso could also create its own Machine Owner Key (MOK) and sign the boot loader and kernel with it. If the MOK is distributed on the ISO, users could enrol this key instead of enrolling the hashes of boot loader and binary. This has the advantage that only a single file needs to be enrolled instead of two, and if the same MOK is used for all releases of the ISO, updated images will work without having to enrol new hashes. (This approach is only necessary when using a shim built by a third party, if we get our own signed shim, the MOK can be replaced by the signing key embedded in the binary, as you say.)
Comment by Jan Alexander Steffens (heftig) - Tuesday, 22 January 2019, 23:45 GMT
Does this solution require injecting secret keys into package builds? That would currently be a blocker.
Comment by mirh (mirh) - Tuesday, 22 January 2019, 23:54 GMT
You would sign the kernel and bootloader with your private (and secret, yes of course) key, and you would ship the public one in the ISO (for users to enroll).
(that is, if you don't want users to re-enroll hashes on every update)

I'm not sure what kind of "injection" you are thinking.
Comment by Jan Alexander Steffens (heftig) - Tuesday, 22 January 2019, 23:57 GMT
Injecting as in allowing makepkg to access a secret key that is not part of the PKGBUILD (and thus public).
We're not set up for that and I suspect the reproducible-builds people will object to allowing such.
Comment by mirh (mirh) - Wednesday, 23 January 2019, 00:14 GMT
Well, yes then.
Ideally, you'd have the interested PKGBUILDs check if the keys file/folder exists (I believe people that don't care about SB would be pissed if it wasn't optional), and if yes use it as a parameter for the signing commands/hook.

If that's not set up yet on build servers.. Well, it shouldn't still stop any of the work getting discussed here
If you don't want SB, nothing will change. Otherwise you'll either make your own key, or enroll hashes.

And AFAIU reproducible builds should still be a possibility then.
Comment by Jonas Witschel (diabonas) - Wednesday, 23 January 2019, 06:52 GMT
Access to the secret key from makepkg is not necessary: instead, you can build the package locally, sign the necessary files with the secret key by creating a detached signature and add only the signature to the public repository, see https://wiki.debian.org/SecureBoot#line-158 In the PKGBUILD, you can then reassemble the detached signature and the created binary. This allows for reproducible builds and does not distribute any secret material.

Note that this is only necessary at all if we want to go the whole way and sign boot loader and kernel, as mirh pointed out: if you only distribute a signed shim (which would be the first step to support Secure Boot), there are no secret keys involved in the build: you need to create a signing key and store it somewhere safe, but the build of shim only requires the public key, which can be distributed alongside the PKGBUILD. Once the shim binary is signed by Microsoft, you can then detach the Microsoft signature, distribute it in the repositories, and reassemble it in the PKGBUILD to recreate the signed binary as described above. This allows to independently verify that Microsoft hasn't tampered with shim, because the signature will not be valid for the binary compiled by the original PKGBUILD.
Comment by Jonas Witschel (diabonas) - Wednesday, 23 January 2019, 14:35 GMT
I described a possible workflow for using detached signatures in https://lists.archlinux.org/pipermail/arch-releng/2019-January/003892.html
Comment by mirh (mirh) - Thursday, 24 January 2019, 21:03 GMT
Oh, that's the Debian way indeed.
It's also probably the only viable one if Arch's build servers are "around the world" too https://lwn.net/Articles/703001/
(so, signed packages would depend on whoever-the-guy to keep updated the signature in source files, but they could still be built "independently official")

..makepkg/secrecy limitations I had failed to consider above notwithstanding though, I'd still hope eventually self-signed PKGBUILDs could be an easy feat to pull off for any interested normal user.
Comment by Jussi Hietanen (jussihi) - Tuesday, 26 March 2019, 12:13 GMT
Sorry for chiming in really late. I did invest this issue too last year when I was creating a bootable ISO image based on archiso. One of the goals was to make it UEFI SB compatible. @mirh linked me this discussion.

I resorted to a shim and GRUB binaries "borrowed" from Ubuntu 14.04 installation disc IIRC. The good part of this old shim/GRUB combination is that the GRUB does not mind whether the kernel itself is signed or not. Only downside is that it seems to be impossible to load GRUB modules (ntfs module for example), which is not signed. But I can successfully boot unsigned kernels on a UEFI SB, since only the shim/GRUB binaries need to be signed.

Hope this helps :) And if this project needs further help, I am willing to help here.
Comment by Brian W (MrBW) - Sunday, 14 April 2019, 06:54 GMT
I might be in deep waters here because of lack of knowledge in SB and bootloaders.
But as far I know Ubuntu and Debian have hardcoded the EFI entry title/folder to be able to sign the EFI bootloader for SB support. The result is you cannot e.g. change the boot entry title (and name of the EFI bootloader folder), which again result in you cannot have e.g. two Ubuntu installation on the same box! How crazy is this?
You can also very easily screw up you boot if you install a second hard disk which happen to have another Debian/Ubuntu installation because EFI bootloaders have the same name and cannot be changed.
I actually use Archlinux to solve this issue because Arch's GRUB package it's NOT signed (I guess). I boot Arch from USB and overwrite Ubuntu/Debian's GRUB with Arch's and now I again have full control of my GRUB.
Please don't make the same mistake with Arch in the eager to enable SB.
I am aware Arch's default bootloader is systemd-boot.
Comment by Jussi Hietanen (jussihi) - Sunday, 14 April 2019, 07:32 GMT
Brian: You are right in the part you cannot change the Bootloader folder, if you mean the /esp/boot/grub boot folder. Otherwise you are simply wrong. You can have two Ubuntu/whatever installations in the same box, just add two GRUB configs for the different ubuntu installations to the same single GRUB installation... Also since the bootloader title is set in the machine itself, and you can choose it during "registering" the bootloader (by using the efibootmgr, for example), the bootloader name in the system can also be altered. So two hard disks and therefore two EFI binaries are not a problem if you want to go that way...
Comment by Brian W (MrBW) - Sunday, 14 April 2019, 08:02 GMT
Yes, you are right you can change the title with efibootmgr.
But bottom line is you cannot use option "--bootloader-id=xxx" of grub-install when the EFI loader is signed and that is a big issue in my view.
Some (e.g. you) might be able to install multiple instances of the same OS because of extended knowledge of GRUB and the boot process, but many don't, myself included.
Don't make GRUB even more difficult to configure/setup than it already is.

Regarding the adding HDDs issue: I can just say you easily run into a non-bootable system. I was not able myself to fix it even after hours Google'ing. No reason to make the boot-process even more vulnerable. Again, it might be an easy issue for you to fix, but I will claim, it's not for many user, might even for the majority (just Google).

I understand and vote myself for SB support, just make it optional! Don't force it and screw it up for some other users ;-)
Apparently Ubuntu and Debian didn't seem to make it optional, so when I ran into this thread I got really nervous.
Comment by mirh (mirh) - Tuesday, 09 July 2019, 21:36 GMT
SB isn't "mandated" anywhere in x86 world, so I 'm not really sure what's the matter here.
And OS support for it definitively isn't going to affect either way firmware settings (whatever the relationship with the new HDD could be).

Anyway back on earth, while I was discussing of similar matters in the M-word distro forums, I fully realized what debian's solution entailed in practice https://debamax.com/blog/2019/04/19/an-overview-of-secure-boot-in-debian/

Put aside the crazy "having to enroll your hashes every time you update the kernel" options, so you:
* confusingly duplicate code with normal and signed versions of every interested package, OR
* build them on the single secret location, then in turn push the whole thing worldwide (sounds especially inelegant for kernels), OR
* let everyone build on their own, with the only "centralized bit" coming from the signature

And.. Assuming Arch will also choose this last way, I feel like some very impressive makepkg-fu will be needed (as also partially hinted in Jonas' last mail).
Eventually I think this is the biggest conundrum. Keeping the most of simplicity with the most of transparency. And the servers in sync.
But maybe I'm putting my nose too much into the maintainers job...

Loading...