| View previous topic :: View next topic |
| Author |
Message |
akhowell
n00b
Joined: 02 Jan 2025
Posts: 2
Location: Australia
|
 Posted: Fri Jan 03, 2025 11:43 pm Post subject: Secureboot issue booting distribution kernels after 6.12.6 |
 |
|
I have a new Gentoo install on an AMD Threadripper 7960 on a Gigabyte Aero D TRX50 motherboard. BIOS version is up to date. I have successfully set up SecureBoot with gentoo-kernel-bin 6.12.6, which boots via Shim, then Grub. When I install gentoo-kernel-bin 6.12.7 and 6.12.8, when Grub initiates the kernel boot it almost instantly goes to a screen indicating a signature error. Its too early to capture any data - it doesn't even get to Initrc so the best I've been able to do is take a photo of the screen, but it starts with "sum of bytes hashed". Working with ChatGPT, because I couldn't find anything at all relevant on Google, I have noticed a difference between /usr/src/linux-6.12.6-gentoo-dist/arch/x86/boot/bzImage and /usr/src/linux-6.12.7-gentoo-dist/arch/x86/boot/bzImage (same for 6.12.8). "sbverify --list bzImage" against 6.12.7 and 6.12.8 reveals a warning "warning: data remaining[20364272 vs 20364288]: gaps between PE/COFF sections?"
"objdump -h bzImage" for 6.12.6 and 6.12.7 reveals identical results.
| Code: | /usr/src/linux-6.12.6-gentoo-dist/arch/x86/boot/bzImage: file format pei-x86-64
Sections:
Idx Name Size VMA LMA File off Algn
0 .setup 00003000 0000000000001000 0000000000001000 00001000 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .compat 00001000 0000000000004000 0000000000004000 00004000 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .text 01366000 0000000000005000 0000000000005000 00005000 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
3 .data 00001200 000000000136b000 000000000136b000 0136b000 2**4
CONTENTS, ALLOC, LOAD, DATA
|
while 6.12.8 shows
| Code: | /usr/src/linux-6.12.8-gentoo-dist/arch/x86/boot/bzImage: file format pei-x86-64
Sections:
Idx Name Size VMA LMA File off Algn
0 .setup 00003000 0000000000001000 0000000000001000 00001000 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .compat 00001000 0000000000004000 0000000000004000 00004000 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .text 01365000 0000000000005000 0000000000005000 00005000 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
3 .data 00001200 000000000136a000 000000000136a000 0136a000 2**4
CONTENTS, ALLOC, LOAD, DATA
|
Given that these files are part of the gentoo-kernel-bin package, and not generated locally on my machine, I am wondering if something changed with the way the bzImage files were generated between gentoo-kernel-bin 6.12.6 and 6.12.7, or if there is a step somewhere along the way that I have missed that is causing my resultant vmlinuz files generate when the package is merged to fail signature verification. I note all 3 versions boot correctly with SecureBoot turned off but I would really like to keep it active if possible.
If there's any further information I can provide to help diagnose what's going on please let me know.
[Administrator edit: added [code] tags to preserve output layout. -Hu] |
|
| Back to top |
|
 |
Nowa
Developer
Joined: 25 Jun 2014
Posts: 470
Location: Nijmegen
|
| Posted: Sat Jan 04, 2025 9:36 am Post subject: |
|
|
It's a bug in systemd 257: https://github.com/systemd/systemd/issues/35851
Still looking for a workaround. The cause of the problem is that the kernel image extracted by objcopy is different and now contains these gaps invalidating the signature.
_________________
OS: Gentoo 6.10.12-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400 |
|
| Back to top |
|
|
Child_of_Sun_24
l33t
Joined: 28 Jul 2004
Posts: 611
|
| Posted: Sat Jan 04, 2025 6:37 pm Post subject: |
|
|
| Don't know if it helps or is relevant for this thread but i am using systemd-257.1 and gentoo-sources-6.12.8. I use sys-boot/shim and sys-boot/grub for booting, and for me the signing of the vmlinuz image does work as expected. Don't know if it is different to the dist kernel because i compile the kernel myself. |
|
| Back to top |
|
|
Nowa
Developer
Joined: 25 Jun 2014
Posts: 470
Location: Nijmegen
|
| Posted: Sat Jan 04, 2025 8:04 pm Post subject: |
|
|
| Child_of_Sun_24 wrote: | | Don't know if it helps or is relevant for this thread but i am using systemd-257.1 and gentoo-sources-6.12.8. I use sys-boot/shim and sys-boot/grub for booting, and for me the signing of the vmlinuz image does work as expected. Don't know if it is different to the dist kernel because i compile the kernel myself. |
Specifically the issue is in systemd 257's ukify, if you are not building a binpkg with a generic-uki inside (like we do for gentoo-kernel-bin) then you won't be affected by this problem. This affects only gentoo-kernel-bin and gentoo-kernel[generic-uki].
As a short-term workaround you can use app-crypt/sbctl and it's kernel installation hook to sign the kernel again with the key that you're also using for grub (or do that manually)
_________________
OS: Gentoo 6.10.12-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400 |
|
| Back to top |
|
|
Child_of_Sun_24
l33t
Joined: 28 Jul 2004
Posts: 611
|
| Posted: Sat Jan 04, 2025 8:50 pm Post subject: |
|
|
No i don't build a uki, i build an efi-stub, so i am not affected.
And i always sign my kernel and grub manually  |
|
| Back to top |
|
|
akhowell
n00b
Joined: 02 Jan 2025
Posts: 2
Location: Australia
|
| Posted: Sun Jan 05, 2025 10:09 pm Post subject: |
|
|
| Nowa wrote: | | Child_of_Sun_24 wrote: | | Don't know if it helps or is relevant for this thread but i am using systemd-257.1 and gentoo-sources-6.12.8. I use sys-boot/shim and sys-boot/grub for booting, and for me the signing of the vmlinuz image does work as expected. Don't know if it is different to the dist kernel because i compile the kernel myself. |
Specifically the issue is in systemd 257's ukify, if you are not building a binpkg with a generic-uki inside (like we do for gentoo-kernel-bin) then you won't be affected by this problem. This affects only gentoo-kernel-bin and gentoo-kernel[generic-uki].
As a short-term workaround you can use app-crypt/sbctl and it's kernel installation hook to sign the kernel again with the key that you're also using for grub (or do that manually) |
Thanks for the pointer. I ended up compiling from gentoo-kernel and signing the kernel myself,, which is working perfectly. |
|
| Back to top |
|
|
Nowa
Developer
Joined: 25 Jun 2014
Posts: 470
Location: Nijmegen
|
| Posted: Fri Jan 10, 2025 4:47 pm Post subject: |
|
|
We now have a workaround for this problem in the tree, re-installing gentoo-kernel-bin will automatically fix the kernel image so the signature verifies again. Please do let me know if there is still some problem in this area.
_________________
OS: Gentoo 6.10.12-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400 |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
