>>> On 02.09.16 at 12:02, <jbeul...@suse.com> wrote:
>>>> On 02.09.16 at 10:51, <rcojoc...@bitdefender.com> 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@lists.xen.org
https://lists.xen.org/xen-devel
