----- On Nov 14, 2017, at 12:03 PM, Avi Kivity avi@xxxxxxxxxxxx wrote: > On 11/14/2017 06:49 PM, Mathieu Desnoyers wrote: >> ----- On Nov 14, 2017, at 11:08 AM, Peter Zijlstra peterz@xxxxxxxxxxxxx wrote: >> >>> On Tue, Nov 14, 2017 at 05:05:41PM +0100, Peter Zijlstra wrote: >>>> On Tue, Nov 14, 2017 at 03:17:12PM +0000, Mathieu Desnoyers wrote: >>>>> I've tried to create a small single-threaded self-modifying loop in >>>>> user-space to trigger a trace cache or speculative execution quirk, >>>>> but I have not succeeded yet. I suspect that I would need to know >>>>> more about the internals of the processor architecture to create the >>>>> right stalls that would allow speculative execution to move further >>>>> ahead, and trigger an incoherent execution flow. Ideas on how to >>>>> trigger this would be welcome. >>>> I thought the whole problem was per definition multi-threaded. >>>> >>>> Single-threaded stuff can't get out of sync with itself; you'll always >>>> observe your own stores. >>> And even if you could, you can always execute a local serializing >>> instruction like CPUID to force things. >> What I'm trying to reproduce is something that breaks in single-threaded >> case if I explicitly leave out the CPUID core serializing instruction >> when doing code modification on upcoming code, in a loop. >> >> AFAIU, Intel requires a core serializing instruction to be issued even >> in single-threaded scenarios between code update and execution, to ensure >> that speculative execution does not observe incoherent code. Now the >> question we all have for Intel is: is this requirement too strong, or >> required by reality ? >> > > In single-threaded execution, a jump is enough. > > "As processor microarchitectures become more complex and start to > speculatively execute code ahead of the retire- > ment point (as in P6 and more recent processor families), the rules > regarding which code should execute, pre- or > post-modification, become blurred. To write self-modifying code and > ensure that it is compliant with current and > future versions of the IA-32 architectures, use one of the following > coding options: > > (* OPTION 1 *) > Store modified code (as data) into code segment; > Jump to new code or an intermediate location; > Execute new code;" Good point, so this is likely why I was having trouble reproducing the single-threaded self-modifying code incoherent case. I did have a branch in there. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
