linux-kernel - Re: [RFC PATCH 0/2] x86: Fix missing core serialization on migration

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: <617343212.13932.1510592207202.JavaMail.zimbra@efficios.com>
Date:   Mon, 13 Nov 2017 16:56:47 +0000 (UTC)
From:   Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Andy Lutomirski <luto@...nel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-api <linux-api@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
        Boqun Feng <boqun.feng@...il.com>,
        Andrew Hunter <ahh@...gle.com>,
        maged michael <maged.michael@...il.com>,
        Avi Kivity <avi@...lladb.com>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        Dave Watson <davejwatson@...com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Andrea Parri <parri.andrea@...il.com>,
        "Russell King, ARM Linux" <linux@...linux.org.uk>,
        Greg Hackmann <ghackmann@...gle.com>,
        Will Deacon <will.deacon@....com>,
        David Sehr <sehr@...gle.com>, x86 <x86@...nel.org>
Subject: Re: [RFC PATCH 0/2] x86: Fix missing core serialization on
 migration

----- On Nov 10, 2017, at 4:57 PM, Mathieu Desnoyers mathieu.desnoyers@...icios.com wrote:

> ----- On Nov 10, 2017, at 4:36 PM, Linus Torvalds torvalds@...ux-foundation.org
> wrote:
> 
>> On Fri, Nov 10, 2017 at 1:12 PM, Mathieu Desnoyers
>> <mathieu.desnoyers@...icios.com> wrote:
>>> x86 can return to user-space through sysexit and sysretq, which are not
>>> core serializing. This breaks expectations from user-space about
>>> sequential consistency from a single-threaded self-modifying program
>>> point of view in specific migration patterns.
>>>
>>> Feedback is welcome,
>> 
>> We should check with Intel. I would actually be surprised if the I$
>> can be out of sync with the D$ after a sysretq.  It would actually
>> break things like "read code from disk" too in theory.
> 
> That core serializing instruction is not that much about I$ vs D$
> consistency, but rather about the processor speculatively executing code
> ahead of its retirement point. Ref. Intel Architecture Software Developer's
> Manual, Volume 3: System Programming.
> 
> 7.1.3. "Handling Self- and Cross-Modifying Code":
> 
> "The act of a processor writing data into a currently executing code segment
> with the intent of
> executing that data as code is called self-modifying code. Intel Architecture
> processors exhibit
> model-specific behavior when executing self-modified code, depending upon how
> far ahead of
> the current execution pointer the code has been modified. As processor
> architectures become
> more complex and start to speculatively execute code ahead of the retirement
> point (as in the P6
> family processors), the rules regarding which code should execute, pre- or
> post-modification,
> become blurred. [...]"
> 
> AFAIU, this core serializing instruction seems to be needed for use-cases of
> self-modifying code, but not for the initial load of a program from disk,
> as the processor has no way to have speculatively executed any of its
> instructions.

I figured out what you're pointing to: if exec() is executed by a previously
running thread, and there is no core serializing instruction between program
load and return to user-space, the kernel ends up acting like a JIT, indeed.

Therefore, we'd also need to invoke sync_core_before_usermode() after loading
the program.

Let's wait to hear back from hpa,

Thanks,

Mathieu


> 
> Hopefully hpa can tell us more about this,
> 
> Thanks,
> 
> Mathieu
> 
> 
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com