On Thu, 31 Oct 2024 at 15:17, Breno Leitao <leitao@xxxxxxxxxx> wrote: > > Hello Ard, > > On Thu, Oct 31, 2024 at 11:44:00AM +0100, Ard Biesheuvel wrote: > > From: Ard Biesheuvel <ardb@xxxxxxxxxx> > > > > There are reports [0] of cases where a corrupt EFI Memory Attributes > > Table leads to out of memory issues at boot because the descriptor size > > and entry count in the table header are still used to reserve the entire > > table in memory, even though the resulting region is gigabytes in size. > > > > Given that the EFI Memory Attributes Table is supposed to carry up to 3 > > entries for each EfiRuntimeServicesCode region in the EFI memory map, > > and given that there is no reason for the descriptor size used in the > > table to exceed the one used in the EFI memory map, 3x the size of the > > entire EFI memory map is a reasonable upper bound for the size of this > > table. This means that sizes exceeding that are highly likely to be > > based on corrupted data, and the table should just be ignored instead. > > First of all, *thank you* for the quick fix. > My pleasure > A few questions/thoughts that are still bugging me. If you know the > answer for any, I would appreciate hearing from you. > > 1) This patch protects the kernel from a broken firmware. It has nothing > to do with the kernel code. The kernel is being a victim here. > Indeed. And this is arguably something I should have added at the time when support for this table was first added. > 2) The bug reported in [0], clearly found that the problem was likely > introduced by 2e6871a632a99d9b9e2ce3a7847acabe99e5a26e[1] from a cold > boot. How it might be related to > 2e6871a632a99d9b9e2ce3a7847acabe99e5a26e ? > To me, it does not seem related to the TPM event log handling at all. The only change made there is the memory type, and none of the other logic is modified. What seems more likely to me is that allocating pool memory of type 'ACPI reclaim' triggers a page allocation in this case, to add enough pages to the pool to satisfy the allocation request. Page allocations modify the EFI memory map, and therefore trigger an update of the EFI memory attributes table. What I suspect is that this firmware doesn't handle this very well when it happens late in the boot. It would be useful to boot the affected system with 'efi=debug' to get a look at the entire EFI memory map. > 3) Does having 2e6871a632a99d9b9e2ce3a7847acabe99e5a26e make the > firmware bug (EFI Memory Attribute Trable corruption) more visible by > any chance? > Exactly.
