linux-kernel - Re: [PATCH] x86: add 'runtime constant' infrastructure

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]

Date: Sun, 9 Jun 2024 08:47:33 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Borislav Petkov <bp@...en8.de>, Ingo Molnar <mingo@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, 
	Rasmus Villemoes <linux@...musvillemoes.dk>, Josh Poimboeuf <jpoimboe@...nel.org>, 
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, "the arch/x86 maintainers" <x86@...nel.org>, 
	linux-arch <linux-arch@...r.kernel.org>
Subject: Re: [PATCH] x86: add 'runtime constant' infrastructure

On Sun, 9 Jun 2024 at 04:48, H. Peter Anvin <hpa@...or.com> wrote:
>
> So the biggest difference versus what I had in progress was that I had
> the idea of basically doing "ro_after_init" behavior by doing memory
> references until alternatives are run.

Yeah, that would make it a lot more complicated, because now you need
to replace the whole asm, and you need to write it in a way that it
can be replaced with alternate code.

It's a bit akin to what Rasmus' RAI code did, but while I liked
Rasmus' patch,  I honestly don't think there is any advantage to
having that "load from memory" alternate version.

At least for something like the dcache lookup, the "before things have
been initialized" state is that the runtime constant pointer is NULL,
so the pre-init code would cause an oops anyway, even if it had that
"load from memory" fallback.

Now, there may be other uses for these kinds of runtime constants, but
I do think the main one - and the one I wrote this for - is simply a
boot-time allocation. So I think that kind of "before it's
initialized, it won't work whether there's a load from memory or not"
is fairly fundamental.

There are other constants this could be used for - particularly things
like "size of virtual memory". That

  #define task_size_max() \
         ((_AC(1,UL) << __VIRTUAL_MASK_SHIFT) - PAGE_SIZE)

thing really used to be a big pain back when we used it in every
get_user/put_user call. We replaced it with just the sign bit test,
though, and now it's gone.

(I still see it in profiles in strncpy_from_user(), but it's not
really noticeable, and it's fixable using a similar address masking
thing).

I'd expect that there are other cases than the dcache lookup that
wants this, but none that really show up on any of the profiles _I_
tend to run (but I don't benchmark networking, for example).

There is the security layer blob_sizes "constants" that could possibly
use this, but a part of the cost there is that since they aren't
compile-time constants, the compiler can't just use a common base
pointer.

So even if those were converted to runtime constants, it wouldn't make
the code generation all _that_ much better.

                    Linus