Le 27/10/2015 12:35, Peter Maydell a écrit : > On 27 October 2015 at 10:47, Laurent Vivier <laur...@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
