>>> On 12.02.19 at 15:05, <nmant...@amazon.de> wrote: > On 2/12/19 14:25, Jan Beulich wrote: >>>>> On 08.02.19 at 14:44, <nmant...@amazon.de> wrote: >>> @@ -4104,6 +4108,12 @@ static int hvmop_set_param( >>> if ( a.index >= HVM_NR_PARAMS ) >>> return -EINVAL; >>> >>> + /* >>> + * Make sure the guest controlled value a.index is bounded even during >>> + * speculative execution. >>> + */ >>> + a.index = array_index_nospec(a.index, HVM_NR_PARAMS); >>> + >>> d = rcu_lock_domain_by_any_id(a.domid); >>> if ( d == NULL ) >>> return -ESRCH; >>> @@ -4370,6 +4380,12 @@ static int hvmop_get_param( >>> if ( a.index >= HVM_NR_PARAMS ) >>> return -EINVAL; >>> >>> + /* >>> + * Make sure the guest controlled value a.index is bounded even during >>> + * speculative execution. >>> + */ >>> + a.index = array_index_nospec(a.index, HVM_NR_PARAMS); >> ... the usefulness of these two. To make forward progress it may >> be worthwhile to split off these two changes into a separate patch. >> If you're fine with this, I could strip these two before committing, >> in which case the remaining change is >> Reviewed-by: Jan Beulich <jbeul...@suse.com> > > Taking apart the commit is fine with me. I will submit a follow up > change that does not update the values but fixes the reads.
As pointed out during the v5 discussion, I'm unconvinced that if you do so the compiler can't re-introduce the issue via CSE. I'd really like a reliable solution to be determined first. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
