linux-kernel - Re: x32 processes, with CONFIG_X86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 25 Mar 2016 11:58:44 -0400
From:	Dave Jones <davej@...emonkey.org.uk>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Andrew Lutomirski <luto@...nel.org>, X86 ML <x86@...nel.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: x32 processes, with CONFIG_X86_X32 not set

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@...emonkey.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