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

Reply via email to