Re: x32 processes, with CONFIG_X86_X32 not set

[Dave Jones <davej@codemonkey.org.uk>]

On Fri, Mar 25, 2016 at 08:51:39AM -0700, Andy Lutomirski wrote:
 > On Fri, Mar 25, 2016 at 8:48 AM, Dave Jones <davej@codemonkey.org.uk> wrote:
 > > I had a trinity process get stuck last overnight.
 > > The reason for it getting stuck is my bug (I think), but
 > > there's an odd unrelated thing I noticed while debugging this..
 > >
 > > $ strace -p 20966
 > > strace: Process 20966 attached
 > > strace: [ Process PID=20966 runs in x32 mode. ]
 > >
 > > So I don't use that new-fangled x32 stuff.
 > > I don't even have CONFIG_X86_X32 compiled in.
 > >
 > > Is this strace getting confused, or did we somehow screw
 > > up the syscall entry code ?
 > >
 > >         Dave
 > >
 > 
 > I think you're just seeing an oddity of how x32 works.  Unlike
 > "compat", x32-ness of the current syscall isn't a special magic state
 > variable; it's just but 31 in the syscall nr.  So trying to do an x32
 > syscall on a non-x32 syscall should still show bit 31 set to ptracers,
 > and the strace probably decodes this as being in x32 mode.

But this is an x86-64 binary, and it's the main process, not one of the fuzzing
child processes. It shouldn't be even trying to do anything weird.
It creates a bunch of fd's, then enters a loop forking/reaping children.
(In this case it actually hung while creating the fd's)

Trinity doesn't actually have any knowledge of x32 at all, mostly because
it's been irrelevant to me (and most other people).

	Dave