Re: [Xen-devel] [PATCH L1TF v9 7/7] common/grant_table: block speculative out-of-bound accesses

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.03.19 at 11:36, <nmanthey@xxxxxxxxx> wrote:
> On 3/5/19 17:38, Jan Beulich wrote:
>>>>> On 27.02.19 at 17:13, <nmanthey@xxxxxxxxx> 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.

And that also wasn't my line of argumentation. All I'm after is as good
of a guideline as possible for how to deal with future new version
dependent code in grant_table.c.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel