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 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 10
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?

Loading...