x32 processes, with CONFIG_X86_X32 not set
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
Quoted 8 lines · Dave Jones
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. ]
Quoted 8 lines
So I don't use that new-fangled x32 stuff.
I don't even haveCONFIG_X86_X32compiled 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.
--Andy
Quoted 15 lines · Andy Lutomirski
Quoted 14 lines · Dave Jones
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 haveCONFIG_X86_X32compiled in.Is this strace getting confused, or did we somehow screw up the syscall entry code ?
Quoted 8 lines
Quoted 2 lines
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
Quoted 25 lines · Dave Jones
Quoted 15 lines · Andy Lutomirski
Quoted 14 lines · Dave Jones
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 haveCONFIG_X86_X32compiled in.Is this strace getting confused, or did we somehow screw up the syscall entry code ?
Quoted 8 lines
Quoted 2 lines
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.
Quoted 8 lines
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).
Hmm. Do you have the next couple lines of strace output by any chance? I'm wondering if this is a classic bug/misfeature/confusion in the way that orig_ax works.
FWIW, the way that strace detects 32-bit mode is bogus, and I don't actually know how strace detects x32 mode.
Quoted 3 lines
Dave
Signature · 2 lines
Andy Lutomirski AMA Capital Management, LLC
Quoted 28 lines · Andy Lutomirski
Quoted 28 lines
Quoted 14 lines
Quoted 14 lines
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 haveCONFIG_X86_X32compiled in.Is this strace getting confused, or did we somehow screw up the syscall entry code ?
Quoted 8 lines
Quoted 2 lines
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)
Quoted 7 lines
Quoted 3 lines
Trinity doesn't actually have any knowledge of x32 at all, mostly because it's been irrelevant to me (and most other people).
Hmm. Do you have the next couple lines of strace output by any chance? I'm wondering if this is a classic bug/misfeature/confusion in the way that
orig_axworks.
I don't. That box got rebooted a couple dozen times since then. FWIW, I've not seen this happen since. Very strange.
Dave