linux-kernel - Re: [PATCH 0/1] x86: should 32 bit processes be PER

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 for Android: free password hash cracker in your pocket

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

Message-ID: <4C8FBF8E.3060503@msgid.tls.msk.ru>
Date:	Tue, 14 Sep 2010 22:31:42 +0400
From:	Michael Tokarev <mjt@....msk.ru>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Andy Whitcroft <apw@...onical.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, Christoph Hellwig <hch@....de>,
	x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/1] x86: should 32 bit processes be PER_LINUX32

14.09.2010 22:19, H. Peter Anvin wrote:
> On 09/14/2010 09:00 AM, Andy Whitcroft wrote:
>> While testing an x86 64 bit kernel on 32 bit userspace I noticed that I
[...]

Folks, while we're at it, can we also fix the ADDR_LIMIT_3GB personality?
With all current kernels it just does not work, returning EINVAL to the
second execve() call.  It never worked from within a 32bit process, but
that at least can be worked around by introducing a small 64bit helper.
Now that helper does not work too.

Or just remove it altogether, to stop confusing people... :)

(We finally moved our legacy application from oracle8 (which only exist
in 32bit for linux) to oracle10, so this problem has no relevance for
us anymore.  Before it were quite problematic...)

Thanks!

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/