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: Tue, 11 Jun 2024 13:15:43 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Rasmus Villemoes <linux@...musvillemoes.dk>,
        Peter Zijlstra <peterz@...radead.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>
CC: Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...en8.de>,
        Thomas Gleixner <tglx@...utronix.de>,
        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 June 11, 2024 12:43:02 PM PDT, "H. Peter Anvin" <hpa@...or.com> wrote:
>On 6/10/24 06:38, Rasmus Villemoes wrote:
>> On 10/06/2024 12.43, Peter Zijlstra wrote:
>>> On Sat, Jun 08, 2024 at 12:35:05PM -0700, Linus Torvalds wrote:
>> 
>>>> Comments?
>>> 
>>> It obviously has the constraint of never running the code before the
>>> corresponding runtime_const_init() has been done, otherwise things will
>>> go sideways in a hurry, but this also makes the whole thing a *lot*
>>> simpler.
>>> 
>>> The only thing I'm not sure about is it having a section per symbol,
>>> given how jump_label and static_call took off, this might not be
>>> scalable.
>>> 
>>> Yes, the approach is super simple and straight forward, but imagine
>>> there being like a 100 symbols soon :/
>>> 
>>> The below hackery -- it very much needs cleanup and is only compiled on
>>> x86_64 and does not support modules, boots for me.
>> 
>> As can be seen in my other reply, yes, I'm also worried about the
>> scalability and would like to see this applied to more stuff.
>> 
>> But if we do this, surely that's what scripts/sorttable is for, right?
>> 
>> Alternatively, if we just keep emitting to per-symbol
>> __runtime_const_##sym sections but collect them in one __runtime_const,
>> just using __runtime_const { *(SORT_BY_NAME(__runtime_const_*)) } in the
>> linker script should already be enough to allow that binary search to
>> work (with whatever : AT(ADDR() ... ) magic is also required), with no
>> post-processing at build or runtime required.
>> 
>
>As far as one section per symbol, this is *exactly* what the linker table infrastructure was intended to make clean and scalable.
>
>I think rejecting it was a big mistake. It is really a very useful general piece of infrastructure, and IMNSHO the whole notion of "oh, we won't ever need that many such tables" is just plain wrong (as evidenced here.)
>
>Either way, the problem isn't that hard; you end up doing something like:
>
>struct runtime_const {
>	unsigned int size;
>	reladdr_t entries[0];
>};
>
>#define DECLARE_RUNTIME_CONST(sym,type) \
>extern struct runtime_const sym;\
>asm(".pushsection \"runtime_const_" #sym ".Start\",\"a\"\n\t"
>    ".globl " #sym "\n"
>    #sym ": .int 2f - 1f\n\t"
>    "1:\n"
>    ".popsection\n\t"
>    ".pushsection \"runtime_const_" #sym "._end\",\"a\"\n\t"
>    "2:\n"
>    ".popsection\n\t");
>
>... and add a common suffix, say, ".entry", for the entry section names. Then SORT_BY_NAME() will handle the rest.
>
>	-hpa
>

Ok, the section naming is obviously bogus, but...

I just had an idea how to clearly make this type-safe as a benefit. I'm at a school event right now but I'll hack up a demo as soon as I get home.