On 1/29/19 10:46, Jan Beulich wrote: >>>> Norbert Manthey <nmant...@amazon.de> 01/29/19 9:35 AM >>> >> I am aware that both version use the same base array, and access it via >> different macros, which essentially partition the array based on the >> size of the respective struct. The underlying raw array has the same >> size for both version. > And this is the problem afaics: If a guest has requested its grant table to > be sized as a single page, this page can fit twice as many entries for > v1 than it can fit for v2. Hence the v1 grant reference pointing at the last > entry would point at the last entry in the (not mapped) second page for v2.
I might understand the code wrong, but a guest would ask to get at most N grant frames, and this number cannot be increased afterwards, i.e. the field gt->max_grant_frames is written exactly once. Furthermore, the void** shared_raw array is allocated and written exactly once with sufficient pointers for, namely gt->max_grant_frames many in function grant_table_init. Hence, independently of the version being used, at least the shared_raw array cannot be used for out-of-bound accesses during speculation with my above evaluate_nospec. That being said, let's assume we have a v1 grant table, and speculation uses the v2 accesses. In that case, an existing and zero-initialized entry of shared_raw might be used in the first part of the shared_entry_v2 macro, and even if that pointer would be non-NULL, the page it would point to would have been cleared when growing the grant table in function gnttab_grow_table. That being said, I believe it is fine to let the above speculative happen without extra hardening. Best, Norbert PS: I just noticed that the shared_raw array might be allocated with a smaller size, as long as more than 1 grant_entry fits into a page. > > > Jan > Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrer: Christian Schlaeger, Ralf Herbrich Ust-ID: DE 289 237 879 Eingetragen am Amtsgericht Charlottenburg HRB 149173 B _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
