linux-kernel - Re: [PATCH v2 2/2] arm: mm: support ARCH_MMAP_RND

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <563BA393.9020504@android.com>
Date:	Thu, 5 Nov 2015 10:44:35 -0800
From:	Daniel Cashman <dcashman@...roid.com>
To:	Kees Cook <keescook@...omium.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...nel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Jonathan Corbet <corbet@....net>,
	Don Zickus <dzickus@...hat.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Heinrich Schuchardt <xypron.glpk@....de>, jpoimboe@...hat.com,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	n-horiguchi@...jp.nec.com, Andrea Arcangeli <aarcange@...hat.com>,
	Mel Gorman <mgorman@...e.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	David Rientjes <rientjes@...gle.com>,
	Linux-MM <linux-mm@...ck.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	Mark Salyzyn <salyzyn@...roid.com>,
	Jeffrey Vander Stoep <jeffv@...gle.com>,
	Nick Kralevich <nnk@...gle.com>,
	dcashman <dcashman@...gle.com>,
	Michael Ellerman <michael@...erman.id.au>
Subject: Re: [PATCH v2 2/2] arm: mm: support ARCH_MMAP_RND_BITS.

On 11/04/2015 10:30 AM, Daniel Cashman wrote:
> On 11/3/15 3:21 PM, Kees Cook wrote:
>> On Tue, Nov 3, 2015 at 3:14 PM, Daniel Cashman <dcashman@...roid.com> wrote:
>>> On 11/03/2015 11:19 AM, Kees Cook wrote:
>>>> Do you have patches for x86 and arm64?
>>>
>>> I was holding off on those until I could gauge upstream reception.  If
>>> desired, I could put those together and add them as [PATCH 3/4] and
>>> [PATCH 4/4].
>>
>> If they're as trivial as I'm hoping, yeah, let's toss them in now. If
>> not, skip 'em. PowerPC, MIPS, and s390 should be relatively simple
>> too, but one or two of those have somewhat stranger calculations when
>> I looked, so their Kconfigs may not be as clean.
> 
> Creating the patches should be simple, it's the choice of minimum and
> maximum values for each architecture that I'd be most concerned about.
> I'll put them together, though, and the ranges can be changed following
> discussion with those more knowledgeable, if needed.  I also don't have
> devices on which to test the PowerPC, MIPS and s390 changes, so I'll
> need someone's help for that.

Actually, in preparing the x86 and arm64 patches, it became apparent
that the current patch-set does not address 32-bit executables running
on 64-bit systems (compatibility mode), since only one procfs
mmap_rnd_bits variable is created and exported. Some possible solutions:

1) Create a second set for compatibility, e.g. mmap_rnd_compat_bits,
mmap_rnd_compat_bits_min, mmap_rnd_compat_bits_max and export it as with
mmap_rnd_bits.  This provides the most control and is truest to the
spirit of this patch, but pollutes the Kconfigs and procfs a bit more,
especially if we ever need a mmap_rnd_64compat_bits...

2) Get rid of the arch-independent nature of this patch and instead let
each arch define its own Kconfig values and procfs entries. Essentially
the same outcome as the above, but with less disruption in the common
kernel code, although also with a potentially variable ABI.

3) Default to the lowest-supported, e.g. arm64 running with
CONFIG_COMPAT would be limited to the same range as arm.  This solution
I think is highly undesirable, as it actually makes things worse for
existing 64-bit platforms.

4) Support setting the COMPAT values by Kconfig, but don't expose them
via procfs.  This keeps the procfs change simple and gets most of its
benefits.

5) Leave the COMPAT values specified in code, and only adjust introduce
config and tunable options for the 64-bit processes.  Basically keep
this patch-set as-is and not give any benefit to compatible applications.

My preference would be for either solutions 1 or 4, but would love
feedback and/or other solutions. Thoughts?

Thank You,
Dan
--
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/