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

Message-ID: <CAMj1kXFSae=stazUv8doka-zLOnDdXXR4ASxHKe5f97ikg3V2A@mail.gmail.com>
Date: Tue, 6 May 2025 18:34:50 +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 18:23, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Tue, 6 May 2025 at 08:49, Ard Biesheuvel <ardb+git@...gle.com> wrote:
> >
> > +       asm_inline(ALTERNATIVE_TERNARY("jmp 6f; 8:", %c[feat], "movl %[yes], %[ret]", "")
> > +               "       .pushsection .altinstr_aux,\"ax\"       \n"
> > +               "6:     pushfq                                  \n"
> > +               "       testb   $1, %a[l5en]                    \n"
> > +               "       jz      7f                              \n"
> > +               "       movl    %[yes], %[ret]                  \n"
> > +               "7:     popfq                                   \n"
> > +               "       jmp     8b                              \n"
> > +               "       .popsection                             \n"
> > +               : [ret]  "+rm" (ret)
> > +               : [feat] "i" (X86_FEATURE_LA57),
> > +                 [yes]  "i" (yes),
> > +                 [l5en] "i" (&__pgtable_l5_enabled));
>
> I really detest these things. I don't think it's worth the complexity.
> Is there really such a hot path somewhere that we should do something
> like this?
>

Not sure - Ingo's data only tells us how often these occur in the
code, not how often they are called.

The only constant that I know is likely to be hot is
KASAN_SHADOW_START, but that only matters when KASAN is enabled so I'm
not sure that matters.

For the remaining uses, I would assume that manipulations of PGD/P4D
level entries [where the 4-level/5-level distinction matters] are
extremely rare compared to lower level ones, so I wouldn't expect any
bottlenecks there.

> If we can't use some existing infrastructure for this, we should just
> keep it simple. Not write ten lines of specialized inline asm.
>

Fair enough - I'm not particularly attached to this, and I'm generally
averse to premature optimization. I was just addressing the concerns
raised by Ingo.

I think the first two patches are important, though, as they are about
robustness/consistency rather than optimization.