linux-kernel - Re: [PATCH] x86/retpoline: Avoid return buffer underflows on context switch

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-next>] [day] [month] [year] [list]

Message-ID: <20180108222604.GW29822@worktop.programming.kicks-ass.net>
Date:   Mon, 8 Jan 2018 23:26:04 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     "Woodhouse, David" <dwmw@...zon.co.uk>
Cc:     "andi@...stfloor.org" <andi@...stfloor.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "tim.c.chen@...ux.intel.com" <tim.c.chen@...ux.intel.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "ak@...ux.intel.com" <ak@...ux.intel.com>,
        "pjt@...gle.com" <pjt@...gle.com>,
        "dave.hansen@...el.com" <dave.hansen@...el.com>,
        "luto@...capital.net" <luto@...capital.net>,
        "gregkh@...ux-foundation.org" <gregkh@...ux-foundation.org>
Subject: Re: [PATCH] x86/retpoline: Avoid return buffer underflows on context
 switch

On Mon, Jan 08, 2018 at 10:17:19PM +0000, Woodhouse, David wrote:
> On Mon, 2018-01-08 at 23:11 +0100, Peter Zijlstra wrote:
> > 
> > So pjt did alignment, a single unroll and per discussion earlier today
> > (CET) or late last night (PST), he only does 16.
> 
> Hey Intel, please tell us precisely how many RSB entries there are, on
> each family of CPU... :)

Right, and we can always fall back to 32 for unknown models.

> > Also, pause is unlikely to stop speculation, that comment doesn't make
> > sense. Looking at PJT's version there used to be a speculation trap in
> > there, but I can't see that here.
> 
> In this particular code we don't need a speculation trap; that's
> elsewhere. This one is *just* about the call stack. And the reason we
> don't just have...
> 
>  call . + 5
>  call . + 5
>  call . + 5
>  ...
> 
> is because that might get interpreted as a "push %rip" and not go on
> the RSB at all. Hence the 'pause' between each one.

OK, then make the comment say that.