On 28 May 2012, at 09:36, Konstantin Belousov wrote: > On Sun, May 27, 2012 at 07:49:36AM +1000, Bruce Evans wrote: >> On Sat, 26 May 2012, Konstantin Belousov wrote: >> >>> On Sat, May 26, 2012 at 10:21:25PM +1000, Bruce Evans wrote: >>> 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. > Hardware zero-extends any register touched in the 32bit mode. > > In fact, please see r217991 for related bug.
This may well be true on Intel, but is not true of MIPS -- which we probably don't care about currently for the purposes of Linux emulation, but maybe someday we will. On MIPS, 32-bit values are sign-extended rather than zero-extended. I see a somewhat complex thread here, but am not sure I quite understand the import for Capsicum. Is the 64-bit rights mask as part of system call arguments not working properly in compat32 scenarios? Or are there issues outside of the compat environment? Right now compat32 is not well-supported with Capsicum, but fixing that is quite important to productionising Capsicum. Robert_______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
