On 7/18/19 14:09, Jan Beulich wrote: > 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"?
I will drop the last condition, and post an update one more time. For code path that can be executed once, e.g. during initialization, no need for mitigation might be obvious enough, and for other path' one has to decide whether a guest can actually trigger them often enough so that a fix is required. Best, Norbert ... snip ... Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
