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

[Robert N. M. Watson]

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