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: <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

Powered by Openwall GNU/*/Linux Powered by OpenVZ