On 3/5/19 17:38, Jan Beulich wrote: >>>> On 27.02.19 at 17:13, <nmant...@amazon.de> wrote: >> Speculative execution is not blocked in case one of the following >> properties is true: >> - path cannot be triggered by the guest >> - path does not return to the guest >> - path does not result in an out-of-bound access >> - path cannot be executed repeatedly >> Only the combination of the above properties allows to actually leak >> continuous chunks of memory. Therefore, we only add the penalty of >> protective mechanisms in case a potential speculative out-of-bound >> access matches all the above properties. > While this is all fine, how do I match which of the reasons applies to > which of (in particular) the gt_version checks left alone? As said, the > reasoning here should specifically be detailed so it can be used as a > guiding reference when adding further conditionals to the code down > the road. And of course review is (more) difficult this way as well, as > (judging from prior conversations) we don't seem to necessarily > agree in our views in all places, and hence to discuss a possibly > questionable decision others also need to understand which of the > criteria you considered to match in the specific case.
I listed the reasons to use above (and in the commit message). I will extend the commit message and give a reason for each version comparison, similarly to a prior email I sent. In my opinion, the commit message for fixing the problems we found in that file should not be a tutorial on how to identify and fix potential speculative out-of-bound accesses. While I agree that teaching more people how to judge whether a certain piece of code might lead to information leak via speculative execution, I would not use a commit message to get that covered. Best, Norbert > > Jan > > Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrer: Christian Schlaeger, Ralf Herbrich Ust-ID: DE 289 237 879 Eingetragen am Amtsgericht Charlottenburg HRB 149173 B _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel