[REGRESSION] linux 6.6.18 and later fails to boot with "initramfs unpacking failed: invalid magic at start of compressed archive"

[REGRESSION] linux 6.6.18 and later fails to boot with "initramfs unpacking failed: invalid magic at start of compressed archive"

[Radek Podgorny]

[-- Attachment #1.1: Type: text/plain, Size: 2269 bytes --]

hi,

i seem to be the only one in the world to have this problem. :-(

on one of my machines, updating to 6.6.18 and later (including mainline 
branch) leads to unbootable system. all other computers are unaffected.

bisecting the history leads to:

commit 8117961d98fb2d335ab6de2cad7afb8b6171f5fe
Author: Ard Biesheuvel <ardb@kernel.org> 
 

Date:   Tue Sep 12 09:00:53 2023 +0000 
 

 
 

     x86/efi: Disregard setup header of loaded image 
 

 
 

     commit 7e50262229faad0c7b8c54477cd1c883f31cc4a7 upstream. 
 


     The native EFI entrypoint does not take a struct boot_params from the
     loader, but instead, it constructs one from scratch, using the setup
     header data placed at the start of the image.

     This setup header is placed in a way that permits legacy loaders to
     manipulate the contents (i.e., to pass the kernel command line or the
     address and size of an initial ramdisk), but EFI boot does not use 
it in
     that way - it only copies the contents that were placed there at build
     time, but EFI loaders will not (and should not) manipulate the setup
     header to configure the boot. (Commit 63bf28ceb3ebbe76 "efi: x86: Wipe
     setup_data on pure EFI boot" deals with some of the fallout of using
     setup_data in a way that breaks EFI boot.)

     Given that none of the non-zero values that are copied from the setup
     header into the EFI stub's struct boot_params are relevant to the boot
     now that the EFI stub no longer enters via the legacy decompressor, the
     copy can be omitted altogether.

     Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
     Signed-off-by: Ingo Molnar <mingo@kernel.org>
     Link: 
https://lore.kernel.org/r/20230912090051.4014114-19-ardb@google.com
     Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

this seems to be the commit to introduce the regression.

i have no idea where to look and what information to provide to explain 
what the problem might be or why this single machine is different. :-(

please don't hesitate to ask me further questions - i can do any 
debugging you may need on your behalf.

sincerely,
R.

#regzbot introduced: 8117961d98fb2d335ab6de2cad7afb8b6171f5fe

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [REGRESSION] linux 6.6.18 and later fails to boot with "initramfs unpacking failed: invalid magic at start of compressed archive"

[Ard Biesheuvel]

On Thu, 14 Mar 2024 at 19:32, Radek Podgorny <radek@podgorny.cz> wrote:
>
> hi,
>
> i seem to be the only one in the world to have this problem. :-(
>
> on one of my machines, updating to 6.6.18 and later (including mainline
> branch) leads to unbootable system. all other computers are unaffected.
>
> bisecting the history leads to:
>
> commit 8117961d98fb2d335ab6de2cad7afb8b6171f5fe
> Author: Ard Biesheuvel <ardb@kernel.org>
>

Thanks for the report.

I'd like to get to the bottom of this if we can.

Please share as much information as you can about the system
- boot logs
- DMI data to identify the system and firmware etc
- distro version
- versions of boot components (shim, grub, systemd-boot, etc including
config files)
- other information that might help narrow this down.

Re: [REGRESSION] linux 6.6.18 and later fails to boot with "initramfs unpacking failed: invalid magic at start of compressed archive"

[Ard Biesheuvel]

On Thu, 14 Mar 2024 at 20:35, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Thu, 14 Mar 2024 at 19:32, Radek Podgorny <radek@podgorny.cz> wrote:
> >
> > hi,
> >
> > i seem to be the only one in the world to have this problem. :-(
> >
> > on one of my machines, updating to 6.6.18 and later (including mainline
> > branch) leads to unbootable system. all other computers are unaffected.
> >
> > bisecting the history leads to:
> >
> > commit 8117961d98fb2d335ab6de2cad7afb8b6171f5fe
> > Author: Ard Biesheuvel <ardb@kernel.org>
> >
>
> Thanks for the report.
>
> I'd like to get to the bottom of this if we can.
>
> Please share as much information as you can about the system
> - boot logs
> - DMI data to identify the system and firmware etc
> - distro version
> - versions of boot components (shim, grub, systemd-boot, etc including
> config files)
> - other information that might help narrow this down.

Also, please check whether the below change makes a difference or not

--- a/drivers/firmware/efi/libstub/x86-stub.c
+++ b/drivers/firmware/efi/libstub/x86-stub.c
@@ -477,6 +477,8 @@
                efi_exit(handle, status);
        }

+       memset(&boot_params, 0, sizeof(boot_params));
+
        /* Assign the setup_header fields that the kernel actually
cares about */
        hdr->root_flags = 1;
        hdr->vid_mode   = 0xffff;

Re: [REGRESSION] linux 6.6.18 and later fails to boot with "initramfs unpacking failed: invalid magic at start of compressed archive"

[Ard Biesheuvel]

On Thu, 14 Mar 2024 at 22:53, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Thu, 14 Mar 2024 at 20:35, Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Thu, 14 Mar 2024 at 19:32, Radek Podgorny <radek@podgorny.cz> wrote:
> > >
> > > hi,
> > >
> > > i seem to be the only one in the world to have this problem. :-(
> > >
> > > on one of my machines, updating to 6.6.18 and later (including mainline
> > > branch) leads to unbootable system. all other computers are unaffected.
> > >
> > > bisecting the history leads to:
> > >
> > > commit 8117961d98fb2d335ab6de2cad7afb8b6171f5fe
> > > Author: Ard Biesheuvel <ardb@kernel.org>
> > >
> >
> > Thanks for the report.
> >
> > I'd like to get to the bottom of this if we can.
> >
> > Please share as much information as you can about the system
> > - boot logs
> > - DMI data to identify the system and firmware etc
> > - distro version
> > - versions of boot components (shim, grub, systemd-boot, etc including
> > config files)
> > - other information that might help narrow this down.
>
> Also, please check whether the below change makes a difference or not
>
> --- a/drivers/firmware/efi/libstub/x86-stub.c
> +++ b/drivers/firmware/efi/libstub/x86-stub.c
> @@ -477,6 +477,8 @@
>                 efi_exit(handle, status);
>         }
>
> +       memset(&boot_params, 0, sizeof(boot_params));
> +
>         /* Assign the setup_header fields that the kernel actually
> cares about */
>         hdr->root_flags = 1;
>         hdr->vid_mode   = 0xffff;

Another thing you might try is reverting commit

commit 5f51c5d0e905608ba7be126737f7c84a793ae1aa
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Tue Sep 12 09:00:52 2023 +0000

    x86/efi: Drop EFI stub .bss from .data section

(in v6.6 the commit id is fa244085025f4a8fb38ec67af635aed04297758d)

Re: [REGRESSION] linux 6.6.18 and later fails to boot with "initramfs unpacking failed: invalid magic at start of compressed archive"

[Radek Podgorny]

[-- Attachment #1.1.1: Type: text/plain, Size: 2737 bytes --]

hi ard, thanks for the effort!

so, your first recommended patch (the memset thing), applied to current 
mainline (6.8) DOES NOT resolve the issue.

the second recommendation, a revert patch, applied to the same mainline 
tree, indeed DOES resolve the problem.

just to be sure, i'm attaching the revert patch.

as for the information to find the cause:

* boot logs - can't really give you as the boot process just stops - i 
can send you a picture of the screen taken with my phone.

* dmi data - attaching dmidecode output

* distro - current arch linux (rolling distro) - attaching list of 
installed packages with versions

* versions of boot components - should be included in the listing above

feel free to send me any patches, i'll be happy to try them out!

cheers,
R.


On 3/15/24 08:42, Ard Biesheuvel wrote:
> On Thu, 14 Mar 2024 at 22:53, Ard Biesheuvel <ardb@kernel.org> wrote:
>>
>> On Thu, 14 Mar 2024 at 20:35, Ard Biesheuvel <ardb@kernel.org> wrote:
>>>
>>> On Thu, 14 Mar 2024 at 19:32, Radek Podgorny <radek@podgorny.cz> wrote:
>>>>
>>>> hi,
>>>>
>>>> i seem to be the only one in the world to have this problem. :-(
>>>>
>>>> on one of my machines, updating to 6.6.18 and later (including mainline
>>>> branch) leads to unbootable system. all other computers are unaffected.
>>>>
>>>> bisecting the history leads to:
>>>>
>>>> commit 8117961d98fb2d335ab6de2cad7afb8b6171f5fe
>>>> Author: Ard Biesheuvel <ardb@kernel.org>
>>>>
>>>
>>> Thanks for the report.
>>>
>>> I'd like to get to the bottom of this if we can.
>>>
>>> Please share as much information as you can about the system
>>> - boot logs
>>> - DMI data to identify the system and firmware etc
>>> - distro version
>>> - versions of boot components (shim, grub, systemd-boot, etc including
>>> config files)
>>> - other information that might help narrow this down.
>>
>> Also, please check whether the below change makes a difference or not
>>
>> --- a/drivers/firmware/efi/libstub/x86-stub.c
>> +++ b/drivers/firmware/efi/libstub/x86-stub.c
>> @@ -477,6 +477,8 @@
>>                  efi_exit(handle, status);
>>          }
>>
>> +       memset(&boot_params, 0, sizeof(boot_params));
>> +
>>          /* Assign the setup_header fields that the kernel actually
>> cares about */
>>          hdr->root_flags = 1;
>>          hdr->vid_mode   = 0xffff;
> 
> Another thing you might try is reverting commit
> 
> commit 5f51c5d0e905608ba7be126737f7c84a793ae1aa
> Author: Ard Biesheuvel <ardb@kernel.org>
> Date:   Tue Sep 12 09:00:52 2023 +0000
> 
>      x86/efi: Drop EFI stub .bss from .data section
> 
> (in v6.6 the commit id is fa244085025f4a8fb38ec67af635aed04297758d)

[-- Attachment #1.1.2: dmidecode.txt --]
[-- Type: text/plain, Size: 21295 bytes --]

# dmidecode 3.5
Getting SMBIOS data from sysfs.
SMBIOS 2.7 present.
75 structures occupying 3069 bytes.
Table at 0x000EB420.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
	Vendor: American Megatrends Inc.
	Version: F4
	Release Date: 03/23/2012
	Address: 0xF0000
	Runtime Size: 64 kB
	ROM Size: 2560 kB
	Characteristics:
		PCI is supported
		BIOS is upgradeable
		BIOS shadowing is allowed
		Boot from CD is supported
		Selectable boot is supported
		BIOS ROM is socketed
		EDD is supported
		5.25"/1.2 MB floppy services are supported (int 13h)
		3.5"/720 kB floppy services are supported (int 13h)
		3.5"/2.88 MB floppy services are supported (int 13h)
		Print screen service is supported (int 5h)
		8042 keyboard services are supported (int 9h)
		Serial services are supported (int 14h)
		Printer services are supported (int 17h)
		ACPI is supported
		USB legacy is supported
		BIOS boot specification is supported
		Targeted content distribution is supported
		UEFI is supported
	BIOS Revision: 4.6

Handle 0x0001, DMI type 1, 27 bytes
System Information
	Manufacturer: Gigabyte Technology Co., Ltd.
	Product Name: To be filled by O.E.M.
	Version: To be filled by O.E.M.
	Serial Number: To be filled by O.E.M.
	UUID: 03000200-0400-0500-0006-000700080009
	Wake-up Type: Power Switch
	SKU Number: To be filled by O.E.M.
	Family: To be filled by O.E.M.

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
	Manufacturer: Gigabyte Technology Co., Ltd.
	Product Name: H61MA-D2V
	Version: x.x
	Serial Number: To be filled by O.E.M.
	Asset Tag: To be filled by O.E.M.
	Features:
		Board is a hosting board
		Board is replaceable
	Location In Chassis: To be filled by O.E.M.
	Chassis Handle: 0x0003
	Type: Motherboard
	Contained Object Handles: 0

Handle 0x0003, DMI type 3, 22 bytes
Chassis Information
	Manufacturer: Gigabyte Technology Co., Ltd.
	Type: Desktop
	Lock: Not Present
	Version: To Be Filled By O.E.M.
	Serial Number: To Be Filled By O.E.M.
	Asset Tag: To Be Filled By O.E.M.
	Boot-up State: Safe
	Power Supply State: Safe
	Thermal State: Safe
	Security Status: None
	OEM Information: 0x00000000
	Height: Unspecified
	Number Of Power Cords: 1
	Contained Elements: 0
	SKU Number: To be filled by O.E.M.

Handle 0x0004, DMI type 7, 19 bytes
Cache Information
	Socket Designation: CPU Internal L1
	Configuration: Enabled, Not Socketed, Level 1
	Operational Mode: Write Through
	Location: Internal
	Installed Size: 64 kB
	Maximum Size: 64 kB
	Supported SRAM Types:
		Unknown
	Installed SRAM Type: Unknown
	Speed: Unknown
	Error Correction Type: Parity
	System Type: Other
	Associativity: 16-way Set-associative

Handle 0x0005, DMI type 7, 19 bytes
Cache Information
	Socket Designation: CPU Internal L2
	Configuration: Enabled, Not Socketed, Level 2
	Operational Mode: Write Through
	Location: Internal
	Installed Size: 512 kB
	Maximum Size: 512 kB
	Supported SRAM Types:
		Unknown
	Installed SRAM Type: Unknown
	Speed: Unknown
	Error Correction Type: Multi-bit ECC
	System Type: Instruction
	Associativity: 16-way Set-associative

Handle 0x0006, DMI type 7, 19 bytes
Cache Information
	Socket Designation: CPU Internal L3
	Configuration: Enabled, Not Socketed, Level 3
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 3 MB
	Maximum Size: 3 MB
	Supported SRAM Types:
		Unknown
	Installed SRAM Type: Unknown
	Speed: Unknown
	Error Correction Type: Multi-bit ECC
	System Type: Instruction
	Associativity: 48-way Set-associative

Handle 0x0007, DMI type 16, 23 bytes
Physical Memory Array
	Location: System Board Or Motherboard
	Use: System Memory
	Error Correction Type: None
	Maximum Capacity: 32 GB
	Error Information Handle: Not Provided
	Number Of Devices: 4

Handle 0x0008, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1A1
	Internal Connector Type: None
	External Reference Designator: PS2Mouse
	External Connector Type: PS/2
	Port Type: Mouse Port

Handle 0x0009, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1A1
	Internal Connector Type: None
	External Reference Designator: Keyboard
	External Connector Type: PS/2
	Port Type: Keyboard Port

Handle 0x000A, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J2A1
	Internal Connector Type: None
	External Reference Designator: TV Out
	External Connector Type: Mini Centronics Type-14
	Port Type: Other

Handle 0x000B, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J2A2A
	Internal Connector Type: None
	External Reference Designator: COM A
	External Connector Type: DB-9 male
	Port Type: Serial Port 16550A Compatible

Handle 0x000C, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J2A2B
	Internal Connector Type: None
	External Reference Designator: Video
	External Connector Type: DB-15 female
	Port Type: Video Port

Handle 0x000D, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J3A1
	Internal Connector Type: None
	External Reference Designator: USB1
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x000E, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J3A1
	Internal Connector Type: None
	External Reference Designator: USB2
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x000F, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J3A1
	Internal Connector Type: None
	External Reference Designator: USB3
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x0010, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J9A1 - TPM HDR
	Internal Connector Type: Other
	External Reference Designator: Not Specified
	External Connector Type: None
	Port Type: Other

Handle 0x0011, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J9C1 - PCIE DOCKING CONN
	Internal Connector Type: Other
	External Reference Designator: Not Specified
	External Connector Type: None
	Port Type: Other

Handle 0x0012, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J2B3 - CPU FAN
	Internal Connector Type: Other
	External Reference Designator: Not Specified
	External Connector Type: None
	Port Type: Other

Handle 0x0013, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J6C2 - EXT HDMI
	Internal Connector Type: Other
	External Reference Designator: Not Specified
	External Connector Type: None
	Port Type: Other

Handle 0x0014, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J3C1 - GMCH FAN
	Internal Connector Type: Other
	External Reference Designator: Not Specified
	External Connector Type: None
	Port Type: Other

Handle 0x0015, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1D1 - ITP
	Internal Connector Type: Other
	External Reference Designator: Not Specified
	External Connector Type: None
	Port Type: Other

Handle 0x0016, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J9E2 - MDC INTPSR
	Internal Connector Type: Other
	External Reference Designator: Not Specified
	External Connector Type: None
	Port Type: Other

Handle 0x0017, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J9E4 - MDC INTPSR
	Internal Connector Type: Other
	External Reference Designator: Not Specified
	External Connector Type: None
	Port Type: Other

Handle 0x0018, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J9E3 - LPC HOT DOCKING
	Internal Connector Type: Other
	External Reference Designator: Not Specified
	External Connector Type: None
	Port Type: Other

Handle 0x0019, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J9E1 - SCAN MATRIX
	Internal Connector Type: Other
	External Reference Designator: Not Specified
	External Connector Type: None
	Port Type: Other

Handle 0x001A, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J9G1 - LPC SIDE BAND
	Internal Connector Type: Other
	External Reference Designator: Not Specified
	External Connector Type: None
	Port Type: Other

Handle 0x001B, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J8F1 - UNIFIED
	Internal Connector Type: Other
	External Reference Designator: Not Specified
	External Connector Type: None
	Port Type: Other

Handle 0x001C, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J6F1 - LVDS
	Internal Connector Type: Other
	External Reference Designator: Not Specified
	External Connector Type: None
	Port Type: Other

Handle 0x001D, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J2F1 - LAI FAN
	Internal Connector Type: Other
	External Reference Designator: Not Specified
	External Connector Type: None
	Port Type: Other

Handle 0x001E, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J2G1 - GFX VID
	Internal Connector Type: Other
	External Reference Designator: Not Specified
	External Connector Type: None
	Port Type: Other

Handle 0x001F, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1G6 - AC JACK
	Internal Connector Type: Other
	External Reference Designator: Not Specified
	External Connector Type: None
	Port Type: Other

Handle 0x0020, DMI type 9, 17 bytes
System Slot Information
	Designation: J6B2
	Type: x16 PCI Express
	Current Usage: In Use
	Length: Long
	ID: 0
	Characteristics:
		3.3 V is provided
		Opening is shared
		PME signal is supported
	Bus Address: 0000:00:02.0

Handle 0x0021, DMI type 9, 17 bytes
System Slot Information
	Designation: J6B1
	Type: x1 PCI Express
	Current Usage: In Use
	Length: Short
	ID: 1
	Characteristics:
		3.3 V is provided
		Opening is shared
		PME signal is supported
	Bus Address: 0000:00:1c.0

Handle 0x0022, DMI type 9, 17 bytes
System Slot Information
	Designation: J6D1
	Type: x8 PCI Express
	Current Usage: In Use
	Length: Short
	ID: 2
	Characteristics:
		3.3 V is provided
		Opening is shared
		PME signal is supported
	Bus Address: 0000:00:01.0

Handle 0x0023, DMI type 9, 17 bytes
System Slot Information
	Designation: J7B1
	Type: x16 PCI Express
	Current Usage: In Use
	Length: Short
	ID: 3
	Characteristics:
		3.3 V is provided
		Opening is shared
		PME signal is supported
	Bus Address: 0000:00:03.0

Handle 0x0024, DMI type 9, 17 bytes
System Slot Information
	Designation: J8B4
	Type: x1 PCI Express
	Current Usage: In Use
	Length: Short
	ID: 4
	Characteristics:
		3.3 V is provided
		Opening is shared
		PME signal is supported
	Bus Address: 0000:00:1c.7

Handle 0x0025, DMI type 9, 17 bytes
System Slot Information
	Designation: J8B3
	Type: 32-bit PCI
	Current Usage: In Use
	Length: Short
	ID: 6
	Characteristics:
		3.3 V is provided
		Opening is shared
		PME signal is supported
	Bus Address: 0000:14:1e.0

Handle 0x0026, DMI type 10, 6 bytes
On Board Device Information
	Type: Video
	Status: Enabled
	Description:    To Be Filled By O.E.M.

Handle 0x0027, DMI type 11, 5 bytes
OEM Strings
	String 1: To Be Filled By O.E.M.

Handle 0x0028, DMI type 12, 5 bytes
System Configuration Options
	Option 1: To Be Filled By O.E.M.

Handle 0x0029, DMI type 32, 20 bytes
System Boot Information
	Status: No errors detected

Handle 0x002A, DMI type 34, 11 bytes
Management Device
	Description: LM78-1
	Type: LM78
	Address: 0x00000000
	Address Type: I/O Port

Handle 0x002B, DMI type 26, 22 bytes
Voltage Probe
	Description: LM78A
	Location: <OUT OF SPEC>
	Status: <OUT OF SPEC>
	Maximum Value: Unknown
	Minimum Value: Unknown
	Resolution: Unknown
	Tolerance: Unknown
	Accuracy: Unknown
	OEM-specific Information: 0x00000000
	Nominal Value: Unknown

Handle 0x002C, DMI type 36, 16 bytes
Management Device Threshold Data
	Lower Non-critical Threshold: 1
	Upper Non-critical Threshold: 2
	Lower Critical Threshold: 3
	Upper Critical Threshold: 4
	Lower Non-recoverable Threshold: 5
	Upper Non-recoverable Threshold: 6

Handle 0x002D, DMI type 35, 11 bytes
Management Device Component
	Description: To Be Filled By O.E.M.
	Management Device Handle: 0x002A
	Component Handle: 0x002A
	Threshold Handle: 0x002B

Handle 0x002E, DMI type 28, 22 bytes
Temperature Probe
	Description: LM78A
	Location: <OUT OF SPEC>
	Status: <OUT OF SPEC>
	Maximum Value: Unknown
	Minimum Value: Unknown
	Resolution: Unknown
	Tolerance: Unknown
	Accuracy: Unknown
	OEM-specific Information: 0x00000000
	Nominal Value: Unknown

Handle 0x002F, DMI type 36, 16 bytes
Management Device Threshold Data
	Lower Non-critical Threshold: 1
	Upper Non-critical Threshold: 2
	Lower Critical Threshold: 3
	Upper Critical Threshold: 4
	Lower Non-recoverable Threshold: 5
	Upper Non-recoverable Threshold: 6

Handle 0x0030, DMI type 35, 11 bytes
Management Device Component
	Description: To Be Filled By O.E.M.
	Management Device Handle: 0x002A
	Component Handle: 0x002D
	Threshold Handle: 0x002E

Handle 0x0031, DMI type 27, 15 bytes
Cooling Device
	Temperature Probe Handle: 0x002E
	Type: <OUT OF SPEC>
	Status: <OUT OF SPEC>
	Cooling Unit Group: 1
	OEM-specific Information: 0x00000000
	Nominal Speed: Unknown Or Non-rotating
	Description: Cooling Dev 1

Handle 0x0032, DMI type 36, 16 bytes
Management Device Threshold Data
	Lower Non-critical Threshold: 1
	Upper Non-critical Threshold: 2
	Lower Critical Threshold: 3
	Upper Critical Threshold: 4
	Lower Non-recoverable Threshold: 5
	Upper Non-recoverable Threshold: 6

Handle 0x0033, DMI type 35, 11 bytes
Management Device Component
	Description: To Be Filled By O.E.M.
	Management Device Handle: 0x002A
	Component Handle: 0x0030
	Threshold Handle: 0x0031

Handle 0x0034, DMI type 27, 15 bytes
Cooling Device
	Temperature Probe Handle: 0x002E
	Type: <OUT OF SPEC>
	Status: <OUT OF SPEC>
	Cooling Unit Group: 1
	OEM-specific Information: 0x00000000
	Nominal Speed: Unknown Or Non-rotating
	Description: Not Specified

Handle 0x0035, DMI type 36, 16 bytes
Management Device Threshold Data
	Lower Non-critical Threshold: 1
	Upper Non-critical Threshold: 2
	Lower Critical Threshold: 3
	Upper Critical Threshold: 4
	Lower Non-recoverable Threshold: 5
	Upper Non-recoverable Threshold: 6

Handle 0x0036, DMI type 35, 11 bytes
Management Device Component
	Description: To Be Filled By O.E.M.
	Management Device Handle: 0x002A
	Component Handle: 0x0033
	Threshold Handle: 0x0034

Handle 0x0037, DMI type 29, 22 bytes
Electrical Current Probe
	Description: ABC
	Location: <OUT OF SPEC>
	Status: <OUT OF SPEC>
	Maximum Value: Unknown
	Minimum Value: Unknown
	Resolution: Unknown
	Tolerance: Unknown
	Accuracy: Unknown
	OEM-specific Information: 0x00000000
	Nominal Value: Unknown

Handle 0x0038, DMI type 36, 16 bytes
Management Device Threshold Data

Handle 0x0039, DMI type 35, 11 bytes
Management Device Component
	Description: To Be Filled By O.E.M.
	Management Device Handle: 0x002A
	Component Handle: 0x0036
	Threshold Handle: 0x0034

Handle 0x003A, DMI type 26, 22 bytes
Voltage Probe
	Description: LM78A
	Location: Power Unit
	Status: OK
	Maximum Value: Unknown
	Minimum Value: Unknown
	Resolution: Unknown
	Tolerance: Unknown
	Accuracy: Unknown
	OEM-specific Information: 0x00000000
	Nominal Value: Unknown

Handle 0x003B, DMI type 28, 22 bytes
Temperature Probe
	Description: LM78A
	Location: Power Unit
	Status: OK
	Maximum Value: Unknown
	Minimum Value: Unknown
	Resolution: Unknown
	Tolerance: Unknown
	Accuracy: Unknown
	OEM-specific Information: 0x00000000
	Nominal Value: Unknown

Handle 0x003C, DMI type 27, 15 bytes
Cooling Device
	Temperature Probe Handle: 0x003B
	Type: Power Supply Fan
	Status: OK
	Cooling Unit Group: 1
	OEM-specific Information: 0x00000000
	Nominal Speed: Unknown Or Non-rotating
	Description: Cooling Dev 1

Handle 0x003D, DMI type 29, 22 bytes
Electrical Current Probe
	Description: ABC
	Location: Power Unit
	Status: OK
	Maximum Value: Unknown
	Minimum Value: Unknown
	Resolution: Unknown
	Tolerance: Unknown
	Accuracy: Unknown
	OEM-specific Information: 0x00000000
	Nominal Value: Unknown

Handle 0x003E, DMI type 39, 22 bytes
System Power Supply
	Power Unit Group: 1
	Location: To Be Filled By O.E.M.
	Name: To Be Filled By O.E.M.
	Manufacturer: To Be Filled By O.E.M.
	Serial Number: To Be Filled By O.E.M.
	Asset Tag: To Be Filled By O.E.M.
	Model Part Number: To Be Filled By O.E.M.
	Revision: To Be Filled By O.E.M.
	Max Power Capacity: Unknown
	Status: Present, OK
	Type: Switching
	Input Voltage Range Switching: Auto-switch
	Plugged: Yes
	Hot Replaceable: No
	Input Voltage Probe Handle: 0x003A
	Cooling Device Handle: 0x003C
	Input Current Probe Handle: 0x003D

Handle 0x003F, DMI type 41, 11 bytes
Onboard Device
	Reference Designation:  Onboard LAN
	Type: Ethernet
	Status: Enabled
	Type Instance: 1
	Bus Address: 0000:00:19.0

Handle 0x0040, DMI type 17, 34 bytes
Memory Device
	Array Handle: 0x0007
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 4 GB
	Form Factor: DIMM
	Set: None
	Locator: ChannelA-DIMM0
	Bank Locator: BANK 0
	Type: DDR3
	Type Detail: Synchronous
	Speed: 1333 MT/s
	Manufacturer: 029E
	Serial Number: 00000000
	Asset Tag: 9876543210
	Part Number: CML8GX3M2A1600C9  
	Rank: 1
	Configured Memory Speed: 1333 MT/s

Handle 0x0041, DMI type 20, 35 bytes
Memory Device Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x000FFFFFFFF
	Range Size: 4 GB
	Physical Device Handle: 0x0040
	Memory Array Mapped Address Handle: 0x0047
	Partition Row Position: Unknown
	Interleave Position: 1
	Interleaved Data Depth: 2

Handle 0x0042, DMI type 17, 34 bytes
Memory Device
	Array Handle: 0x0007
	Error Information Handle: Not Provided
	Total Width: Unknown
	Data Width: Unknown
	Size: No Module Installed
	Form Factor: DIMM
	Set: None
	Locator: ChannelA-DIMM1
	Bank Locator: BANK 1
	Type: Unknown
	Type Detail: None

Handle 0x0043, DMI type 4, 42 bytes
Processor Information
	Socket Designation: Intel(R) Core(TM) i3-3240 CPU @ 3.40GHz
	Type: Central Processor
	Family: Core i7
	Manufacturer: Intel
	ID: A9 06 03 00 FF FB EB BF
	Signature: Type 0, Family 6, Model 58, Stepping 9
	Flags:
		FPU (Floating-point unit on-chip)
		VME (Virtual mode extension)
		DE (Debugging extension)
		PSE (Page size extension)
		TSC (Time stamp counter)
		MSR (Model specific registers)
		PAE (Physical address extension)
		MCE (Machine check exception)
		CX8 (CMPXCHG8 instruction supported)
		APIC (On-chip APIC hardware supported)
		SEP (Fast system call)
		MTRR (Memory type range registers)
		PGE (Page global enable)
		MCA (Machine check architecture)
		CMOV (Conditional move instruction supported)
		PAT (Page attribute table)
		PSE-36 (36-bit page size extension)
		CLFSH (CLFLUSH instruction supported)
		DS (Debug store)
		ACPI (ACPI supported)
		MMX (MMX technology supported)
		FXSR (FXSAVE and FXSTOR instructions supported)
		SSE (Streaming SIMD extensions)
		SSE2 (Streaming SIMD extensions 2)
		SS (Self-snoop)
		HTT (Multi-threading)
		TM (Thermal monitor supported)
		PBE (Pending break enabled)
	Version: Intel(R) Core(TM) i3-3240 CPU @ 3.40GHz
	Voltage: 1.0 V
	External Clock: 100 MHz
	Max Speed: 7000 MHz
	Current Speed: 3400 MHz
	Status: Populated, Enabled
	Upgrade: Other
	L1 Cache Handle: 0x0004
	L2 Cache Handle: 0x0005
	L3 Cache Handle: 0x0006
	Serial Number: Not Specified
	Asset Tag: Fill By OEM
	Part Number: Fill By OEM
	Core Count: 2
	Core Enabled: 1
	Thread Count: 2
	Characteristics:
		64-bit capable

Handle 0x0044, DMI type 17, 34 bytes
Memory Device
	Array Handle: 0x0007
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 2 GB
	Form Factor: DIMM
	Set: None
	Locator: ChannelB-DIMM0
	Bank Locator: BANK 2
	Type: DDR3
	Type Detail: Synchronous
	Speed: 1333 MT/s
	Manufacturer: 04EF
	Serial Number: 00000000
	Asset Tag: 9876543210
	Part Number: Team-Elite-1333   
	Rank: 2
	Configured Memory Speed: 1333 MT/s

Handle 0x0045, DMI type 20, 35 bytes
Memory Device Mapped Address
	Starting Address: 0x00100000000
	Ending Address: 0x0017FFFFFFF
	Range Size: 2 GB
	Physical Device Handle: 0x0044
	Memory Array Mapped Address Handle: 0x0047
	Partition Row Position: Unknown
	Interleave Position: 2
	Interleaved Data Depth: 2

Handle 0x0046, DMI type 17, 34 bytes
Memory Device
	Array Handle: 0x0007
	Error Information Handle: Not Provided
	Total Width: Unknown
	Data Width: Unknown
	Size: No Module Installed
	Form Factor: DIMM
	Set: None
	Locator: ChannelB-DIMM1
	Bank Locator: BANK 3
	Type: Unknown
	Type Detail: None

Handle 0x0047, DMI type 19, 31 bytes
Memory Array Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x0017FFFFFFF
	Range Size: 6 GB
	Physical Array Handle: 0x0007
	Partition Width: 4

Handle 0x004C, DMI type 131, 64 bytes
OEM-specific Type
	Header and Data:
		83 40 4C 00 31 00 00 00 00 00 00 00 00 00 00 00
		F8 00 5C 1C FF FF FF FF 01 00 00 00 00 00 08 00
		47 05 00 00 00 00 00 00 C8 00 FF FF 00 00 00 00
		00 00 00 00 36 00 00 00 76 50 72 6F 00 00 00 00

Handle 0x004D, DMI type 13, 22 bytes
BIOS Language Information
	Language Description Format: Long
	Installable Languages: 6
		en|US|iso8859-1
		de|DE|iso8859-1
		ru|RU|iso8859-5
		ja|JP|unicode
		zh|CS|unicode
		zh|CT|unicode
	Currently Installed Language: en|US|iso8859-1

Handle 0x004F, DMI type 127, 4 bytes
End Of Table


[-- Attachment #1.1.3: pacman.txt --]
[-- Type: text/plain, Size: 4046 bytes --]

abseil-cpp 20230802.1-1
acl 2.3.2-1
archlinux-keyring 20240208-1
argon2 20190702-5
attr 2.5.2-1
audit 4.0-1
bash 5.2.026-2
binutils 2.42-2
boost 1.83.0-5
boost-libs 1.83.0-5
bridge-utils 1.7.1-2
brotli 1.1.0-1
btrfs-progs 6.7.1-1
bzip2 1.0.8-5
ca-certificates 20220905-1
ca-certificates-mozilla 3.98-1
ca-certificates-utils 20220905-1
containerd 1.7.13-1
coreutils 9.4-3
cracklib 2.9.11-1
cryptsetup 2.7.1-1
curl 8.6.0-3
db 6.2.32-1
db5.3 5.3.28-4
dbus 1.14.10-2
dbus-broker 35-2
dbus-broker-units 35-2
device-mapper 2.03.23-3
dhcpcd 10.0.6-1
diffutils 3.10-1
dmidecode 3.5-1
dnssec-anchors 20190629-3
docker 1:25.0.3-1
dool 1.3.1-1
downgrade 11.2.1-1
e2fsprogs 1.47.0-1
encfs 1.9.5-7
expat 2.6.1-1
faddnsc-git r200.b9fd931-9
fakeroot 1.34-1
file 5.45-1
filesystem 2024.01.19-1
findutils 4.9.0-3
fish 3.7.0-1
fuse-common 3.16.2-1
fuse2 2.9.9-4
fuse3 3.16.2-1
fzf 0.46.1-1
gawk 5.3.0-1
gcc-libs 13.2.1-5
gdbm 1.23-2
gettext 0.22.4-1
git 2.44.0-1
glib2 2.78.4-1
glibc 2.39-1
gmp 6.3.0-1
gnupg 2.4.4-1
gnutls 3.8.3-1
gpgme 1.23.2-1
gpm 1.20.7.r38.ge82d1a6-5
grep 3.11-1
groff 1.23.0-5
gzip 1.13-2
haveged 1.9.18-1
htop 3.3.0-1
hwdata 0.380-1
hwloc 2.10.0-1
iana-etc 20231228-1
icu 74.2-1
inetutils 2.5-1
intel-ucode 20231114-2
iotop 0.6-10
iproute2 6.7.0-1
iptables 1:1.8.10-1
iputils 20240117-1
jansson 2.14-2
jfsutils 1.1.15-8
jq 1.7.1-1
json-c 0.17-1
kbd 2.6.4-1
keyutils 1.6.3-2
kmod 32-1
krb5 1.21.2-2
ldns 1.8.3-2
less 1:643-1
libaio 0.3.113-3
libarchive 3.7.2-1
libassuan 2.5.6-1
libbpf 1.3.0-1
libcap 2.69-3
libcap-ng 0.8.4-1
libcroco 0.6.13-2
libedit 20230828_3.1-1
libelf 0.191-1
libevent 2.1.12-4
libffi 3.4.6-1
libgcrypt 1.10.3-1
libgpg-error 1.48-1
libidn2 2.3.7-1
libinih 57-1
libksba 1.6.6-1
libldap 2.6.6-2
libmicrohttpd 1.0.1-1
libmnl 1.0.5-1
libnetfilter_conntrack 1.0.9-1
libnfnetlink 1.0.2-1
libnftnl 1.2.6-1
libnghttp2 1.60.0-1
libnghttp3 1.2.0-1
libnl 3.9.0-1
libnsl 2.0.1-1
libp11-kit 0.25.3-1
libpcap 1.10.4-1
libpciaccess 0.18-1
libpipeline 1.5.7-1
libpsl 0.21.2-1
libsasl 2.1.28-4
libseccomp 2.5.5-2
libsecret 0.21.4-1
libssh2 1.11.0-1
libsysprof-capture 45.2-1
libtasn1 4.19.0-1
libtirpc 1.3.4-1
libtool 2.4.7+4+g1ec8fa28-7
libunistring 1.1-2
liburcu 0.14.0-1
liburing 2.5-1
libusb 1.0.27-1
libutempter 1.2.1-4
libuv 1.48.0-1
libverto 0.3.2-4
libxcrypt 4.4.36-1
libxml2 2.12.5-1
licenses 20240206-1
linux 6.6.10.arch1-1
linux-api-headers 6.7-1
linux-firmware 20240220.97b693d2-1
linux-firmware-whence 20240220.97b693d2-1
linux-git 6.6.17.r316.8117961d98fb.stable.linux-1
linux-lts 6.6.21-1
linux-mainline 6.8-3
logrotate 3.21.0-2
lvm2 2.03.23-3
lz4 1:1.9.4-2
lzo 2.10-5
man-db 2.12.0-1
man-pages 6.06-2
mariadb-libs 11.3.2-1
mdadm 4.3-2
mfs_utils 3.0.117-4
mkinitcpio 38-4
mkinitcpio-busybox 1.36.1-1
moosefs 3.0.117-1
mosh 1.4.0-6
mpfr 4.2.1-2
nano 7.2-1
ncdu 2.3-1
ncurses 6.4_20230520-1
netctl 1.29-1
nettle 3.9.1-1
nheqminer-cpu-git 0.5c.r1.gb9900ff-2
npth 1.7-1
oniguruma 6.9.9-1
openresolv 3.13.2-2
openssh 9.6p1-3
openssl 3.2.1-1
p11-kit 0.25.3-1
pacman 6.0.2-9
pacman-contrib 1.10.4-3
pacman-mirrorlist 20231001-1
pam 1.6.0-4
pambase 20230918-1
parted 3.6-1
pciutils 3.11.1-1
pcre 8.45-4
pcre2 10.42-2
perl 5.38.2-1
perl-error 0.17029-5
perl-io-tty 1.20-1
perl-mailtools 2.21-7
perl-timedate 2.33-5
pinentry 1.2.1-3
popt 1.19-1
postfix 3.8.6-1
postfix-pcre 3.8.6-1
postgresql-libs 16.1-6
procps-ng 4.0.4-2
protobuf 25.3-1
psmisc 23.7-1
python 3.11.8-1
python-docopt 0.6.2-12
python-six 1.16.0-8
readline 8.2.010-1
reiserfsprogs 3.6.27-4
runc 1.1.12-1
s-nail 14.9.24-2
sed 4.9-3
shadow 4.14.6-1
smartmontools 7.4-1
sqlite 3.45.1-1
sudo 1.9.15.p5-1
sysfsutils 2.1.1-1
systemd 255.4-2
systemd-check-failed 0.7-1
systemd-libs 255.4-2
systemd-sysvcompat 255.4-2
tar 1.35-2
texinfo 7.1-2
thin-provisioning-tools 1.0.12-1
tinycdb 0.81-1
tinyxml2 10.0.0-1
tmux 3.4-4
tpm2-tss 4.0.1-1
tzdata 2024a-1
uptimed 0.4.6-3
usbutils 017-1
util-linux 2.39.3-2
util-linux-libs 2.39.3-2
vi 1:070224-6
vim 9.1.0151-2
vim-runtime 9.1.0151-2
which 2.21-6
xfsprogs 6.6.0-1
xmrig-donateless 6.21.1-1
xz 5.6.0-1
zlib 1:1.3.1-1
zstd 1.5.5-1

[-- Attachment #1.1.4: revert.patch --]
[-- Type: text/x-patch, Size: 2514 bytes --]

diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c
index 7bcc5170043f..4a11470bed5e 100644
--- a/drivers/firmware/efi/libstub/x86-stub.c
+++ b/drivers/firmware/efi/libstub/x86-stub.c
@@ -458,8 +458,9 @@ void __noreturn efi_stub_entry(efi_handle_t handle,
 efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 				   efi_system_table_t *sys_table_arg)
 {
-	static struct boot_params boot_params __page_aligned_bss;
-	struct setup_header *hdr = &boot_params.hdr;
+	struct boot_params *boot_params;
+	struct setup_header *hdr;
+	void *image_base;
 	efi_guid_t proto = LOADED_IMAGE_PROTOCOL_GUID;
 	int options_size = 0;
 	efi_status_t status;
@@ -477,9 +478,30 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 		efi_exit(handle, status);
 	}
 
-	/* Assign the setup_header fields that the kernel actually cares about */
+	image_base = efi_table_attr(image, image_base);
+
+	status = efi_allocate_pages(sizeof(struct boot_params),
+				    (unsigned long *)&boot_params, ULONG_MAX);
+	if (status != EFI_SUCCESS) {
+		efi_err("Failed to allocate lowmem for boot params\n");
+		efi_exit(handle, status);
+	}
+
+	memset(boot_params, 0x0, sizeof(struct boot_params));
+
+	hdr = &boot_params->hdr;
+
+	/* Copy the setup header from the second sector to boot_params */
+	memcpy(&hdr->jump, image_base + 512,
+	       sizeof(struct setup_header) - offsetof(struct setup_header, jump));
+
+	/*
+	 * Fill out some of the header fields ourselves because the
+	 * EFI firmware loader doesn't load the first sector.
+	 */
 	hdr->root_flags	= 1;
 	hdr->vid_mode	= 0xffff;
+	hdr->boot_flag	= 0xAA55;
 
 	hdr->type_of_loader = 0x21;
 
@@ -488,13 +510,25 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 	if (!cmdline_ptr)
 		goto fail;
 
-	efi_set_u64_split((unsigned long)cmdline_ptr, &hdr->cmd_line_ptr,
-			  &boot_params.ext_cmd_line_ptr);
+	efi_set_u64_split((unsigned long)cmdline_ptr,
+			  &hdr->cmd_line_ptr, &boot_params->ext_cmd_line_ptr);
+
+	hdr->ramdisk_image = 0;
+	hdr->ramdisk_size = 0;
+
+	/*
+	 * Disregard any setup data that was provided by the bootloader:
+	 * setup_data could be pointing anywhere, and we have no way of
+	 * authenticating or validating the payload.
+	 */
+	hdr->setup_data = 0;
 
-	efi_stub_entry(handle, sys_table_arg, &boot_params);
+	efi_stub_entry(handle, sys_table_arg, boot_params);
 	/* not reached */
 
 fail:
+	efi_free(sizeof(struct boot_params), (unsigned long)boot_params);
+
 	efi_exit(handle, status);
 }
 

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [REGRESSION] linux 6.6.18 and later fails to boot with "initramfs unpacking failed: invalid magic at start of compressed archive"

[Ard Biesheuvel]

On Fri, 15 Mar 2024 at 15:12, Radek Podgorny <radek@podgorny.cz> wrote:
>
> hi ard, thanks for the effort!
>
> so, your first recommended patch (the memset thing), applied to current
> mainline (6.8) DOES NOT resolve the issue.
>
> the second recommendation, a revert patch, applied to the same mainline
> tree, indeed DOES resolve the problem.
>
> just to be sure, i'm attaching the revert patch.
>

Thanks.

If the revert works for you, I think we can stop looking.

This points to an issue in the firmware's image loader, which does not
clear all the memory it should be clearing.

I will queue up the revert with your tested-by.

Thanks,
Ard.

Re: [REGRESSION] linux 6.6.18 and later fails to boot with "initramfs unpacking failed: invalid magic at start of compressed archive"

[Radek Podgorny]

[-- Attachment #1.1: Type: text/plain, Size: 941 bytes --]

ok, no problem, thanks!

i was just wondering what was the purpose of the original change - i 
don't want others to miss some improvement just because of my weird 
machine. ;-)

r.


On 3/15/24 15:25, Ard Biesheuvel wrote:
> On Fri, 15 Mar 2024 at 15:12, Radek Podgorny <radek@podgorny.cz> wrote:
>>
>> hi ard, thanks for the effort!
>>
>> so, your first recommended patch (the memset thing), applied to current
>> mainline (6.8) DOES NOT resolve the issue.
>>
>> the second recommendation, a revert patch, applied to the same mainline
>> tree, indeed DOES resolve the problem.
>>
>> just to be sure, i'm attaching the revert patch.
>>
> 
> Thanks.
> 
> If the revert works for you, I think we can stop looking.
> 
> This points to an issue in the firmware's image loader, which does not
> clear all the memory it should be clearing.
> 
> I will queue up the revert with your tested-by.
> 
> Thanks,
> Ard.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [REGRESSION] linux 6.6.18 and later fails to boot with "initramfs unpacking failed: invalid magic at start of compressed archive"

[Ard Biesheuvel]

On Fri, 15 Mar 2024 at 15:12, Radek Podgorny <radek@podgorny.cz> wrote:
>
> hi ard, thanks for the effort!
>
> so, your first recommended patch (the memset thing), applied to current
> mainline (6.8) DOES NOT resolve the issue.
>
> the second recommendation, a revert patch, applied to the same mainline
> tree, indeed DOES resolve the problem.
>
> just to be sure, i'm attaching the revert patch.
>

Actually, that is not the patch I had in mind.

Please revert

x86/efi: Drop EFI stub .bss from .data section

commit fa244085025f4a8fb38ec67af635aed04297758d in v6.6

(or apply the changes below by hand if that is easier for you)

--- a/arch/x86/boot/compressed/vmlinux.lds.S
+++ b/arch/x86/boot/compressed/vmlinux.lds.S
@@ -47,6 +47,7 @@ SECTIONS
                _data = . ;
                *(.data)
                *(.data.*)
+               *(.bss.efistub)

                /* Add 4 bytes of extra space for a CRC-32 checksum */
                . = ALIGN(. + 4, 0x200);

--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -108,6 +108,13 @@
 # https://bugs.llvm.org/show_bug.cgi?id=46480
 STUBCOPY_FLAGS-y               += --remove-section=.note.gnu.property

+STUBCOPY_FLAGS-$(CONFIG_X86)   += --rename-section .bss=.bss.efistub,load,alloc
 STUBCOPY_RELOC-$(CONFIG_X86_32)        := R_386_32
 STUBCOPY_RELOC-$(CONFIG_X86_64)        := R_X86_64_64

Re: [REGRESSION] linux 6.6.18 and later fails to boot with "initramfs unpacking failed: invalid magic at start of compressed archive"

[Ard Biesheuvel]

On Fri, 15 Mar 2024 at 16:33, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Fri, 15 Mar 2024 at 15:12, Radek Podgorny <radek@podgorny.cz> wrote:
> >
> > hi ard, thanks for the effort!
> >
> > so, your first recommended patch (the memset thing), applied to current
> > mainline (6.8) DOES NOT resolve the issue.
> >
> > the second recommendation, a revert patch, applied to the same mainline
> > tree, indeed DOES resolve the problem.
> >
> > just to be sure, i'm attaching the revert patch.
> >
>
> Actually, that is not the patch I had in mind.
>
> Please revert
>
> x86/efi: Drop EFI stub .bss from .data section
>

BTW which bootloader are you using?

Re: [REGRESSION] linux 6.6.18 and later fails to boot with "initramfs unpacking failed: invalid magic at start of compressed archive"

[Radek Podgorny]

[-- Attachment #1.1.1: Type: text/plain, Size: 1431 bytes --]

it's systemd-boot. attaching bootctl output. now looking at it, it seems 
that while systemd (and systemd-boot) gets timely updates on my system 
(currently at 255.4), the stub (is this how it's called?) does not get 
updated automatically in the efi partition (still at version 244?).

i can try to update it. but i'll wait for your instructions since this 
may be some rare situation and we may use it for testing.

anyway, i'm compiling new kernel with your suggested changes right now 
so i'll let you know how it turned out, soon.

r.

p.s.: ha! nevermind, i just checked the other systems which boot fine 
and they also are on stub (?) 244 so it's probably not the cause.


On 3/15/24 17:08, Ard Biesheuvel wrote:
> On Fri, 15 Mar 2024 at 16:33, Ard Biesheuvel <ardb@kernel.org> wrote:
>>
>> On Fri, 15 Mar 2024 at 15:12, Radek Podgorny <radek@podgorny.cz> wrote:
>>>
>>> hi ard, thanks for the effort!
>>>
>>> so, your first recommended patch (the memset thing), applied to current
>>> mainline (6.8) DOES NOT resolve the issue.
>>>
>>> the second recommendation, a revert patch, applied to the same mainline
>>> tree, indeed DOES resolve the problem.
>>>
>>> just to be sure, i'm attaching the revert patch.
>>>
>>
>> Actually, that is not the patch I had in mind.
>>
>> Please revert
>>
>> x86/efi: Drop EFI stub .bss from .data section
>>
> 
> BTW which bootloader are you using?

[-- Attachment #1.1.2: bootctl.txt --]
[-- Type: text/plain, Size: 3663 bytes --]

^[[0mSystem:
      Firmware: UEFI 2.31 (American Megatrends 4.651)
 Firmware Arch: x64
   Secure Boot: disabled (unsupported)
  TPM2 Support: no
  Measured UKI: no
  Boot into FW: not supported

^[[0mCurrent Boot Loader:
      Product: systemd-boot 244-1-arch
     Features: ✓ Boot counting
               ✓ Menu timeout control
               ✓ One-shot menu timeout control
               ✓ Default entry control
               ✓ One-shot entry control
               ✓ Support for XBOOTLDR partition
               ✓ Support for passing random seed to OS
               ✗ Load drop-in drivers
               ✗ Support Type #1 sort-key field
               ✗ Support @saved pseudo-entry
               ✗ Support Type #1 devicetree field
               ✗ Enroll SecureBoot keys
               ✗ Retain SHIM protocols
               ✗ Menu can be disabled
               ✓ Boot loader sets ESP information
          ESP: /dev/disk/by-partuuid/2adefc75-3da0-4c3d-9449-ea0114a4b281
         File: └─/EFI/systemd/systemd-bootx64.efi

^[[0mRandom Seed:
 System Token: set
       Exists: yes

^[[0mAvailable Boot Loaders on ESP:
          ESP: /boot (/dev/disk/by-partuuid/2adefc75-3da0-4c3d-9449-ea0114a4b281)
         File: ├─/EFI/systemd/systemd-bootx64.efi (systemd-boot 244-1-arch)
               └─/EFI/BOOT/BOOTX64.EFI (systemd-boot 244-1-arch)

^[[0mBoot Loaders Listed in EFI Variables:
        Title: Linux Boot Manager
           ID: 0x0009
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/2adefc75-3da0-4c3d-9449-ea0114a4b281
         File: └─/EFI/systemd/systemd-bootx64.efi

        Title: Linux Boot Manager
           ID: 0x0008
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/dacde831-60af-4f8c-bbb2-c4b03a3265e4
         File: └─/EFI/systemd/systemd-bootx64.efi

        Title: Linux Boot Manager
           ID: 0x0001
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/f9169784-d163-4c58-a95d-26deb4145714
         File: └─/EFI/systemd/systemd-bootx64.efi

        Title: Linux Boot Manager
           ID: 0x0004
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/ed77cf92-2acd-4e2b-be07-b6f1e4cded29
         File: └─/EFI/systemd/systemd-bootx64.efi

        Title: Linux Boot Manager
           ID: 0x0000
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/ca18d734-d8b3-48f8-b68e-3e4ae919e0c6
         File: └─/EFI/systemd/systemd-bootx64.efi

        Title: Linux Boot Manager
           ID: 0x0002
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/896b1d31-733e-417a-a740-a787acff3f15
         File: └─/EFI/systemd/systemd-bootx64.efi

        Title: Linux Boot Manager
           ID: 0x0003
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/e7bf6fc5-0bf6-4dc2-8116-c2dbc8999a54
         File: └─/EFI/systemd/systemd-bootx64.efi

        Title: Linux Boot Manager
           ID: 0x0006
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/6d9fa765-a4c9-4723-becf-61105a9d1f30
         File: └─/EFI/systemd/systemd-bootx64.efi

^[[0mBoot Loader Entries:
        $BOOT: /boot (/dev/disk/by-partuuid/2adefc75-3da0-4c3d-9449-ea0114a4b281)
        token: arch

^[[0mDefault Boot Loader Entry:
         type: Boot Loader Specification Type #1 (.conf)
        title: Arch Linux
           id: arch.conf
       source: /boot//loader/entries/arch.conf
        linux: /boot//vmlinuz-linux
       initrd: /boot//intel-ucode.img
               /boot//initramfs-linux.img
      options: root=/dev/disk/by-label/MATLA_ROOT rw

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [REGRESSION] linux 6.6.18 and later fails to boot with "initramfs unpacking failed: invalid magic at start of compressed archive"

[Ard Biesheuvel]

On Fri, 15 Mar 2024 at 17:24, Radek Podgorny <radek@podgorny.cz> wrote:
>
> it's systemd-boot. attaching bootctl output. now looking at it, it seems
> that while systemd (and systemd-boot) gets timely updates on my system
> (currently at 255.4), the stub (is this how it's called?) does not get
> updated automatically in the efi partition (still at version 244?).
>
> i can try to update it. but i'll wait for your instructions since this
> may be some rare situation and we may use it for testing.
>
> anyway, i'm compiling new kernel with your suggested changes right now
> so i'll let you know how it turned out, soon.
>
> r.
>
> p.s.: ha! nevermind, i just checked the other systems which boot fine
> and they also are on stub (?) 244 so it's probably not the cause.
>

OK that makes sense.

I installed Arch linux in a VM (what a pain!) but I don't think the
distro has anything to do with it.

I did realize that reverting that patch is not going to be a full
solution in any case.

Could you please try whether the following fix works for you?

--- a/drivers/firmware/efi/libstub/x86-stub.c
+++ b/drivers/firmware/efi/libstub/x86-stub.c
@@ -473,6 +473,9 @@
        int options_size = 0;
        efi_status_t status;
        char *cmdline_ptr;
+       extern char _bss[], _ebss[];
+
+       memset(_bss, 0, _ebss - _bss);

        efi_system_table = sys_table_arg;

Re: [REGRESSION] linux 6.6.18 and later fails to boot with "initramfs unpacking failed: invalid magic at start of compressed archive"

[Radek Podgorny]

[-- Attachment #1.1: Type: text/plain, Size: 1743 bytes --]

ok, will. the kernel with previous patch is still compiling so i'll 
queue it. ;-)

anyway, should i apply this as a separate patch or as an addition to the 
previous one (the one with bss.efistub addition)?

r.


On 3/15/24 18:48, Ard Biesheuvel wrote:
> On Fri, 15 Mar 2024 at 17:24, Radek Podgorny <radek@podgorny.cz> wrote:
>>
>> it's systemd-boot. attaching bootctl output. now looking at it, it seems
>> that while systemd (and systemd-boot) gets timely updates on my system
>> (currently at 255.4), the stub (is this how it's called?) does not get
>> updated automatically in the efi partition (still at version 244?).
>>
>> i can try to update it. but i'll wait for your instructions since this
>> may be some rare situation and we may use it for testing.
>>
>> anyway, i'm compiling new kernel with your suggested changes right now
>> so i'll let you know how it turned out, soon.
>>
>> r.
>>
>> p.s.: ha! nevermind, i just checked the other systems which boot fine
>> and they also are on stub (?) 244 so it's probably not the cause.
>>
> 
> OK that makes sense.
> 
> I installed Arch linux in a VM (what a pain!) but I don't think the
> distro has anything to do with it.
> 
> I did realize that reverting that patch is not going to be a full
> solution in any case.
> 
> Could you please try whether the following fix works for you?
> 
> --- a/drivers/firmware/efi/libstub/x86-stub.c
> +++ b/drivers/firmware/efi/libstub/x86-stub.c
> @@ -473,6 +473,9 @@
>          int options_size = 0;
>          efi_status_t status;
>          char *cmdline_ptr;
> +       extern char _bss[], _ebss[];
> +
> +       memset(_bss, 0, _ebss - _bss);
> 
>          efi_system_table = sys_table_arg;

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [REGRESSION] linux 6.6.18 and later fails to boot with "initramfs unpacking failed: invalid magic at start of compressed archive"

[Ard Biesheuvel]

On Fri, 15 Mar 2024 at 19:11, Radek Podgorny <radek@podgorny.cz> wrote:
>
> ok, will. the kernel with previous patch is still compiling so i'll
> queue it. ;-)
>
> anyway, should i apply this as a separate patch or as an addition to the
> previous one (the one with bss.efistub addition)?
>

Only this one change please.

Re: [REGRESSION] linux 6.6.18 and later fails to boot with "initramfs unpacking failed: invalid magic at start of compressed archive"

[Radek Podgorny]

[-- Attachment #1.1: Type: text/plain, Size: 1014 bytes --]

hello ard,

so, i have some bad news. unfortunately, none of the suggested changes 
resolves the issue. :-(

the last two patches still lead to boot-stuck system.

overall, the patches only make the difference in error being printed: 
sometimes it's something like "wrong padding", sometimes the "invalid 
magic" message. i only noticed later so i can't really tell which patch 
leads to which message but i can retry them all and tell you exactly if 
it helps.

anyway, if you have any other patches, i'll be more than happy to test 
them out (and be more careful about the message this time)!

thanks,
r.


On 3/15/24 19:25, Ard Biesheuvel wrote:
> On Fri, 15 Mar 2024 at 19:11, Radek Podgorny <radek@podgorny.cz> wrote:
>>
>> ok, will. the kernel with previous patch is still compiling so i'll
>> queue it. ;-)
>>
>> anyway, should i apply this as a separate patch or as an addition to the
>> previous one (the one with bss.efistub addition)?
>>
> 
> Only this one change please.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [REGRESSION] linux 6.6.18 and later fails to boot with "initramfs unpacking failed: invalid magic at start of compressed archive"

[Ard Biesheuvel]

On Mon, 18 Mar 2024 at 14:14, Radek Podgorny <radek@podgorny.cz> wrote:
>
> hello ard,
>
> so, i have some bad news. unfortunately, none of the suggested changes
> resolves the issue. :-(
>

... except reverting the patch that you bisected the regression to, right?

> the last two patches still lead to boot-stuck system.
>

What does 'boot-stuck' mean? Please provide as much context as you
can. More is more.

> overall, the patches only make the difference in error being printed:
> sometimes it's something like "wrong padding",

Can you share the entire, exact error message?

> sometimes the "invalid
> magic" message. i only noticed later so i can't really tell which patch
> leads to which message but i can retry them all and tell you exactly if
> it helps.
>

Yes, please.

> anyway, if you have any other patches, i'll be more than happy to test
> them out (and be more careful about the message this time)!
>

We should be able to narrow down why that one particular change causes
the issue. I can split the change in question into smaller ones to see
which exact change triggers the failure.

And many thanks for taking the time - I really want to figure out what
is happening here.

Re: [REGRESSION] linux 6.6.18 and later fails to boot with "initramfs unpacking failed: invalid magic at start of compressed archive"

[Radek Podgorny]

[-- Attachment #1.1.1: Type: text/plain, Size: 2499 bytes --]

hi ard!

sorry for the delay, i had some stuff to handle. :-(

anyway, i've set up somewhat more organized testing environment so i can 
now test possible patches much more efficiently (but still not instantly 
- the compilation still takes some time on my machine).

i'm sending results of previous patches. explanation:

99 - unpatched linux-mainline (6.8) - does NOT WORK
100 - applied patch 100 (revert) - WORKS
101 - skipped - patch does not apply cleanly
102 - applied patch 102 - does NOT WORK
...etc. up to 105 - neither of which works :-(

screenshots of stuck boot attached (and in one case - patch100 - unstuck 
boot).

by "stuck boot" i mean a situation when the pc boots up, the bootloader 
loads the kernel (and initramfs?) and tries to continue with the boot 
sequence but gets stuck forever without any signs of further activity. 
ctrl+alt+del does not work - i have to reboot with physical button. see 
the attached pictures to see what i mean (and try to spot the difference 
between non-stuck boot in picture 100 at the very bottom).

eagerly waiting for more - possibly lots - of patches to try!

cheers,
r.


On 3/18/24 14:19, Ard Biesheuvel wrote:
> On Mon, 18 Mar 2024 at 14:14, Radek Podgorny <radek@podgorny.cz> wrote:
>>
>> hello ard,
>>
>> so, i have some bad news. unfortunately, none of the suggested changes
>> resolves the issue. :-(
>>
> 
> ... except reverting the patch that you bisected the regression to, right?
> 
>> the last two patches still lead to boot-stuck system.
>>
> 
> What does 'boot-stuck' mean? Please provide as much context as you
> can. More is more.
> 
>> overall, the patches only make the difference in error being printed:
>> sometimes it's something like "wrong padding",
> 
> Can you share the entire, exact error message?
> 
>> sometimes the "invalid
>> magic" message. i only noticed later so i can't really tell which patch
>> leads to which message but i can retry them all and tell you exactly if
>> it helps.
>>
> 
> Yes, please.
> 
>> anyway, if you have any other patches, i'll be more than happy to test
>> them out (and be more careful about the message this time)!
>>
> 
> We should be able to narrow down why that one particular change causes
> the issue. I can split the change in question into smaller ones to see
> which exact change triggers the failure.
> 
> And many thanks for taking the time - I really want to figure out what
> is happening here.

[-- Attachment #1.1.2: patch100.patch --]
[-- Type: text/x-patch, Size: 2514 bytes --]

diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c
index 7bcc5170043f..4a11470bed5e 100644
--- a/drivers/firmware/efi/libstub/x86-stub.c
+++ b/drivers/firmware/efi/libstub/x86-stub.c
@@ -458,8 +458,9 @@ void __noreturn efi_stub_entry(efi_handle_t handle,
 efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 				   efi_system_table_t *sys_table_arg)
 {
-	static struct boot_params boot_params __page_aligned_bss;
-	struct setup_header *hdr = &boot_params.hdr;
+	struct boot_params *boot_params;
+	struct setup_header *hdr;
+	void *image_base;
 	efi_guid_t proto = LOADED_IMAGE_PROTOCOL_GUID;
 	int options_size = 0;
 	efi_status_t status;
@@ -477,9 +478,30 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 		efi_exit(handle, status);
 	}
 
-	/* Assign the setup_header fields that the kernel actually cares about */
+	image_base = efi_table_attr(image, image_base);
+
+	status = efi_allocate_pages(sizeof(struct boot_params),
+				    (unsigned long *)&boot_params, ULONG_MAX);
+	if (status != EFI_SUCCESS) {
+		efi_err("Failed to allocate lowmem for boot params\n");
+		efi_exit(handle, status);
+	}
+
+	memset(boot_params, 0x0, sizeof(struct boot_params));
+
+	hdr = &boot_params->hdr;
+
+	/* Copy the setup header from the second sector to boot_params */
+	memcpy(&hdr->jump, image_base + 512,
+	       sizeof(struct setup_header) - offsetof(struct setup_header, jump));
+
+	/*
+	 * Fill out some of the header fields ourselves because the
+	 * EFI firmware loader doesn't load the first sector.
+	 */
 	hdr->root_flags	= 1;
 	hdr->vid_mode	= 0xffff;
+	hdr->boot_flag	= 0xAA55;
 
 	hdr->type_of_loader = 0x21;
 
@@ -488,13 +510,25 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 	if (!cmdline_ptr)
 		goto fail;
 
-	efi_set_u64_split((unsigned long)cmdline_ptr, &hdr->cmd_line_ptr,
-			  &boot_params.ext_cmd_line_ptr);
+	efi_set_u64_split((unsigned long)cmdline_ptr,
+			  &hdr->cmd_line_ptr, &boot_params->ext_cmd_line_ptr);
+
+	hdr->ramdisk_image = 0;
+	hdr->ramdisk_size = 0;
+
+	/*
+	 * Disregard any setup data that was provided by the bootloader:
+	 * setup_data could be pointing anywhere, and we have no way of
+	 * authenticating or validating the payload.
+	 */
+	hdr->setup_data = 0;
 
-	efi_stub_entry(handle, sys_table_arg, &boot_params);
+	efi_stub_entry(handle, sys_table_arg, boot_params);
 	/* not reached */
 
 fail:
+	efi_free(sizeof(struct boot_params), (unsigned long)boot_params);
+
 	efi_exit(handle, status);
 }
 

[-- Attachment #1.1.3: patch101.patch --]
[-- Type: text/x-patch, Size: 1241 bytes --]

diff --git a/arch/x86/boot/compressed/vmlinux.lds.S b/arch/x86/boot/compressed/vmlinux.lds.S
index 4ff6ab1b67d9..b22f34b8684a 100644
--- a/arch/x86/boot/compressed/vmlinux.lds.S
+++ b/arch/x86/boot/compressed/vmlinux.lds.S
@@ -47,6 +47,7 @@ SECTIONS
 		_data = . ;
 		*(.data)
 		*(.data.*)
+		*(.bss.efistub)
 		_edata = . ;
 	}
 	. = ALIGN(L1_CACHE_BYTES);
diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
index ef4c12f0877b..a1157c2a7170 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -108,6 +108,13 @@ lib-y				:= $(patsubst %.o,%.stub.o,$(lib-y))
 # https://bugs.llvm.org/show_bug.cgi?id=46480
 STUBCOPY_FLAGS-y		+= --remove-section=.note.gnu.property
 
+#
+# For x86, bootloaders like systemd-boot or grub-efi do not zero-initialize the
+# .bss section, so the .bss section of the EFI stub needs to be included in the
+# .data section of the compressed kernel to ensure initialization. Rename the
+# .bss section here so it's easy to pick out in the linker script.
+#
+STUBCOPY_FLAGS-$(CONFIG_X86)	+= --rename-section .bss=.bss.efistub,load,alloc
 STUBCOPY_RELOC-$(CONFIG_X86_32)	:= R_386_32
 STUBCOPY_RELOC-$(CONFIG_X86_64)	:= R_X86_64_64
 

[-- Attachment #1.1.4: patch102.patch --]
[-- Type: text/x-patch, Size: 1329 bytes --]

diff --git a/arch/x86/boot/compressed/vmlinux.lds.S b/arch/x86/boot/compressed/vmlinux.lds.S
index 083ec6d7722a..10429e900051 100644
--- a/arch/x86/boot/compressed/vmlinux.lds.S
+++ b/arch/x86/boot/compressed/vmlinux.lds.S
@@ -47,9 +47,7 @@ SECTIONS
 		_data = . ;
 		*(.data)
 		*(.data.*)
-
-		/* Add 4 bytes of extra space for a CRC-32 checksum */
-		. = ALIGN(. + 4, 0x200);
+		*(.bss.efistub)
 		_edata = . ;
 	}
 	. = ALIGN(L1_CACHE_BYTES);
diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
index 73f4810f6db3..cffe0d8795fa 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -108,6 +108,13 @@ lib-y				:= $(patsubst %.o,%.stub.o,$(lib-y))
 # https://bugs.llvm.org/show_bug.cgi?id=46480
 STUBCOPY_FLAGS-y		+= --remove-section=.note.gnu.property
 
+#
+# For x86, bootloaders like systemd-boot or grub-efi do not zero-initialize the
+# .bss section, so the .bss section of the EFI stub needs to be included in the
+# .data section of the compressed kernel to ensure initialization. Rename the
+# .bss section here so it's easy to pick out in the linker script.
+#
+STUBCOPY_FLAGS-$(CONFIG_X86)	+= --rename-section .bss=.bss.efistub,load,alloc
 STUBCOPY_RELOC-$(CONFIG_X86_32)	:= R_386_32
 STUBCOPY_RELOC-$(CONFIG_X86_64)	:= R_X86_64_64
 

[-- Attachment #1.1.5: patch103.patch --]
[-- Type: text/x-patch, Size: 966 bytes --]

diff --git a/arch/x86/boot/compressed/vmlinux.lds.S b/arch/x86/boot/compressed/vmlinux.lds.S
index 083ec6d7722a..adfc4d1ae59b 100644
--- a/arch/x86/boot/compressed/vmlinux.lds.S
+++ b/arch/x86/boot/compressed/vmlinux.lds.S
@@ -47,6 +47,7 @@ SECTIONS
 		_data = . ;
 		*(.data)
 		*(.data.*)
+		*(.bss.efistub)
 
 		/* Add 4 bytes of extra space for a CRC-32 checksum */
 		. = ALIGN(. + 4, 0x200);
diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
index 73f4810f6db3..efdf4a31e28f 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -108,6 +108,7 @@ lib-y				:= $(patsubst %.o,%.stub.o,$(lib-y))
 # https://bugs.llvm.org/show_bug.cgi?id=46480
 STUBCOPY_FLAGS-y		+= --remove-section=.note.gnu.property
 
+STUBCOPY_FLAGS-$(CONFIG_X86)   += --rename-section .bss=.bss.efistub,load,alloc
 STUBCOPY_RELOC-$(CONFIG_X86_32)	:= R_386_32
 STUBCOPY_RELOC-$(CONFIG_X86_64)	:= R_X86_64_64
 

[-- Attachment #1.1.6: patch104.patch --]
[-- Type: text/x-patch, Size: 477 bytes --]

diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c
index 99429bc4b0c7..7e3e69cd8778 100644
--- a/drivers/firmware/efi/libstub/x86-stub.c
+++ b/drivers/firmware/efi/libstub/x86-stub.c
@@ -464,6 +464,9 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 	int options_size = 0;
 	efi_status_t status;
 	char *cmdline_ptr;
+	extern char _bss[], _ebss[];
+
+	memset(_bss, 0, _ebss - _bss);
 
 	efi_system_table = sys_table_arg;
 

[-- Attachment #1.1.7: patch105.patch --]
[-- Type: text/x-patch, Size: 318 bytes --]

--- a/drivers/firmware/efi/libstub/x86-stub.c
+++ b/drivers/firmware/efi/libstub/x86-stub.c
@@ -477,6 +477,8 @@
		efi_exit(handle, status);
	}

+	memset(&boot_params, 0, sizeof(boot_params));
+
	/* Assign the setup_header fields that the kernel actually cares about */
	hdr->root_flags = 1;
	hdr->vid_mode   = 0xffff;

[-- Attachment #1.1.8: 99.jpg --]
[-- Type: image/jpeg, Size: 725777 bytes --]

[-- Attachment #1.1.9: 100.jpg --]
[-- Type: image/jpeg, Size: 796077 bytes --]

[-- Attachment #1.1.10: 102.jpg --]
[-- Type: image/jpeg, Size: 762794 bytes --]

[-- Attachment #1.1.11: 103.jpg --]
[-- Type: image/jpeg, Size: 703456 bytes --]

[-- Attachment #1.1.12: 104.jpg --]
[-- Type: image/jpeg, Size: 679021 bytes --]

[-- Attachment #1.1.13: 105.jpg --]
[-- Type: image/jpeg, Size: 689637 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [REGRESSION] linux 6.6.18 and later fails to boot with "initramfs unpacking failed: invalid magic at start of compressed archive"

[Ard Biesheuvel]

[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]

On Fri, 22 Mar 2024 at 18:29, Radek Podgorny <radek@podgorny.cz> wrote:
>
> hi ard!
>
> sorry for the delay, i had some stuff to handle. :-(
>
> anyway, i've set up somewhat more organized testing environment so i can
> now test possible patches much more efficiently (but still not instantly
> - the compilation still takes some time on my machine).
>
> i'm sending results of previous patches. explanation:
>
> 99 - unpatched linux-mainline (6.8) - does NOT WORK
> 100 - applied patch 100 (revert) - WORKS
> 101 - skipped - patch does not apply cleanly
> 102 - applied patch 102 - does NOT WORK
> ...etc. up to 105 - neither of which works :-(
>
> screenshots of stuck boot attached (and in one case - patch100 - unstuck
> boot).
>
> by "stuck boot" i mean a situation when the pc boots up, the bootloader
> loads the kernel (and initramfs?) and tries to continue with the boot
> sequence but gets stuck forever without any signs of further activity.
> ctrl+alt+del does not work - i have to reboot with physical button. see
> the attached pictures to see what i mean (and try to spot the difference
> between non-stuck boot in picture 100 at the very bottom).
>
> eagerly waiting for more - possibly lots - of patches to try!
>

Please try the attached patches - they are partial reverts of the
offending patch, and knowing which one of those breaks your system
would be useful to narrow this down further.

[-- Attachment #2: 0001-Partial-revert-of-8117961d98f-2.patch --]
[-- Type: text/x-patch, Size: 2078 bytes --]

From 2095b1979abbc22ea83ca3db171eb3f78bce9968 Mon Sep 17 00:00:00 2001
From: Ard Biesheuvel <ardb@kernel.org>
Date: Fri, 22 Mar 2024 18:21:29 +0100
Subject: [PATCH] Partial revert of 8117961d98f #2

---
 drivers/firmware/efi/libstub/x86-stub.c | 23 +++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c
index 99429bc4b0c7..d3678ca23980 100644
--- a/drivers/firmware/efi/libstub/x86-stub.c
+++ b/drivers/firmware/efi/libstub/x86-stub.c
@@ -460,6 +460,7 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 {
 	static struct boot_params boot_params __page_aligned_bss;
 	struct setup_header *hdr = &boot_params.hdr;
+	void *image_base;
 	efi_guid_t proto = LOADED_IMAGE_PROTOCOL_GUID;
 	int options_size = 0;
 	efi_status_t status;
@@ -477,9 +478,19 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 		efi_exit(handle, status);
 	}
 
-	/* Assign the setup_header fields that the kernel actually cares about */
+	image_base = efi_table_attr(image, image_base);
+
+	/* Copy the setup header from the second sector to boot_params */
+	memcpy(&hdr->jump, image_base + 512,
+	       sizeof(struct setup_header) - offsetof(struct setup_header, jump));
+
+	/*
+	 * Fill out some of the header fields ourselves because the
+	 * EFI firmware loader doesn't load the first sector.
+	 */
 	hdr->root_flags	= 1;
 	hdr->vid_mode	= 0xffff;
+	hdr->boot_flag	= 0xAA55;
 
 	hdr->type_of_loader = 0x21;
 
@@ -491,6 +502,16 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 	efi_set_u64_split((unsigned long)cmdline_ptr, &hdr->cmd_line_ptr,
 			  &boot_params.ext_cmd_line_ptr);
 
+	hdr->ramdisk_image = 0;
+	hdr->ramdisk_size = 0;
+
+	/*
+	 * Disregard any setup data that was provided by the bootloader:
+	 * setup_data could be pointing anywhere, and we have no way of
+	 * authenticating or validating the payload.
+	 */
+	hdr->setup_data = 0;
+
 	efi_stub_entry(handle, sys_table_arg, &boot_params);
 	/* not reached */
 
-- 
2.44.0.396.g6e790dbe36-goog


[-- Attachment #3: 0001-Partial-revert-of-8117961d98f-1.patch --]
[-- Type: text/x-patch, Size: 2155 bytes --]

From 9d3df2f3d781a770e93efd5abf8cb872b1501cf4 Mon Sep 17 00:00:00 2001
From: Ard Biesheuvel <ardb@kernel.org>
Date: Fri, 22 Mar 2024 18:11:32 +0100
Subject: [PATCH] Partial revert of 8117961d98f #1

---
 drivers/firmware/efi/libstub/x86-stub.c | 25 +++++++++++++++-----
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c
index 99429bc4b0c7..b117fe9be516 100644
--- a/drivers/firmware/efi/libstub/x86-stub.c
+++ b/drivers/firmware/efi/libstub/x86-stub.c
@@ -458,8 +458,8 @@ void __noreturn efi_stub_entry(efi_handle_t handle,
 efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 				   efi_system_table_t *sys_table_arg)
 {
-	static struct boot_params boot_params __page_aligned_bss;
-	struct setup_header *hdr = &boot_params.hdr;
+	struct boot_params *boot_params;
+	struct setup_header *hdr;
 	efi_guid_t proto = LOADED_IMAGE_PROTOCOL_GUID;
 	int options_size = 0;
 	efi_status_t status;
@@ -477,7 +477,17 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 		efi_exit(handle, status);
 	}
 
-	/* Assign the setup_header fields that the kernel actually cares about */
+	status = efi_allocate_pages(sizeof(struct boot_params),
+				    (unsigned long *)&boot_params, ULONG_MAX);
+	if (status != EFI_SUCCESS) {
+		efi_err("Failed to allocate lowmem for boot params\n");
+		efi_exit(handle, status);
+	}
+
+	memset(boot_params, 0x0, sizeof(struct boot_params));
+
+	hdr = &boot_params->hdr;
+
 	hdr->root_flags	= 1;
 	hdr->vid_mode	= 0xffff;
 
@@ -488,13 +498,16 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 	if (!cmdline_ptr)
 		goto fail;
 
-	efi_set_u64_split((unsigned long)cmdline_ptr, &hdr->cmd_line_ptr,
-			  &boot_params.ext_cmd_line_ptr);
+	efi_set_u64_split((unsigned long)cmdline_ptr,
+			  &hdr->cmd_line_ptr, &boot_params->ext_cmd_line_ptr);
+
 
-	efi_stub_entry(handle, sys_table_arg, &boot_params);
+	efi_stub_entry(handle, sys_table_arg, boot_params);
 	/* not reached */
 
 fail:
+	efi_free(sizeof(struct boot_params), (unsigned long)boot_params);
+
 	efi_exit(handle, status);
 }
 
-- 
2.44.0.396.g6e790dbe36-goog

Re: [REGRESSION] linux 6.6.18 and later fails to boot with "initramfs unpacking failed: invalid magic at start of compressed archive"

[Radek Podgorny]

[-- Attachment #1.1.1: Type: text/plain, Size: 1721 bytes --]

hi!

patch 106 - does NOT work - result same as with patch 105 (Initramfs 
unpacking failed: broken padding
patch 107 - WORKS - result same asi with patch 100 (full revert)

cheers,
r.


On 3/22/24 18:23, Ard Biesheuvel wrote:
> On Fri, 22 Mar 2024 at 18:29, Radek Podgorny <radek@podgorny.cz> wrote:
>>
>> hi ard!
>>
>> sorry for the delay, i had some stuff to handle. :-(
>>
>> anyway, i've set up somewhat more organized testing environment so i can
>> now test possible patches much more efficiently (but still not instantly
>> - the compilation still takes some time on my machine).
>>
>> i'm sending results of previous patches. explanation:
>>
>> 99 - unpatched linux-mainline (6.8) - does NOT WORK
>> 100 - applied patch 100 (revert) - WORKS
>> 101 - skipped - patch does not apply cleanly
>> 102 - applied patch 102 - does NOT WORK
>> ...etc. up to 105 - neither of which works :-(
>>
>> screenshots of stuck boot attached (and in one case - patch100 - unstuck
>> boot).
>>
>> by "stuck boot" i mean a situation when the pc boots up, the bootloader
>> loads the kernel (and initramfs?) and tries to continue with the boot
>> sequence but gets stuck forever without any signs of further activity.
>> ctrl+alt+del does not work - i have to reboot with physical button. see
>> the attached pictures to see what i mean (and try to spot the difference
>> between non-stuck boot in picture 100 at the very bottom).
>>
>> eagerly waiting for more - possibly lots - of patches to try!
>>
> 
> Please try the attached patches - they are partial reverts of the
> offending patch, and knowing which one of those breaks your system
> would be useful to narrow this down further.

[-- Attachment #1.1.2: patch106.patch --]
[-- Type: text/x-patch, Size: 2155 bytes --]

From 9d3df2f3d781a770e93efd5abf8cb872b1501cf4 Mon Sep 17 00:00:00 2001
From: Ard Biesheuvel <ardb@kernel.org>
Date: Fri, 22 Mar 2024 18:11:32 +0100
Subject: [PATCH] Partial revert of 8117961d98f #1

---
 drivers/firmware/efi/libstub/x86-stub.c | 25 +++++++++++++++-----
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c
index 99429bc4b0c7..b117fe9be516 100644
--- a/drivers/firmware/efi/libstub/x86-stub.c
+++ b/drivers/firmware/efi/libstub/x86-stub.c
@@ -458,8 +458,8 @@ void __noreturn efi_stub_entry(efi_handle_t handle,
 efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 				   efi_system_table_t *sys_table_arg)
 {
-	static struct boot_params boot_params __page_aligned_bss;
-	struct setup_header *hdr = &boot_params.hdr;
+	struct boot_params *boot_params;
+	struct setup_header *hdr;
 	efi_guid_t proto = LOADED_IMAGE_PROTOCOL_GUID;
 	int options_size = 0;
 	efi_status_t status;
@@ -477,7 +477,17 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 		efi_exit(handle, status);
 	}
 
-	/* Assign the setup_header fields that the kernel actually cares about */
+	status = efi_allocate_pages(sizeof(struct boot_params),
+				    (unsigned long *)&boot_params, ULONG_MAX);
+	if (status != EFI_SUCCESS) {
+		efi_err("Failed to allocate lowmem for boot params\n");
+		efi_exit(handle, status);
+	}
+
+	memset(boot_params, 0x0, sizeof(struct boot_params));
+
+	hdr = &boot_params->hdr;
+
 	hdr->root_flags	= 1;
 	hdr->vid_mode	= 0xffff;
 
@@ -488,13 +498,16 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 	if (!cmdline_ptr)
 		goto fail;
 
-	efi_set_u64_split((unsigned long)cmdline_ptr, &hdr->cmd_line_ptr,
-			  &boot_params.ext_cmd_line_ptr);
+	efi_set_u64_split((unsigned long)cmdline_ptr,
+			  &hdr->cmd_line_ptr, &boot_params->ext_cmd_line_ptr);
+
 
-	efi_stub_entry(handle, sys_table_arg, &boot_params);
+	efi_stub_entry(handle, sys_table_arg, boot_params);
 	/* not reached */
 
 fail:
+	efi_free(sizeof(struct boot_params), (unsigned long)boot_params);
+
 	efi_exit(handle, status);
 }
 
-- 
2.44.0.396.g6e790dbe36-goog


[-- Attachment #1.1.3: patch107.patch --]
[-- Type: text/x-patch, Size: 2078 bytes --]

From 2095b1979abbc22ea83ca3db171eb3f78bce9968 Mon Sep 17 00:00:00 2001
From: Ard Biesheuvel <ardb@kernel.org>
Date: Fri, 22 Mar 2024 18:21:29 +0100
Subject: [PATCH] Partial revert of 8117961d98f #2

---
 drivers/firmware/efi/libstub/x86-stub.c | 23 +++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c
index 99429bc4b0c7..d3678ca23980 100644
--- a/drivers/firmware/efi/libstub/x86-stub.c
+++ b/drivers/firmware/efi/libstub/x86-stub.c
@@ -460,6 +460,7 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 {
 	static struct boot_params boot_params __page_aligned_bss;
 	struct setup_header *hdr = &boot_params.hdr;
+	void *image_base;
 	efi_guid_t proto = LOADED_IMAGE_PROTOCOL_GUID;
 	int options_size = 0;
 	efi_status_t status;
@@ -477,9 +478,19 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 		efi_exit(handle, status);
 	}
 
-	/* Assign the setup_header fields that the kernel actually cares about */
+	image_base = efi_table_attr(image, image_base);
+
+	/* Copy the setup header from the second sector to boot_params */
+	memcpy(&hdr->jump, image_base + 512,
+	       sizeof(struct setup_header) - offsetof(struct setup_header, jump));
+
+	/*
+	 * Fill out some of the header fields ourselves because the
+	 * EFI firmware loader doesn't load the first sector.
+	 */
 	hdr->root_flags	= 1;
 	hdr->vid_mode	= 0xffff;
+	hdr->boot_flag	= 0xAA55;
 
 	hdr->type_of_loader = 0x21;
 
@@ -491,6 +502,16 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 	efi_set_u64_split((unsigned long)cmdline_ptr, &hdr->cmd_line_ptr,
 			  &boot_params.ext_cmd_line_ptr);
 
+	hdr->ramdisk_image = 0;
+	hdr->ramdisk_size = 0;
+
+	/*
+	 * Disregard any setup data that was provided by the bootloader:
+	 * setup_data could be pointing anywhere, and we have no way of
+	 * authenticating or validating the payload.
+	 */
+	hdr->setup_data = 0;
+
 	efi_stub_entry(handle, sys_table_arg, &boot_params);
 	/* not reached */
 
-- 
2.44.0.396.g6e790dbe36-goog


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [REGRESSION] linux 6.6.18 and later fails to boot with "initramfs unpacking failed: invalid magic at start of compressed archive"

[Ard Biesheuvel]

[-- Attachment #1: Type: text/plain, Size: 519 bytes --]

On Mon, 25 Mar 2024 at 16:56, Radek Podgorny <radek@podgorny.cz> wrote:
>
> hi!
>
> patch 106 - does NOT work - result same as with patch 105 (Initramfs
> unpacking failed: broken padding
> patch 107 - WORKS - result same asi with patch 100 (full revert)
>


OK, we're making progress!

Please try the attached patches (try 0001 first and then 0001+0002)
instead of 107, and capture the output of the combination that
produces a working boot. There should be some diagnostic data on the
screen followed by a 10s delay.

[-- Attachment #2: 0001-Dump-setup-header.patch --]
[-- Type: text/x-patch, Size: 2547 bytes --]

From 11add4a8dae5c36b30da018e30d62a7fc1a37bc0 Mon Sep 17 00:00:00 2001
From: Ard Biesheuvel <ardb@kernel.org>
Date: Mon, 25 Mar 2024 17:18:33 +0100
Subject: [PATCH 1/2] Dump setup header

---
 drivers/firmware/efi/libstub/x86-stub.c | 29 ++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c
index 7bcc5170043f..aa44bda2305f 100644
--- a/drivers/firmware/efi/libstub/x86-stub.c
+++ b/drivers/firmware/efi/libstub/x86-stub.c
@@ -450,6 +450,20 @@ void __noreturn efi_stub_entry(efi_handle_t handle,
 			       efi_system_table_t *sys_table_arg,
 			       struct boot_params *boot_params);
 
+static void dump_buf(const u8 *p, int size)
+{
+	for (int i = 0; i < size; i++) {
+		char s[4], *c = " ..";
+
+		if (!(i % 32))
+			efi_puts("\n#####");
+		if (p[i])
+			snprintf(c = s, 4, " %02x", p[i]);
+		efi_puts(c);
+	}
+	efi_puts("\n");
+}
+
 /*
  * Because the x86 boot code expects to be passed a boot_params we
  * need to create one ourselves (usually the bootloader would create
@@ -460,6 +474,7 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 {
 	static struct boot_params boot_params __page_aligned_bss;
 	struct setup_header *hdr = &boot_params.hdr;
+	void *image_base;
 	efi_guid_t proto = LOADED_IMAGE_PROTOCOL_GUID;
 	int options_size = 0;
 	efi_status_t status;
@@ -477,6 +492,16 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 		efi_exit(handle, status);
 	}
 
+	dump_buf((u8 *)hdr, sizeof(*hdr));
+
+	image_base = efi_table_attr(image, image_base);
+
+	/* Copy the setup header from the second sector to boot_params */
+	memcpy(&hdr->jump, image_base + 512,
+	       sizeof(struct setup_header) - offsetof(struct setup_header, jump));
+
+	dump_buf((u8 *)hdr, sizeof(*hdr));
+
 	/* Assign the setup_header fields that the kernel actually cares about */
 	hdr->root_flags	= 1;
 	hdr->vid_mode	= 0xffff;
@@ -491,6 +516,8 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 	efi_set_u64_split((unsigned long)cmdline_ptr, &hdr->cmd_line_ptr,
 			  &boot_params.ext_cmd_line_ptr);
 
+	dump_buf((u8 *)hdr, sizeof(*hdr));
+
 	efi_stub_entry(handle, sys_table_arg, &boot_params);
 	/* not reached */
 
@@ -908,6 +935,8 @@ void __noreturn efi_stub_entry(efi_handle_t handle,
 				  &boot_params->ext_ramdisk_size);
 	}
 
+	dump_buf((u8 *)hdr, sizeof(*hdr));
+	efi_bs_call(stall, 10 * EFI_USEC_PER_SEC);
 
 	/*
 	 * If the boot loader gave us a value for secure_boot then we use that,
-- 
2.44.0.396.g6e790dbe36-goog


[-- Attachment #3: 0002-Set-some-header-flags.patch --]
[-- Type: text/x-patch, Size: 1359 bytes --]

From 397c0a38a8367acd9bbebd2ccd8da8737158285f Mon Sep 17 00:00:00 2001
From: Ard Biesheuvel <ardb@kernel.org>
Date: Mon, 25 Mar 2024 17:22:23 +0100
Subject: [PATCH 2/2] Set some header flags

---
 drivers/firmware/efi/libstub/x86-stub.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c
index aa44bda2305f..07b237dafa04 100644
--- a/drivers/firmware/efi/libstub/x86-stub.c
+++ b/drivers/firmware/efi/libstub/x86-stub.c
@@ -505,6 +505,7 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 	/* Assign the setup_header fields that the kernel actually cares about */
 	hdr->root_flags	= 1;
 	hdr->vid_mode	= 0xffff;
+	hdr->boot_flag	= 0xAA55;
 
 	hdr->type_of_loader = 0x21;
 
@@ -516,6 +517,16 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 	efi_set_u64_split((unsigned long)cmdline_ptr, &hdr->cmd_line_ptr,
 			  &boot_params.ext_cmd_line_ptr);
 
+	hdr->ramdisk_image = 0;
+	hdr->ramdisk_size = 0;
+
+	/*
+	 * Disregard any setup data that was provided by the bootloader:
+	 * setup_data could be pointing anywhere, and we have no way of
+	 * authenticating or validating the payload.
+	 */
+	hdr->setup_data = 0;
+
 	dump_buf((u8 *)hdr, sizeof(*hdr));
 
 	efi_stub_entry(handle, sys_table_arg, &boot_params);
-- 
2.44.0.396.g6e790dbe36-goog

Re: [REGRESSION] linux 6.6.18 and later fails to boot with "initramfs unpacking failed: invalid magic at start of compressed archive"

[Radek Podgorny]

[-- Attachment #1.1.1: Type: text/plain, Size: 1081 bytes --]

hi!

results:

108 - just patch 0001 - WORKS
109 - patch 0001+0002 - WORKS

visually, i see no difference between the output of 108 and 109. :-(

both start with a hex dump before the "normal" booting sequence. 
unfortunately, i doesn't seem to fit to screen so the top of the dump 
scrolls of almost immediately. i was able to only shoot the "bottom" of 
the dump. i can make a video and try to extract frames if you also need 
the beginning of the dump.

r.

On 3/25/24 5:24 PM, Ard Biesheuvel wrote:
> On Mon, 25 Mar 2024 at 16:56, Radek Podgorny <radek@podgorny.cz> wrote:
>>
>> hi!
>>
>> patch 106 - does NOT work - result same as with patch 105 (Initramfs
>> unpacking failed: broken padding
>> patch 107 - WORKS - result same asi with patch 100 (full revert)
>>
> 
> 
> OK, we're making progress!
> 
> Please try the attached patches (try 0001 first and then 0001+0002)
> instead of 107, and capture the output of the combination that
> produces a working boot. There should be some diagnostic data on the
> screen followed by a 10s delay.

[-- Attachment #1.1.2: patch108.patch --]
[-- Type: text/x-patch, Size: 2547 bytes --]

From 11add4a8dae5c36b30da018e30d62a7fc1a37bc0 Mon Sep 17 00:00:00 2001
From: Ard Biesheuvel <ardb@kernel.org>
Date: Mon, 25 Mar 2024 17:18:33 +0100
Subject: [PATCH 1/2] Dump setup header

---
 drivers/firmware/efi/libstub/x86-stub.c | 29 ++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c
index 7bcc5170043f..aa44bda2305f 100644
--- a/drivers/firmware/efi/libstub/x86-stub.c
+++ b/drivers/firmware/efi/libstub/x86-stub.c
@@ -450,6 +450,20 @@ void __noreturn efi_stub_entry(efi_handle_t handle,
 			       efi_system_table_t *sys_table_arg,
 			       struct boot_params *boot_params);
 
+static void dump_buf(const u8 *p, int size)
+{
+	for (int i = 0; i < size; i++) {
+		char s[4], *c = " ..";
+
+		if (!(i % 32))
+			efi_puts("\n#####");
+		if (p[i])
+			snprintf(c = s, 4, " %02x", p[i]);
+		efi_puts(c);
+	}
+	efi_puts("\n");
+}
+
 /*
  * Because the x86 boot code expects to be passed a boot_params we
  * need to create one ourselves (usually the bootloader would create
@@ -460,6 +474,7 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 {
 	static struct boot_params boot_params __page_aligned_bss;
 	struct setup_header *hdr = &boot_params.hdr;
+	void *image_base;
 	efi_guid_t proto = LOADED_IMAGE_PROTOCOL_GUID;
 	int options_size = 0;
 	efi_status_t status;
@@ -477,6 +492,16 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 		efi_exit(handle, status);
 	}
 
+	dump_buf((u8 *)hdr, sizeof(*hdr));
+
+	image_base = efi_table_attr(image, image_base);
+
+	/* Copy the setup header from the second sector to boot_params */
+	memcpy(&hdr->jump, image_base + 512,
+	       sizeof(struct setup_header) - offsetof(struct setup_header, jump));
+
+	dump_buf((u8 *)hdr, sizeof(*hdr));
+
 	/* Assign the setup_header fields that the kernel actually cares about */
 	hdr->root_flags	= 1;
 	hdr->vid_mode	= 0xffff;
@@ -491,6 +516,8 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 	efi_set_u64_split((unsigned long)cmdline_ptr, &hdr->cmd_line_ptr,
 			  &boot_params.ext_cmd_line_ptr);
 
+	dump_buf((u8 *)hdr, sizeof(*hdr));
+
 	efi_stub_entry(handle, sys_table_arg, &boot_params);
 	/* not reached */
 
@@ -908,6 +935,8 @@ void __noreturn efi_stub_entry(efi_handle_t handle,
 				  &boot_params->ext_ramdisk_size);
 	}
 
+	dump_buf((u8 *)hdr, sizeof(*hdr));
+	efi_bs_call(stall, 10 * EFI_USEC_PER_SEC);
 
 	/*
 	 * If the boot loader gave us a value for secure_boot then we use that,
-- 
2.44.0.396.g6e790dbe36-goog


[-- Attachment #1.1.3: patch109_apply_with_108.patch --]
[-- Type: text/x-patch, Size: 1359 bytes --]

From 397c0a38a8367acd9bbebd2ccd8da8737158285f Mon Sep 17 00:00:00 2001
From: Ard Biesheuvel <ardb@kernel.org>
Date: Mon, 25 Mar 2024 17:22:23 +0100
Subject: [PATCH 2/2] Set some header flags

---
 drivers/firmware/efi/libstub/x86-stub.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c
index aa44bda2305f..07b237dafa04 100644
--- a/drivers/firmware/efi/libstub/x86-stub.c
+++ b/drivers/firmware/efi/libstub/x86-stub.c
@@ -505,6 +505,7 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 	/* Assign the setup_header fields that the kernel actually cares about */
 	hdr->root_flags	= 1;
 	hdr->vid_mode	= 0xffff;
+	hdr->boot_flag	= 0xAA55;
 
 	hdr->type_of_loader = 0x21;
 
@@ -516,6 +517,16 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 	efi_set_u64_split((unsigned long)cmdline_ptr, &hdr->cmd_line_ptr,
 			  &boot_params.ext_cmd_line_ptr);
 
+	hdr->ramdisk_image = 0;
+	hdr->ramdisk_size = 0;
+
+	/*
+	 * Disregard any setup data that was provided by the bootloader:
+	 * setup_data could be pointing anywhere, and we have no way of
+	 * authenticating or validating the payload.
+	 */
+	hdr->setup_data = 0;
+
 	dump_buf((u8 *)hdr, sizeof(*hdr));
 
 	efi_stub_entry(handle, sys_table_arg, &boot_params);
-- 
2.44.0.396.g6e790dbe36-goog


[-- Attachment #1.1.4: 108_1.jpg --]
[-- Type: image/jpeg, Size: 401378 bytes --]

[-- Attachment #1.1.5: 108_2.jpg --]
[-- Type: image/jpeg, Size: 729460 bytes --]

[-- Attachment #1.1.6: 109_1.jpg --]
[-- Type: image/jpeg, Size: 415561 bytes --]

[-- Attachment #1.1.7: 109_2.jpg --]
[-- Type: image/jpeg, Size: 766020 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [REGRESSION] linux 6.6.18 and later fails to boot with "initramfs unpacking failed: invalid magic at start of compressed archive"

[Ard Biesheuvel]

On Thu, 28 Mar 2024 at 11:18, Radek Podgorny <radek@podgorny.cz> wrote:
>
> hi!
>
> results:
>
> 108 - just patch 0001 - WORKS
> 109 - patch 0001+0002 - WORKS
>
> visually, i see no difference between the output of 108 and 109. :-(
>
> both start with a hex dump before the "normal" booting sequence.
> unfortunately, i doesn't seem to fit to screen so the top of the dump
> scrolls of almost immediately. i was able to only shoot the "bottom" of
> the dump. i can make a video and try to extract frames if you also need
> the beginning of the dump.
>

Can you drop the last two 'dump_buf()' calls and try again? But keep the call to

efi_bs_call(stall, 10 * EFI_USEC_PER_SEC);

which is what generates the 10s delay.

The first dump is interesting because the memcpy() that is being
brought back overwrites those contents, and I'd like to see what is
there before in your case.

Also fine just to capture it on video - I suspect it's all 0x0 anyway
(.. in the dump)



>
> On 3/25/24 5:24 PM, Ard Biesheuvel wrote:
> > On Mon, 25 Mar 2024 at 16:56, Radek Podgorny <radek@podgorny.cz> wrote:
> >>
> >> hi!
> >>
> >> patch 106 - does NOT work - result same as with patch 105 (Initramfs
> >> unpacking failed: broken padding
> >> patch 107 - WORKS - result same asi with patch 100 (full revert)
> >>
> >
> >
> > OK, we're making progress!
> >
> > Please try the attached patches (try 0001 first and then 0001+0002)
> > instead of 107, and capture the output of the combination that
> > produces a working boot. There should be some diagnostic data on the
> > screen followed by a 10s delay.

Re: [REGRESSION] linux 6.6.18 and later fails to boot with "initramfs unpacking failed: invalid magic at start of compressed archive"

[Ard Biesheuvel]

On Thu, 28 Mar 2024 at 11:41, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Thu, 28 Mar 2024 at 11:18, Radek Podgorny <radek@podgorny.cz> wrote:
> >
> > hi!
> >
> > results:
> >
> > 108 - just patch 0001 - WORKS
> > 109 - patch 0001+0002 - WORKS
> >
> > visually, i see no difference between the output of 108 and 109. :-(
> >
> > both start with a hex dump before the "normal" booting sequence.
> > unfortunately, i doesn't seem to fit to screen so the top of the dump
> > scrolls of almost immediately. i was able to only shoot the "bottom" of
> > the dump. i can make a video and try to extract frames if you also need
> > the beginning of the dump.
> >
>
> Can you drop the last two 'dump_buf()' calls and try again? But keep the call to
>
> efi_bs_call(stall, 10 * EFI_USEC_PER_SEC);
>
> which is what generates the 10s delay.
>
> The first dump is interesting because the memcpy() that is being
> brought back overwrites those contents, and I'd like to see what is
> there before in your case.
>
> Also fine just to capture it on video - I suspect it's all 0x0 anyway
> (.. in the dump)
>

After some more head scratching, I identified an issue in the original
patch that might explain the behavior you are seeing. Could you try
the below please? (and drop all the other reverts)

--- a/drivers/firmware/efi/libstub/x86-stub.c
+++ b/drivers/firmware/efi/libstub/x86-stub.c
@@ -496,6 +496,7 @@
        hdr->vid_mode   = 0xffff;

        hdr->type_of_loader = 0x21;
+       hdr->initrd_addr_max = INT_MAX;

        /* Convert unicode cmdline to ascii */
        cmdline_ptr = efi_convert_cmdline(image, &options_size);

Re: [REGRESSION] linux 6.6.18 and later fails to boot with "initramfs unpacking failed: invalid magic at start of compressed archive"

[Radek Podgorny]

[-- Attachment #1.1.1: Type: text/plain, Size: 1944 bytes --]

hello,

this patch (i named it 112) WORKS. no initramfs error, normal boot sequence.

r.

p.s.: i'm still working on previous (dump) patches - should i not continue?


On 3/28/24 3:49 PM, Ard Biesheuvel wrote:
> On Thu, 28 Mar 2024 at 11:41, Ard Biesheuvel <ardb@kernel.org> wrote:
>>
>> On Thu, 28 Mar 2024 at 11:18, Radek Podgorny <radek@podgorny.cz> wrote:
>>>
>>> hi!
>>>
>>> results:
>>>
>>> 108 - just patch 0001 - WORKS
>>> 109 - patch 0001+0002 - WORKS
>>>
>>> visually, i see no difference between the output of 108 and 109. :-(
>>>
>>> both start with a hex dump before the "normal" booting sequence.
>>> unfortunately, i doesn't seem to fit to screen so the top of the dump
>>> scrolls of almost immediately. i was able to only shoot the "bottom" of
>>> the dump. i can make a video and try to extract frames if you also need
>>> the beginning of the dump.
>>>
>>
>> Can you drop the last two 'dump_buf()' calls and try again? But keep the call to
>>
>> efi_bs_call(stall, 10 * EFI_USEC_PER_SEC);
>>
>> which is what generates the 10s delay.
>>
>> The first dump is interesting because the memcpy() that is being
>> brought back overwrites those contents, and I'd like to see what is
>> there before in your case.
>>
>> Also fine just to capture it on video - I suspect it's all 0x0 anyway
>> (.. in the dump)
>>
> 
> After some more head scratching, I identified an issue in the original
> patch that might explain the behavior you are seeing. Could you try
> the below please? (and drop all the other reverts)
> 
> --- a/drivers/firmware/efi/libstub/x86-stub.c
> +++ b/drivers/firmware/efi/libstub/x86-stub.c
> @@ -496,6 +496,7 @@
>          hdr->vid_mode   = 0xffff;
> 
>          hdr->type_of_loader = 0x21;
> +       hdr->initrd_addr_max = INT_MAX;
> 
>          /* Convert unicode cmdline to ascii */
>          cmdline_ptr = efi_convert_cmdline(image, &options_size);

[-- Attachment #1.1.2: patch112.patch --]
[-- Type: text/x-patch, Size: 308 bytes --]

--- a/drivers/firmware/efi/libstub/x86-stub.c
+++ b/drivers/firmware/efi/libstub/x86-stub.c
@@ -496,6 +496,7 @@
 	hdr->vid_mode   = 0xffff;
 
 	hdr->type_of_loader = 0x21;
+	hdr->initrd_addr_max = INT_MAX;
 
 	/* Convert unicode cmdline to ascii */
 	cmdline_ptr = efi_convert_cmdline(image, &options_size);

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [REGRESSION] linux 6.6.18 and later fails to boot with "initramfs unpacking failed: invalid magic at start of compressed archive"

[Ard Biesheuvel]

On Fri, 29 Mar 2024 at 12:43, Radek Podgorny <radek@podgorny.cz> wrote:
>
> hello,
>
> this patch (i named it 112) WORKS. no initramfs error, normal boot sequence.
>

I'll take that as a tested-by, thanks

I'll send this fix out to Linus today, so it should hit v6.9-rc2 and
make its way back through the stable releases in the following weeks.