From: Ard Biesheuvel <ardb@kernel.org>
To: Arvind Sankar <nivedita@alum.mit.edu>
Cc: Borislav Petkov <bp@alien8.de>, Arnd Bergmann <arnd@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, X86 ML <x86@kernel.org>,
Nathan Chancellor <natechancellor@gmail.com>,
Nick Desaulniers <ndesaulniers@google.com>,
Arnd Bergmann <arnd@arndb.de>, Darren Hart <dvhart@infradead.org>,
Andy Shevchenko <andy@infradead.org>,
"H. Peter Anvin" <hpa@zytor.com>,
linux-efi <linux-efi@vger.kernel.org>,
platform-driver-x86@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
clang-built-linux <clang-built-linux@googlegroups.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [PATCH] x86: efi: avoid BUILD_BUG_ON() for non-constant p4d_index
Date: Wed, 20 Jan 2021 10:33:43 +0100 [thread overview]
Message-ID: <CAMj1kXHM98-iDYpAozaWEv-qxhZ0-CUMwSdG532x2d+55gXDhQ@mail.gmail.com> (raw)
In-Reply-To: <YAYAvBARSRSg8z8G@rani.riverdale.lan>
On Mon, 18 Jan 2021 at 22:42, Arvind Sankar <nivedita@alum.mit.edu> wrote:
>
> On Mon, Jan 18, 2021 at 09:24:09PM +0100, Borislav Petkov wrote:
> > > > > As a matter of fact, it seems like the four assertions could be combined
> > > > > into:
> > > > > BUILD_BUG_ON((EFI_VA_END & P4D_MASK) != (MODULES_END & P4D_MASK));
> > > > > BUILD_BUG_ON((EFI_VA_START & P4D_MASK) != (EFI_VA_END & P4D_MASK));
> > > > > instead of separately asserting they're the same PGD entry and the same
> > > > > P4D entry.
> > > > >
> > > > > Thanks.
> > > >
> > > > I actually don't quite get the MODULES_END check -- Ard, do you know
> > > > what that's for?
> > > >
> > >
> > > Maybe Boris remembers? He wrote the original code for the 'new' EFI
> > > page table layout.
> >
> > That was added by Kirill for 5-level pgtables:
> >
> > e981316f5604 ("x86/efi: Add 5-level paging support")
>
> That just duplicates the existing pgd_index() check for the p4d_index()
> as well. It looks like the original commit adding
> efi_sync_low_kernel_mappings() used to copy upto the PGD entry including
> MODULES_END:
> d2f7cbe7b26a7 ("x86/efi: Runtime services virtual mapping")
> and then Matt changed that when creating efi_mm:
> 67a9108ed4313 ("x86/efi: Build our own page table structures")
> to use EFI_VA_END instead but have a check that EFI_VA_END is in the
> same entry as MODULES_END.
>
> AFAICT, MODULES_END is only relevant as being something that happens to
> be in the top 512GiB, and -1ul would be clearer.
>
> >
> > Documentation/x86/x86_64/mm.rst should explain the pagetable layout:
> >
> > ffffff8000000000 | -512 GB | ffffffeeffffffff | 444 GB | ... unused hole
> > ffffffef00000000 | -68 GB | fffffffeffffffff | 64 GB | EFI region mapping space
> > ffffffff00000000 | -4 GB | ffffffff7fffffff | 2 GB | ... unused hole
> > ffffffff80000000 | -2 GB | ffffffff9fffffff | 512 MB | kernel text mapping, mapped to physical address 0
> > ffffffff80000000 |-2048 MB | | |
> > ffffffffa0000000 |-1536 MB | fffffffffeffffff | 1520 MB | module mapping space
> > ffffffffff000000 | -16 MB | | |
> > FIXADDR_START | ~-11 MB | ffffffffff5fffff | ~0.5 MB | kernel-internal fixmap range, variable size and offset
> >
> > That thing which starts at -512 GB above is the last PGD on the
> > pagetable. In it, between -4G and -68G there are 64G which are the EFI
> > region mapping space for runtime services.
> >
> > Frankly I'm not sure what this thing is testing because the EFI VA range
> > is hardcoded and I can't imagine it being somewhere else *except* in the
> > last PGD.
>
> It's just so that someone doesn't just change the #define's for
> EFI_VA_END/START and think that it will work, I guess.
>
> Another reasonable option, for example, would be to reserve an entire
> PGD entry, allowing everything but the PGD level to be shared, and
> adding the EFI PGD to the pgd_list and getting rid of
> efi_sync_low_kernel_mappings() altogether. There aren't that many PGD
> entries still unused though, so this is probably not worth it.
>
The churn doesn't seem to be worth it, tbh.
So could we get rid of the complexity here, and only build_bug() on
the start address of the EFI region being outside the topmost p4d?
That should make the PGD test redundant as well.
next prev parent reply other threads:[~2021-01-20 11:08 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-07 22:34 [PATCH] x86: efi: avoid BUILD_BUG_ON() for non-constant p4d_index Arnd Bergmann
2021-01-07 22:42 ` Nathan Chancellor
2021-01-13 17:51 ` Ard Biesheuvel
2021-01-15 18:23 ` Borislav Petkov
2021-01-15 18:32 ` Nathan Chancellor
2021-01-15 19:07 ` Borislav Petkov
2021-01-15 19:11 ` Arvind Sankar
2021-01-15 19:18 ` Borislav Petkov
2021-01-15 19:54 ` Arnd Bergmann
2021-01-15 20:12 ` Arvind Sankar
2021-01-15 20:32 ` Arvind Sankar
2021-01-15 19:07 ` Arvind Sankar
2021-01-15 20:27 ` Arvind Sankar
2021-01-16 16:34 ` Ard Biesheuvel
2021-01-18 20:24 ` Borislav Petkov
2021-01-18 21:42 ` Arvind Sankar
2021-01-20 9:33 ` Ard Biesheuvel [this message]
2021-01-20 11:44 ` Borislav Petkov
2021-02-03 18:51 ` Nathan Chancellor
2021-02-03 20:29 ` Ard Biesheuvel
2021-02-04 10:51 ` Borislav Petkov
2021-02-04 10:59 ` Ard Biesheuvel
2021-02-04 19:16 ` Nathan Chancellor
2021-02-04 21:43 ` Arvind Sankar
2021-02-04 22:13 ` Borislav Petkov
2021-02-05 0:08 ` Arvind Sankar
2021-02-05 11:39 ` [PATCH] x86/efi: Remove EFI PGD build time checks Borislav Petkov
2021-02-05 11:57 ` Ard Biesheuvel
2021-02-05 18:14 ` Nick Desaulniers
2021-02-05 18:56 ` Nathan Chancellor
2021-02-05 10:34 ` [PATCH] x86: efi: avoid BUILD_BUG_ON() for non-constant p4d_index Borislav Petkov
2021-02-05 18:27 ` Nick Desaulniers
2021-02-05 18:31 ` Nathan Chancellor
2021-01-20 11:26 ` Kirill A. Shutemov
2021-01-20 11:06 ` Kirill A. Shutemov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMj1kXHM98-iDYpAozaWEv-qxhZ0-CUMwSdG532x2d+55gXDhQ@mail.gmail.com \
--to=ardb@kernel.org \
--cc=andy@infradead.org \
--cc=arnd@arndb.de \
--cc=arnd@kernel.org \
--cc=bp@alien8.de \
--cc=clang-built-linux@googlegroups.com \
--cc=dvhart@infradead.org \
--cc=hpa@zytor.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=natechancellor@gmail.com \
--cc=ndesaulniers@google.com \
--cc=nivedita@alum.mit.edu \
--cc=platform-driver-x86@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).