rhboot / shim

UEFI shim loader
Other
816 stars 284 forks source link

Is 15.8 being prepared? #615

Open TBOpen opened 9 months ago

TBOpen commented 9 months ago

I'd like to just get a clean 15.8 to update without having to use 15.7 with patches. Is that almost ready? Otherwise I guess I'll have to do the 15.7 with patch since it appears some new mobo/bios now stop loading the 15. 4 version.

julian-klode commented 9 months ago

More or less NX support is a bit um broken and people are trying to sort it out. Also nobody is actively reviewing shims right now to my knowledge so it's likely just useless work to try to go and build now.

Some systems discover the NX flag on shim and enable NX mode, but then kernels are not ready and your grub also needs to be and the patches are not merged either, so then you regress vs older shim because these systems fail to boot.

But you cannot submit a shim without that flag even if we managed to review it because MS doesn't sign without the flag anymore, so it's all a bit stuck.

TBOpen commented 9 months ago

Why couldn't the firmware have simply checked the actually alignment instead of relying on a notification bit flag?

So that then sounds like we will have to upgrade GRUB again? Please please please, put together a single ready-to-use grub source directory so it's not so confusing with all the required patches. People could still provide small patches for custom things that aren't security related to that secure baseline.

Also please consider my patch for mainline to deal with booting things not called "grubx64.efi". I'll attach here again (it was from 15.4 - had a couple bug fixes as well - and removed some stuff peter put in for me (different than my actual patch) back in the early days - mine was actually 32kernel on 64bit uefi - but that no longer works on the modern systems, I guess 32bit UEFI on 64bit system could still allow 64bit kernel but I think the logic is in that other location mentioned). Of course my Acme stuff doesn't apply.

shim-15.4.patch

Thanks!!

es-fabricemarie commented 7 months ago

More or less NX support is a bit um broken and people are trying to sort it out.

@julian-klode Could you please explain a bit more on the state of NX_Compat support?

I've been reading all comments in shim/shim-review and I can't find clarity. I can't seem to find much activity on the kernel mailing list regarding NX_Compat either.

Example: what would happen if I were to build my shim using HEAD from git (it has NX_Compat enabled by default right) and a 6.6 kernel? Would that boot? When you say "fail to boot" what are the typical symptoms?

Thanks a lot in advance for your help

julian-klode commented 7 months ago

Work on NX is ongoing also see the NX Exception https://techcommunity.microsoft.com/t5/hardware-dev-center/nx-exception-for-shim-community/ba-p/3976522#M147

Kernel patches should be in 6.7 AFAIK

es-fabricemarie commented 7 months ago

@julian-klode Does this mean we can submit a new shim (new vendor) for review with NX Compat turned off? (and then wait for the kernel to support it properly?)

joeyli commented 7 months ago

Work on NX is ongoing also see the NX Exception https://techcommunity.microsoft.com/t5/hardware-dev-center/nx-exception-for-shim-community/ba-p/3976522#M147

Kernel patches should be in 6.7 AFAIK

Per my understood, v6.6 kernel includes the following patches of x86/decompressor. It also supports EFI memory attributes protocol :

264b82fdb4989cf6a44a2bcd0c6ea05e8026b2ac x86/decompressor: Don't rely on upper 32 bits of GPRs being preserved 2f69a81ad6873231a2ae78d5ade3263ec54a4c9c x86/head_64: Store boot_params pointer in callee save register d2d7a54f69b67cd0a30e0ebb5307cb2de625baac x86/efistub: Branch straight to kernel entry point from C code df9215f15206c2a81909ccf60f21d170801dce38 x86/efistub: Simplify and clean up handover entry code 12792064587623065250069d1df980e2c9ac3e67 x86/decompressor: Avoid magic offsets for EFI handover entrypoint d7156b986d4cc0657fa6dc05c9fcf51c3d55a0fe x86/efistub: Clear BSS in EFI handover protocol entrypoint 8b63cba746f86a754d66e302c43209cc9b9b6e39 x86/decompressor: Store boot_params pointer in callee save register 00c6b0978ec182f1a672095930872168b9d5b1e2 x86/decompressor: Assign paging related global variables earlier e8972a76aa90c05a0078043413f806c02fcb3487 x86/decompressor: Call trampoline as a normal function 918a7a04e71745e99a0efc6753e587439b794b29 x86/decompressor: Use standard calling convention for trampoline bd328aa01ff77a45aeffea5fc4521854291db11f x86/decompressor: Avoid the need for a stack in the 32-bit trampoline 64ef578b6b6866bec012544416946533444036c8 x86/decompressor: Call trampoline directly from C code f97b67a773cd84bd8b55c0a0ec32448a87fc56bb x86/decompressor: Only call the trampoline when changing paging levels cb83cece57e1889109dd73ea08ee338668c9d1b8 x86/decompressor: Pass pgtable address to trampoline directly 03dda95137d3247564854ad9032c0354273a159d x86/decompressor: Merge trampoline cleanup with switching code cb1c9e02b0c13032c3aec325643453ba48e96e17 x86/efistub: Perform 4/5 level paging switch from the stub 11078876b7a6a1b7226344fecab968945c806832 x86/efistub: Prefer EFI memory attributes protocol over DXE services 8217ad0a435ff06d651d7298ea8ae8d72388179e decompress: Use 8 byte alignment 24388292e2d7fae79a0d4183cc91716b851299cf x86/decompressor: Move global symbol references to C code 83381519352d6b5b3e429bf72aaab907480cb6b6 x86/decompressor: Factor out kernel decompression and relocation bc5ddceff4c14494d83449ad45c985e6cd353fce efi/libstub: Add limit argument to efi_random_alloc() 31c77a50992e8dd136feed7b67073bb5f1f978cc x86/efistub: Perform SNP feature test while running in the firmware a1b87d54f4e45ff5e0d081fb1d9db3bf1a8fb39a x86/efistub: Avoid legacy decompressor when doing EFI boot

Do we have more patches relate to NX support in v6.7 kernel? I think that shim-review should provide a patches list for supporting NX. It's useful for shi-review and also good for kernel backporting. Because distro should maintains old kernel version with shim for NX.

es-fabricemarie commented 7 months ago

@julian-klode you mentioned grub upstream not being ready either?