linux-kernel - Re: [RFC 2/2] efi/memattr: add efi_mem_attr_table as a reserved region in 820_table

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: <CAMj1kXFjJZKGS1VDcUw3Uw9xB0R5+Q3q-21hojw4NMbr__XmgA@mail.gmail.com>
Date: Fri, 10 Jan 2025 18:33:27 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Breno Leitao <leitao@...ian.org>
Cc: Usama Arif <usamaarif642@...il.com>, linux-efi@...r.kernel.org, devel@...2.groups.io, 
	kexec@...ts.infradead.org, hannes@...xchg.org, dyoung@...hat.com, 
	x86@...nel.org, linux-kernel@...r.kernel.org, gourry@...rry.net, 
	kernel-team@...a.com
Subject: Re: [RFC 2/2] efi/memattr: add efi_mem_attr_table as a reserved
 region in 820_table_firmware

On Fri, 10 Jan 2025 at 12:36, Breno Leitao <leitao@...ian.org> wrote:
>
> Hello Ard,
>
> On Fri, Jan 10, 2025 at 08:32:08AM +0100, Ard Biesheuvel wrote:
> > On Thu, 9 Jan 2025 at 17:32, Usama Arif <usamaarif642@...il.com> wrote:
>
> > > I think in the end whoevers' responsibility it is, the easiest path forward
> > > seems to be in kernel? (and not firmware or libstub)
> > >
> >
> > Agreed. But as I pointed out in the other thread, the memory
> > attributes table only augments the memory map with permission
> > information, and can be disregarded, and given how badly we mangle the
> > memory map on x86, maybe this is the right choice here.
>
> If this augmented memory is not preserved accross kexec, then the next
> kexec'ed kernel will be able to find the original table?
>
> I understand that the memattr region(s) need to be always (in each kexec
> instances) `memblocked_reserved` to protect it from being used as a
> System RAM, right?
>
> Thus, if it is not passed throught e820, kexec'ed kernel needs to fetch
> it again from original EFI table at kexec/boot time.
>

Not sure what 'fetching' means here.

> This brings me another question.
>
> If the kexec'ed kernel sees the original memory, why can't it
> augment/update the RX permissions *again*, instead of passing the
> previous augmented version from previous kernel in this crazy dance.
>

I don't understand what original memory means. I think we're talking
past each other tbh.

> > This is a kexec problem (on x86 only) so let's fix it there.
>
> Would you mind explaining what kexec needs to be done differently?
> Should it preserve the augmented memattr table independently if it is
> mapped in e820?
>

I don't know what 'mapped in e820' means.

Let's forget about what the memory attributes table actually contains,
and just assume we can live without it, ok?

So when booting x86 via kexec (which is already detected in
arch/x86/platform/efi/efi.c), the kernel should pretend that the table
does not exist.