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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAGXu5j+2xiRwt6mKrjzuf9O745GWOcjXzutONp6rz_Kj+3PfVQ@mail.gmail.com>
Date:	Fri, 6 Nov 2015 12:52:32 -0800
From:	Kees Cook <keescook@...omium.org>
To:	Daniel Cashman <dcashman@...roid.com>
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 Thu, Nov 5, 2015 at 10:44 AM, Daniel Cashman <dcashman@...roid.com> wrote:
> 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?

How about a single new CONFIG+sysctl that is the compat delta. For
example, on x86, it's 20 bits. Then we don't get splashed with a whole
new set of min/maxes, but we can reasonably control compat?

-Kees

-- 
Kees Cook
Chrome OS Security
--
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/