[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211020192229.GP174703@worktop.programming.kicks-ass.net>
Date: Wed, 20 Oct 2021 21:22:29 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Josh Poimboeuf <jpoimboe@...hat.com>
Cc: Andrew Cooper <andrew.cooper3@...rix.com>, x86@...nel.org,
linux-kernel@...r.kernel.org, alexei.starovoitov@...il.com,
ndesaulniers@...gle.com
Subject: Re: [PATCH v2 08/14] x86/retpoline: Create a retpoline thunk array
On Wed, Oct 20, 2021 at 10:09:56AM -0700, Josh Poimboeuf wrote:
> On Wed, Oct 20, 2021 at 05:46:39PM +0100, Andrew Cooper wrote:
> > On 20/10/2021 16:57, Josh Poimboeuf wrote:
> > > On Wed, Oct 20, 2021 at 12:44:50PM +0200, Peter Zijlstra wrote:
> > >> Stick all the retpolines in a single symbol and have the individual
> > >> thunks as inner labels, this should guarantee thunk order and layout.
> > > How so?
> > >
> > > Just wondering what the purpose of the array is. It doesn't seem to be
> > > referenced anywhere.
> >
> > The array property is what makes:
> >
> > > + reg = (target - &__x86_indirect_thunk_rax) /
> > > + (&__x86_indirect_thunk_rcx - &__x86_indirect_thunk_rax);
> >
> > safe in the next path.
>
> The thunks were already 32-byte aligned. I don't see how slapping a few
> unused symbols around them does anything.
Previously there were 16 (or rather 15 without rsp) separate symbols and
a toolchain might reasonably expect it could displace them however it
liked, with disregard for the relative position.
However, now they're part of a larger symbol. Any change to their
relative position would disrupt this larger _array symbol and thus not
be sound.
This is I think the same reasoning used for data symbols. On their own
there is no guarantee about their relative position wrt to one aonther,
but we're still able to do arrays because an array as a whole is a
single larger symbol.
Powered by blists - more mailing lists