[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150915002358.GA12618@node.dhcp.inet.fi>
Date: Tue, 15 Sep 2015 03:23:58 +0300
From: "Kirill A. Shutemov" <kirill@...temov.name>
To: Palmer Dabbelt <palmer@...belt.com>
Cc: arnd@...db.de, dhowells@...hat.com, viro@...iv.linux.org.uk,
ast@...mgrid.com, aishchuk@...ux.vnet.ibm.com, aarcange@...hat.com,
akpm@...ux-foundation.org, luto@...nel.org, acme@...nel.org,
bhe@...hat.com, 3chas3@...il.com, chris@...kel.net, dave@...1.net,
dyoung@...hat.com, drysdale@...gle.com, davem@...emloft.net,
ebiederm@...ssion.com, geoff@...radead.org,
gregkh@...uxfoundation.org, hpa@...or.com, mingo@...nel.org,
iulia.manda21@...il.com, plagnioj@...osoft.com, jikos@...nel.org,
josh@...htriplett.org, kexec@...ts.infradead.org,
linux-api@...r.kernel.org, linux-arch@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-xtensa@...ux-xtensa.org, mathieu.desnoyers@...icios.com,
jcmvbkbc@...il.com, paulmck@...ux.vnet.ibm.com,
a.p.zijlstra@...llo.nl, tglx@...utronix.de, tomi.valkeinen@...com,
vgoyal@...hat.com, x86@...nel.org
Subject: Re: [PATCH 04/13] Always expose MAP_UNINITIALIZED to userspace
On Mon, Sep 14, 2015 at 03:50:38PM -0700, Palmer Dabbelt wrote:
> This used to be hidden behind CONFIG_MMAP_ALLOW_UNINITIALIZED, so
> userspace wouldn't actually ever see it be non-zero. While I could
> have kept hiding it, the man pages seem to indicate that
> MAP_UNINITIALIZED should be visible:
>
> mmap(2)
> MAP_UNINITIALIZED (since Linux 2.6.33)
> Don't clear anonymous pages. This flag is intended to improve
> performance on embedded devices. This flag is honored only if the
> kernel was configured with the CONFIG_MMAP_ALLOW_UNINITIALIZED
> option. Because of the security implications, that option is
> normally enabled only on embedded devices (i.e., devices where one
> has complete control of the contents of user memory).
>
> and since the only time it shows up in my /usr/include is in this
> header I believe this should have been visible to userspace (as
> non-zero, which wouldn't do anything when or'd into the flags) all
> along.
Are you sure about "wouldn't do anything"?
Suspiciously, 0x4000000 is also (1 << MAP_HUGE_SHIFT). I'm not sure if any
architecture has order-1 huge pages, but still looks like we have conflict
here.
I think it's harmful to expose non-zero MAP_UNINITIALIZED to system which
potentially can handle multiple users. Or non-trivial user space in
general.
Should we leave it at least under '#ifndef CONFIG_MMU'? I don't think it's
possible to have single ABI for MMU and MMU-less systems anyway. And we
can avoid conflict with MAP_HUGE_SHIFT this way.
P.S. MAP_UNINITIALIZED itself looks very broken to me. I probably need dig
mailing list on why it was allowed.
But that's other topic.
--
Kirill A. Shutemov
--
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/
Powered by blists - more mailing lists