Re: [Qemu-devel] RFC: [0/11] EFAULT patch

[J. Mayer]

On Wed, 2007-09-19 at 15:00 -0400, Stuart Anderson wrote:
> On Wed, 19 Sep 2007, J. Mayer wrote:
> 
> > Then, the changes you've done, changing long arguments (which should be
> > target_long to be correct, you can take a look at the last patch I sent
> > on the list) to pointers, for example in function prototypes, are
> > incorrect.
> 
> I just went, and looked at the linux code again for 32 on 64 for x86_64 and
> powerpc.  In both of these cases (and I suspect the others as well), the
> parameters which are passed via registers are 0 extended from 32 bits to
> 64 bit in the syscall entry asm code. This way, once the C code is
> called via the sys_call_table, everything is dealt with as 64 bits. This
> actually keeps the rest of the code simpler as the rest of the kernel
> doesn't have to be extending & truncating pointers everywhere else.

It's not surprising to me for PowerPC as PowerPC 32 is mostly defined as
the same architecture as PowerPC 64 with 32 bits addressing. Running in
32 bits mode on PowerPC mostly mean you have addresses masked for memory
accesses and different overflow and carry flags generations, but all
computations can still be done the same way as in 64 bits mode.
The situation may be different for x86 code running on x86_64, don't
have the knowledge to tell...

> On x86_64 and powerpc, it appears that both user (ie target) and kernel
> pointers co-exist and that the code that maps structures assume that the
> __get_user()/__put_user() and copy_*_user() routines can handle any
> special situation. The pointers passed into functions like
> cp_compat_stat() are 64-bits for both the structure located in the
> kernel, and the one located in user space.
> 
> My understanding is that we want to do as the kernel does as much as
> possible. In light of this, wouldn't we want to be decreasing the use
> of target_long where pointers may be involved instead of increasing it?

Well, we also have to take care of the reversed case: emulating 64 bits
targets on 32 bits hosts (which is exactly what I'm currently trying to
sanitize). Then, we need to keep argument size to always be >=
TARGET_LONG_BITS. That's the reason why it seems a good idea to me to
use target_long everywhere but at the point we would actually
dereference the pointer. If we want once to be able to fully emulate 64
bits targets on 32 bits hosts, we will have to deal with the fact the
target memory space may not fit in the host one, then deal with page
swapping. In those conditions, host pointers use would have to be
avoided as much as possible, imho.

-- 
J. Mayer <address@hidden>
Never organized