Re: [Qemu-devel] [PATCH] linux-user: manage SOCK_PACKET socket type.

[Laurent Vivier <laurent@vivier.eu>]

Le 27/10/2015 12:35, Peter Maydell a écrit :
> On 27 October 2015 at 10:47, Laurent Vivier <laurent@vivier.eu> wrote:
>> And for the socketcall part, we need the tswap16():
>>
>> for instance,
>>
>>     int a = htons(0x0003);
>>
>> On a LE host:
>>
>>     a = 0x00000300
>>
>> On a BE host:
>>
>>     a = 0x00000003
>>
>> If the guest is BE, it will put in memory:
>>
>>     0x00 0x00 0x00 0x03
>>
>> Then a LE host, will read:
>>
>>     int b = 0x03000000
>>
>> but get_user_ual() in do_socketcall() will byte-swap it and put
>> 0x00000003 in a[2].
>>
>> so without the byte-swap, we call do_socket(..., 0x0003),
>> whereas the syscall is waiting for htons(0x0003) -> 0x0300 as we are on
>> LE host.
> 
> So, I thought through this this morning, and I think the swapping
> issues here are not specific to socketcall. If the socket syscall
> ABI requires an argument of "htons(3)", then this is actually
> a *different* ABI for BE vs LE systems. On a BE system this is
> asking for "3", but on LE it is asking for "0x300". (Argument
> is generally passed in a register.) So we need to be able to tell
> when the host kernel wants this sort of difference and fix it up.
> 
> For socketcall, the current swapping we have will correctly pass
> the value the user wrote into the array-of-longs into the syscall,
> because if the value to be passed is 0x11223344 (assume 32-bit long),
> for BE guest LE host we have:
>  in register 0x11223344
>  in memory 0x11 0x22 0x33 0x44
>  byteswapped back by get_user_ual: 0x11223344
> and for LE guest LE host:
>  in register 0x11223344
>  in memory 0x44 0x33 0x22 0x11
>  read back by get_user_ual: 0x11223344
> But we still have the same issue that if the guest believes the
> kernel wants a value of 0x3 but in fact it wants 0x300 we need to
> fix things up.
> 
> So the fix needs to go into do_socket(), and it needs to be
> specific to the PF*/SOCK* values that indicate socket types
> that want a network-order-16-bit value, which I think is
>  (domain == AF_PACKET || (domain == AF_INET && type == SOCK_PACKET))

OK, I will try with my use case.

> 
> (this is pretty close to what your patch had to start with,
> so apologies for taking a while to work through it. Endianness
> always confuses me...)

No problem, It tooks me 3 years to explain that correctly :) ...

> Still thinking about the other part of your patch, because
> "does this start with 'eth'" is not very pretty...

I agree but I didn't find a better way...

Laurent