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

[Jan Beulich <JBeulich@xxxxxxxx>]

On 12.07.2019 10:51, 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

I notice this sentence is still there without modification. If you
don't want to drop it (and then perhaps make changes to a few more
paths), can we at least settle on a less firm statement like "path
is unlikely to be executed repeatedly in rapid succession"?

> 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.
> 
> This commit addresses only out-of-bound accesses whose index is
> directly controlled by the guest, and the index is checked before.
> Potential out-of-bound accesses that are caused by speculatively
> evaluating the version of the current table are not addressed in this
> commit. Hence, speculative out-of-bound accesses might still be
> possible, for example in gnttab_get_status_frame_mfn, when calling
> gnttab_grow_table, the assertion that the grant table version equals
> two might not hold under speculation.
> 
> This is part of the speculative hardening effort.
> 
> Signed-off-by: Norbert Manthey <nmanthey@xxxxxxxxx>

With the above taken care of by some re-writing
Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

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