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

[Peter Maydell]

On 27 October 2015 at 10:47, Laurent Vivier <address@hidden> 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))

(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...)

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

thanks
-- PMM