linux-kernel - Re: [RFC PATCH 2/7] static_call: deal with unexported keys without cluttering up the API

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: <YYrO4/S7tfr7P5YA@hirez.programming.kicks-ass.net>
Date:   Tue, 9 Nov 2021 20:41:23 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Ard Biesheuvel <ardb@...nel.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Jason Baron <jbaron@...mai.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Mark Rutland <mark.rutland@....com>,
        Kees Cook <keescook@...omium.org>
Subject: Re: [RFC PATCH 2/7] static_call: deal with unexported keys without
 cluttering up the API

On Tue, Nov 09, 2021 at 07:53:33PM +0100, Ard Biesheuvel wrote:
> On Tue, 9 Nov 2021 at 19:49, Peter Zijlstra <peterz@...radead.org> wrote:
> >
> > On Tue, Nov 09, 2021 at 05:45:44PM +0100, Ard Biesheuvel wrote:
> >
> > > diff --git a/include/linux/static_call_types.h b/include/linux/static_call_types.h
> > > index 5a00b8b2cf9f..0bb36294cce7 100644
> > > --- a/include/linux/static_call_types.h
> > > +++ b/include/linux/static_call_types.h
> > > @@ -32,15 +32,20 @@
> > >  struct static_call_site {
> > >       s32 addr;
> > >       s32 key;
> > > +     s32 tramp;
> > >  };
> >
> > I can't say I'm thrilled at growing this thing, but the cleanup is nice.
> > Perhaps we can increase alignment on struct static_call_key and instead
> > frob it in .key still?
> >
> 
> This is already a place-relative field, and one points into the data
> section and the other into text. So I don't see how we can squeeze
> enough bits out of it to make this fit.

Well, the actual address will be:

	((unsigned long)&site->key + site->key)

either way around, right? Now, if we align struct static_call_key to 8,
that means the low 3 bits of that address will be 0 and free for us to
muck about with.

That is, we already use the low 2 bits of that (because natural
alignment etc.).

If we got 3 bits, we could shift the existing two bits one up and free
up bit0, then say that if bit0 is set, it's a trampoline address. The
only additional requirement would be that trampolines are (at least)
aligned 2 (they're at 4 currently).

Except.... it would be the linker having to create that field, and
there's no way that thing is smart like that :-( Ooh well.