linux-kernel - Re: [RFC PATCH 3/3] x86/boot: Use alternatives based selector for 5-level paging constants

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] [day] [month] [year] [list]

Message-ID: <CAMj1kXEJ_SzoYaEEMq32Er5Ro6kOEg0Z_mk0MEeOh6wNX5mqoA@mail.gmail.com>
Date: Wed, 7 May 2025 15:51:07 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Ard Biesheuvel <ardb+git@...gle.com>, linux-kernel@...r.kernel.org, x86@...nel.org, 
	Ingo Molnar <mingo@...nel.org>
Subject: Re: [RFC PATCH 3/3] x86/boot: Use alternatives based selector for
 5-level paging constants

On Tue, 6 May 2025 at 21:50, Ard Biesheuvel <ardb@...nel.org> wrote:
>
> On Tue, 6 May 2025 at 21:42, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> >
> > On Tue, 6 May 2025 at 12:15, Ard Biesheuvel <ardb@...nel.org> wrote:
> > >
> > > First of all, that would mean calling into even more C code from the
> > > 1:1 mapping of memory,
> >
> > Not a lot, actually.
> >
> > When I did the runtime-const stuff, I refused to use the alternatives
> > code, because it was called much too late and was much too
> > complicated.
> >
> > So I just did an early fixup by hand - in the place where the variable
> > was actually changed. Exactly so that you had *consistency*.
> >
> > It's literally four lines of code that gets inlined.
> >
> > See runtime_const_fixup().
> >
> > And I just checked. Those four lines of code generate seven *instructions*:
> >
> >   .LBB80_4:
> >         movq    $__start_runtime_ptr_dentry_hashtable, %rcx
> >   .LBB80_6:                               # =>This Inner Loop Header: Depth=1
> >         cmpq    $__stop_runtime_ptr_dentry_hashtable, %rcx
> >         jae     .LBB80_7
> >   # %bb.5:                                #   in Loop: Header=BB80_6 Depth=1
> >         movslq  (%rcx), %rdx
> >         movq    %rax, (%rcx,%rdx)
> >         addq    $4, %rcx
> >         jmp     .LBB80_6
> >
> > that's literally what that
> >
> >         runtime_const_init(ptr, dentry_hashtable);
> >
> > generates in dcache_init_early() for me.
> >
> > Seriously, this is *trivial*.
> >
>
> This looks trivial, yes - I thought you were talking about the
> alternatives patching code, which seems rather complex, and either
> pulling it into the startup code or writing an 'early' version of it
> seem like a lot of work for little gain.
>
> So yes, let's use this from the startup code, once we figure out which
> of these constants are too costly to be expressed as
> 'pgtable_l5_enabled() ? foo : bar'

OK, after digging a bit deeper, it seems that runtime constants are
not going to be usable here.

First of all, the constants

page_offset_base
vmalloc_base
vmemmap_base

have their address taken in the KASLR memory randomization code, which
subsequently overwrites them with different values.

This means that runtime constants are not usable here. It also means
that there is no need whatsoever to assign these variables extremely
early, given that they may assume different values during the
execution of setup_arch().

That leaves

pgdir_shift
ptrs_per_p4d

which are both 'int', and while looking into adding runtime const
support for the 'int' type, I noticed that it doesn't appear to
support loadable modules? This is a problem because these variables
are exported.

So, in order to get rid of USE_EARLY_PGTABLE_L5, which is how this
discussion started to begin with, I suggest we go with an approach
that just redefines references to these two variables in terms of
pgtable_l5_enabled()?l5_val:l4_val, as I proposed originally. Then, I
can try to make cpu_feature_enabled() usable from early boot onwards
so we can drop the early variant of pgtable_l5_enabled().

If any of these variables turn out to be a bottleneck in practice, we
can revisit.