Arch Linux

Did you read this? https://lists.archlinux.org/pipermail/arch-releng/2016-October/003748.html Nobody answer I guess there was no interest.

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)

Seems like you don't even need a penny to jump aboard.
https://mjg59.dreamwidth.org/47438.html

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.

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?

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

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

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.

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$).

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.

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)

Indeed.

Sbsigntools and aur's sbupdate-git may help with that btw.

Assigning relevant people related to "linux" and "systemd" packages. Looks like this feature needs changes in these pkgs, at least to be seamless.

So.. I'm not sure how much bumping could be against etiquette, but has somebody currently at least _planned_ to work at this?

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

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.

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

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.

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.)

Does this solution require injecting secret keys into package builds? That would currently be a blocker.

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.

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.

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.

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.

I described a possible workflow for using detached signatures in https://lists.archlinux.org/pipermail/arch-releng/2019-January/003892.html

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.

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.

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.

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...

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.

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...

I would suggest the following:

Have 2 version of grub available in the package repos: grub and grub-signed. (also why not signed and unsigned versions of systemd-boot..?)
- The signed version would include the Microsoft-signed shim bundled with a grub binary signed with Arch's certificate (and the signed shim would verify this).
- The unsigned version would have only non-modified grub without shim. This would target non-SB machines.

Since the Secure Boot auth chain can end to the feature-rich bootloader (here grub), both of these setups could use the same, unsigned, kernel. This is how it is done in Ubuntu for example, because I'm able to "borrow" their shim+grub to build an SB-compatible archiso with Arch kernel and initramfs.

However, for generating a fresh archiso, this would need a change in the pipeline so that the pipeline generates 2 different iso images - one unsigned one just as it is right now, and one signed iso image with this sort of shim-->signed grub-->unsigned kernel+initramfs boot chain. During the installation the user should first burn an ISO compatible for their platform (either the ISO with SB-compatible bootloader chain or the unsigned one) and when bootstrapping to the HDD could have the choice to install either one of for example the unsigned systemd-boot or the signed grub bootloader from the Arch repo. This way the kernel would not need to be signed, and the SB-compatible bootloader would merely exist only for those people that can't disable it from their machine..?

It is my understanding (but I'm a bit rusty after all these years) that signed shim/grub shouldn't work any differently in an unsecured enviroment.

Also, ubuntu *do* require signing since 16.04.
But just on SB-enabled system, thanks to a patch (not sure why it hasn't been upstreamed yet)
https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/unstable/log/arch/x86/kernel
https://src.fedoraproject.org/rpms/kernel/blob/master/f/0001-efi-Lock-down-the-kernel-if-booted-in-secure-boot-mo.patch

Which makes all sense of the world since for the user everything is as smooth as possible.
SB-off is the same that it ever was, and you just gain support for the proper SB-on case (whose security you may or may not care and appreciate).

p.s. putting aside that the only thing separating shims is the signature they automatically accept in unattended mode, maybe their grub is also working fine due to this
https://github.com/torvalds/linux/commit/f3cf6f7434debcc65f397228c689641b07c1be35

So.. how are we doing?
Like, did we even settle which theoretical design is good to begin with?

@mirh: It looks like we'll try going the shim direction for archiso.

For this purpose shim has now been added to [community].
Note, that it is an unsigned version of course and we now have to get involved in the rest of the process as described by @diabonas

There seems to be no developement in this space. I hope someone starts working on this feature request, as it's definitely would be a good feature to have in archlinux

I am made a project for myself to add Secure Boot to archiso => https://github.com/solsticedhiver/archiso-sb-shim/

It is basically a very simple patch to mkarchiso that adds shim to the archiso. You have to enroll your keys with shim before booting it. As this is custom made, you can include your key, on the iso.

What would be needed so that that patch is included in archlinux?