Hi Vashti, Generally, the behavior of LFENCE isn't very well defined by the ISA.
>From https://www.felixcloutier.com/x86/lfence: "Processors are free to fetch and cache data speculatively from regions of system memory that use the WB, WC, and WT memory types. This speculative fetching can occur at any time and is not tied to instruction execution. Thus, it is not ordered with respect to executions of the LFENCE instruction; data can be brought into the caches speculatively just before, during, or after the execution of an LFENCE instruction." The way I read that is that LFENCE actually won't protect against spectre. However, IIRC, this isn't how it's implemented on current system (it *does* protect against spectre on Intel and AMD processors). Here's gem5's implementation: https://gem5.googlesource.com/public/gem5/+/master/src/arch/x86/isa/decoder/two_byte_opcodes.isa#787 This is simply a "read barrier". I believe that this is a nop in the O3CPU when using TSO (as it should be since all loads are ordered anyway in TSO). >From my understanding, the speculation semantics aren't specified in the ISA, so it's up to the implementation what to do in these cases. That said, it looks like someone has a patch on gerrit to change this behavior: https://gem5-review.googlesource.com/c/public/gem5/+/10321. I'll go ahead and submit that changeset as I think it's more representative of current systems. Hopefully this helps. Let me know if you have more questions! Cheers, Jason On Tue, Oct 15, 2019 at 2:29 AM <[email protected]> wrote: > Dear gem5 users, and in particular Jason Lowe-Power, > > I read with interest the blog post by Jason about Visualizing Spectre with > gem5: > http://www.lowepower.com/jason/visualizing-spectre-with-gem5.html > > I then investigated visualising what happens when fences are added. I > modified the code, adding _mm_lfence or _mm_mfence in the victim function > > void victim_function(size_t x) { > if (x < array1_size) { > > FENCE ADDED HERE > > temp &= array2[array1[x] * 512]; > } > } > > > Running both modifications natively resulted in no leakage of the secret > (although that does not prove that no leakage is possible with the right > tweaking of parameters). > > However, running in gem5 > > build/X86/gem5.opt configs/learning_gem5/part1/two_level.py spectre > > using the modifications to two_level.py described in the blog, there was > no leakage using mfence but the secret was leaked using lfence. > > Does anyone have an idea of why this is happening? Output from the O3 > pipeline viewer shows that the fetch of the fence instruction is delayed in > the one case and not the other (I haven’t included screenshots due to > message size restrictions of the list but I can supply them in separate > messages if requested). > Potential causes are > - some misunderstanding on my part > - incorrect implementation of lfence in gem5 > - two_level.py may be too simplistic for investigating fences > > Thanking you in advance > Vashti > > > ---------------------------------------------- > Vashti Galpin > Laboratory for Foundations of Computer Science > School of Informatics, University of Edinburgh > ---------------------------------------------- > > The University of Edinburgh is a charitable body, > registered in Scotland, with registration number SC005336. > > > > > ---------------------------------------------- > Vashti Galpin > Laboratory for Foundations of Computer Science > School of Informatics, University of Edinburgh > ---------------------------------------------- > > The University of Edinburgh is a charitable body, > registered in Scotland, with registration number SC005336. > > > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
