Re: [Xen-devel] [PATCH L1TF MDS GT v2 1/2] common/grant_table: harden bound accesses

[Jan Beulich <JBeulich@xxxxxxxx>]

On 12.07.2019 10:40, Norbert Manthey wrote:
> On 7/11/19 14:34, Jan Beulich wrote:
>> On 10.07.2019 14:54, Norbert Manthey wrote:
>>> Guests can issue grant table operations and provide guest controlled
>>> data to them. This data is used as index for memory loads after bound
>>> checks have been done. To avoid speculative out-of-bound accesses, we
>>> use the array_index_nospec macro where applicable, or the macro
>>> block_speculation. Note, the block_speculation macro is used on all
>>> path in shared_entry_header and nr_grant_entries. This way, after a
>>> call to such a function, all bound checks that happened before become
>>> architectural visible, so that no additional protection is required
>>> for corresponding array accesses. As the way we introduce an lfence
>>> instruction might allow the compiler to reload certain values from
>>> memory multiple times, we try to avoid speculatively continuing
>>> execution with stale register data by moving relevant data into
>>> function local variables.
>>>
>>> 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
>> Upon re-reading I think this last item isn't fully applicable: I think
>> you attach such an attribute to domain creation/destruction functions.
>> Those aren't executed repeatedly for a single guest, but e.g. rapid
>> rebooting of a guest (or several ones) may actually be able to train
>> such paths.
> True, but a rebooted domain might come up on a different core, which
> results in using different hardware structures. The "repeatedly" is open
> to be interpreted, I agree. From my understanding, it belongs to the
> properties to have to reliably target a speculative out-of-bound access.

Looks like we're taking a somewhat different perspective here: I don't
think "reliably" is the criteria to go by, but instead it would be
"there's a reasonable chance". Plus the smaller the host, the less
possibilities there are for coming back up on a different core, yet imo
we shouldn't favor large hosts in our considerations.

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