svn commit: r236026 - in head/sys: amd64/linux32 compat/freebsd32 kern

Bruce Evans brde at optusnet.com.au
Sun May 27 07:45:17 UTC 2012


On Sun, 27 May 2012, Bruce Evans wrote:

> On Sat, 26 May 2012, Konstantin Belousov wrote:
>
>> On Sat, May 26, 2012 at 10:21:25PM +1000, Bruce Evans wrote:
>>>...
>>> All the non-indirect "char *"s for pathnames and other things seem to be
>>> completely wrong on amd64 too.  These pointers start as 32 bits, and it
>>> takes more than a bad type pun to turn then into kernel 64-bit pointers.
>>> The magic for this seems to be:
>>> - all args are converted to 64 bits (by zero-extension?) at a low level
>>> ...
>> The 'low level' AKA magic happens in several *_fetch_syscall_args()
>> functions. For both linux32 and freebsd32, the magic code automatically
>> zero-extends the arguments into 64bit entities. Linux passes args in
>> registers, while FreeBSD uses words on stack.
>
> Actually, the amd64 linux_fetch32_fetch_syscall_args() just copies from
> 64-bit registers frame->tf_r* to 64-bit sa->args[*].  I can't see how
> this gives anything except garbage in the top bits.  Is there magic in
> the switch to 64-bit mode that sets the top bits?  Anyway, sign extension
> would give garbage for unsigned args, and zero-extension would give
> garbage for negative signed args.

I checked what actually happens.  There is no magic.  The registers
just have garbage in the top bits.  Mostly this is 0.  Sometimes it
is all top bits 1.  Sometimes it is some top bits 1 (starting at the
top).  I traced a bit of the execution of ld-linux.so...  The first
syscall was an linux_mmap.  It had all top bits 1 in tf_rbx, then some
top bits 1 in a later register, and all top bits 0 in 4 registers.
Then there were several syscalls with all top bits in all 6 syscall
arg registers 0.  Then there was a linux_write syscall with 1's back
in some top bits.  Then there were many syscalls with all top bits in
all arg registers 0.

This behaviour is probably due to the initial state being more random
(but why doesn't exec clear all top bits?).  Then normal activity
like xorl %ebx,%ebx tends to clear top bits (does this xorl clear top
bits even in 32-bit mode?).  Then something occasionally sets top bits
to 1.

> The amd64 ia32_fetch_syscall_args() is quite different.  Now the args
> ...

Bruce


More information about the svn-src-all mailing list