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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
