linux-kernel - Re: [PATCH v2 5/8] x86/speculation: Add basic support for IBPB

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]

Date:   Sun, 21 Jan 2018 21:17:53 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     David Woodhouse <dwmw2@...radead.org>
Cc:     arjan@...ux.intel.com, tglx@...utronix.de, karahmed@...zon.de,
        x86@...nel.org, linux-kernel@...r.kernel.org,
        tim.c.chen@...ux.intel.com, peterz@...radead.org,
        pbonzini@...hat.com, ak@...ux.intel.com,
        torvalds@...ux-foundation.org, gregkh@...ux-foundation.org
Subject: Re: [PATCH v2 5/8] x86/speculation: Add basic support for IBPB

On Sun, Jan 21, 2018 at 08:07:06PM +0000, David Woodhouse wrote:
> That bug is the *reason* we're arguing about static_cpu_has vs.
> ALTERNATIVE. 
> 
> A conditional branch that the CPU sees can be speculated over...

Lemme see if I understand it correctly: you don't want to have any such
constructs:

	 testb $1,boot_cpu_data+50(%rip)	#, MEM[(const char *)&boot_cpu_data + 50B]
	 jnz .L707	#

which could cause any speculation.

Instead, you want to have unconditional code which is slapped in by
alternatives.

Oh, and you don't want to have that at privilege crossing sites, like
VMEXIT or so.

Am I close?

> Now, Andrew is right that in a number of cases there will be another
> serialising instruction before we ever hit a problematic indirect
> branch. But as I just said elsewhere, I'd really like the *primitives*
> to support unconditional operation.

In this particular case, WRMSR is already serializing too. So it is hard
to exploit stuff here :-)

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.