lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMj1kXEQXZc2Vpgh5JA3nCCw=LB0kjLgQoximQ4pZhcJ91iOnw@mail.gmail.com>
Date: Tue, 23 Jul 2024 16:26:37 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: "Shao, Marshall" <Marshall.Shao@...l.com>
Cc: "linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "hpa@...or.com" <hpa@...or.com>, 
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>, "bp@...en8.de" <bp@...en8.de>, 
	"mingo@...hat.com" <mingo@...hat.com>, "tglx@...utronix.de" <tglx@...utronix.de>, 
	"Mishra, Ashish" <Ashish.Mishra4@...l.com>, "Chia, Jia Yuan" <JiaYuan.Chia@...l.com>, 
	"Dion, Christopher" <Christopher.Dion@...l.com>, "Caisse, Joe" <Joe.Caisse@...l.com>, 
	"Mukundan, Govind" <Govind.Mukundan@...l.com>
Subject: Re: [Patch] Do not clear BSS region in x86 stub

On Tue, 23 Jul 2024 at 16:21, Shao, Marshall <Marshall.Shao@...l.com> wrote:
>
> Hi Ard,
>
> Many thanks for your reply.
>
> > systemd-boot does not use the EFI handover protocol. Please try to
> > determine where this confusion comes from: are you using a UKI image
> > perhaps?
>
> I can confirm that both systemd-boot and stub will be used, and you
> are correct about the stub part, because currently, the stub will lead
> the system to handover protocol and trigger the problem.
>

Can you explain why this is the case? systemd-stub should only use the
EFI handover protocol for v5.8 or older.

> > I am trying to understand *why* this particular change works around
> > the issue. Please elaborate.
>
> When I removed the memset, and booted to efi_decompress_kernel, the
> boot service crashed, and it indicated that the memory region from _bss
> to the end of boot_heap cannot be overwritten. Upon inspecting the data
> in the BSS region found one thing is that the _bss address is not fixed on
> each boot (when the MOR bit is set to 1), and it changes randomly.
>
> For example, in normal boot the _bss address is 0xffee0000, if I set MOR
> to 1, then the address shifts to 0xff990000 or 0xff991000 or
>  0xff993000. I cannot predict which will be the starting address for the
> next boot.
>
> Since the entire BSS region was not cleaned, and it contains zeros and
> other data, so I tried to increase the boot_stack size by 0x3000 to
> cover the 'fragile' part.
>

This is not a proper fix. As I indicated in my previous reply, even if
you omit the memset() of BSS, the running code will still treat it as
usable memory, whereas the memory is already allocated for something
else.

> > My preliminary conclusion here is that your implementation of the EFI
> > handover protocol (which I fail to understand where it comes from) is
> > not allocating enough memory. This should be fixed on the bootloader
> > side, as not clearing the BSS does not prevent this memory from being
> > corrupted.
>
> I understand that the handover protocol is nearing the end of its support
> and it seems I am only one experiencing the issue. However,
> from the perspective of backward compatibility, I think this patch maybe
> useful.
>

Again, this is not an issue in the implementation of the EFI handover
protocol. It is an issue in the implementation of the bootloader.

I filed an issue with systemd here:
https://github.com/systemd/systemd/issues/33816

I will not consider this patch for the kernel - please work with
systemd upstream and/or your downstream to clarify why the EFI
handover protocol is being used to begin with, and get it fixed in
your code base.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ