Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 02.09.16 at 12:02, <JBeulich@xxxxxxxx> wrote:
>>>> On 02.09.16 at 10:51, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>> @@ -320,6 +321,23 @@ int compat_memory_op(unsigned int cmd, 
>> XEN_GUEST_HANDLE_PARAM(void) compat)
>>              break;
>>          }
>>  
>> +        case XENMEM_access_op:
>> +        {
>> +#define XLAT_mem_access_op_HNDL_pfn_list(_d_, _s_) \
>> +            guest_from_compat_handle((_d_)->pfn_list, (_s_)->pfn_list)
>> +#define XLAT_mem_access_op_HNDL_access_list(_d_, _s_) \
>> +            guest_from_compat_handle((_d_)->access_list, (_s_)->access_list)
>> +
>> +            XLAT_mem_access_op(nat.mao, &cmp.mao);
>> +
>> +#undef XLAT_mem_access_op_HNDL_pfn_list
>> +#undef XLAT_mem_access_op_HNDL_access_list
>> +
>> +            return mem_access_memop(cmd,
>> +                                    guest_handle_cast(compat,
>> +                                                      xen_mem_access_op_t));
>> +        }
> 
> You translate into native format, but then cast the compat handle
> to its native counterpart type. Such casting is okay only when
> accompanied by a respectively invoked CHECK_* macro. Please
> follow the model other code here uses.
> 
> And reviewing this I notice that my earlier bug fix also is still not
> really correct: It causes hypercall_xlat_continuation() to be
> bypassed.

Actually no, that patch is fine because it (legitimately) uses a cast.
You would introduce the bypassing problem here as soon as you
properly handed the native handle to mem_access_memop().

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel