linux-kernel - Re: [PATCH 4/9] x86/alternative: Implement .retpoline

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: <20211013215217.pjs53a65reicn72d@treble>
Date:   Wed, 13 Oct 2021 14:52:17 -0700
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     x86@...nel.org, andrew.cooper3@...rix.com,
        linux-kernel@...r.kernel.org, alexei.starovoitov@...il.com,
        ndesaulniers@...gle.com
Subject: Re: [PATCH 4/9] x86/alternative: Implement .retpoline_sites support

On Wed, Oct 13, 2021 at 02:49:10PM -0700, Josh Poimboeuf wrote:
> On Wed, Oct 13, 2021 at 11:20:02PM +0200, Peter Zijlstra wrote:
> > On Wed, Oct 13, 2021 at 01:39:27PM -0700, Josh Poimboeuf wrote:
> > > On Wed, Oct 13, 2021 at 02:22:21PM +0200, Peter Zijlstra wrote:
> > > > +static int patch_retpoline(void *addr, struct insn *insn, u8 *bytes)
> > > > +{
> > > > +	void (*target)(void);
> > > > +	int reg, i = 0;
> > > > +
> > > > +	if (cpu_feature_enabled(X86_FEATURE_RETPOLINE))
> > > > +		return -1;
> > > 
> > > Better to do this check further up the call stack in apply_retpolines()
> > > before looping through all the call sites?
> > 
> > In fact, I've pushed it further down, in order to always validate the
> > absense of rsp.
> > 
> > > > +
> > > > +	target = addr + insn->length + insn->immediate.value;
> > > > +	reg = (target - &__x86_indirect_thunk_rax) /
> > > > +	      (&__x86_indirect_thunk_rcx - &__x86_indirect_thunk_rax);
> > > > +
> > > > +	if (WARN_ON_ONCE(reg & ~0xf))
> > > > +		return -1;
> > > 
> > > It would be more robust and less magical to just have a basic lookup
> > > table array which converts a thunk address to a reg.  Then you can just
> > > avoid all the safety checks because it's no longer insane ;-)
> > 
> > Andrew suggested the reverse lookup to validate. That should give the
> > same robustness but lacks the linear lookup.
> 
> So you've got a WARN_ON_ONCE, a BUG_ON, and a too-deep feature check,
> all in the name of supporting this scheme.  ok...

Not to mention the extra silly rsp thunks...

> If performance of the linear lookup were a real concern then you could
> just put rax and r11 at the beginning of the array.

-- 
Josh