linux-kernel - Re: [PATCH v3 5/6] x86/alternative: Use a single access in text

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:   Thu, 10 Jan 2019 12:57:57 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Sean Christopherson <sean.j.christopherson@...el.com>
Cc:     Josh Poimboeuf <jpoimboe@...hat.com>,
        Nadav Amit <namit@...are.com>, X86 ML <x86@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Andy Lutomirski <luto@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Jason Baron <jbaron@...mai.com>, Jiri Kosina <jkosina@...e.cz>,
        David Laight <David.Laight@...LAB.COM>,
        Borislav Petkov <bp@...en8.de>,
        Julia Cartwright <julia@...com>, Jessica Yu <jeyu@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Edward Cree <ecree@...arflare.com>,
        Daniel Bristot de Oliveira <bristot@...hat.com>
Subject: Re: [PATCH v3 5/6] x86/alternative: Use a single access in
 text_poke() where possible

On Thu, 10 Jan 2019 09:42:57 -0800
Sean Christopherson <sean.j.christopherson@...el.com> wrote:

> On Thu, Jan 10, 2019 at 12:32:43PM -0500, Steven Rostedt wrote:
> > On Thu, 10 Jan 2019 11:20:04 -0600
> > Josh Poimboeuf <jpoimboe@...hat.com> wrote:
> > 
> >   
> > > > While I can't find a reason for hypervisors to emulate this instruction,
> > > > smarter people might find ways to turn it into a security exploit.    
> > > 
> > > Interesting point... but I wonder if it's a realistic concern.  BTW,
> > > text_poke_bp() also relies on undocumented behavior.  
> > 
> > But we did get an official OK from Intel that it will work. Took a bit
> > of arm twisting to get them to do so, but they did. And it really is
> > pretty robust.  
> 
> Did we (they?) list any caveats for this behavior?  E.g. I'm fairly
> certain atomicity guarantees go out the window if WC memtype is used.

Note, the text_poke_bp() process was this: (nothing to do with atomic
guarantees)

add breakpoint (one byte) to instruction.

Sync all cores (send an IPI to each one).

change the back half of the instruction (the rest of the instruction
after the breakpoint).

Sync all cores

Remove the breakpoint with the new byte of the new instruction.


What atomicity guarantee does the above require?

-- Steve