[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH SpectreV1+L1TF v6 3/9] x86/hvm: block speculative out-of-bound accesses



>>> On 15.02.19 at 09:05, <nmanthey@xxxxxxxxx> wrote:
> On 2/12/19 15:14, Jan Beulich wrote:
>>>>> On 12.02.19 at 15:05, <nmanthey@xxxxxxxxx> wrote:
>>> On 2/12/19 14:25, Jan Beulich wrote:
>>>>>>> On 08.02.19 at 14:44, <nmanthey@xxxxxxxxx> 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 <jbeulich@xxxxxxxx>
>>> 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.
> 
> I cannot give a guarantee what future compilers might do. Furthermore, I
> do not want to wait until all/most compilers ship with such a
> controllable guarantee.

Guarantee? Future compilers are (hopefully) going to get better at
optimizing, and hence are (again hopefully) going to find more
opportunities for CSE. So the problem is going to get worse rather
than better, and the changes you're proposing to re-instate are
therefore more like false promises.

Jan



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.