linux-kernel - Re: [PATCH 04/13] Always expose MAP

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:	Tue, 15 Sep 2015 12:42:00 +0300
From:	"Kirill A. Shutemov" <kirill@...temov.name>
To:	Josh Triplett <josh@...htriplett.org>
Cc:	Palmer Dabbelt <palmer@...belt.com>, 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,
	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 10:19:19PM -0700, Josh Triplett wrote:
> On Tue, Sep 15, 2015 at 03:23:58AM +0300, Kirill A. Shutemov wrote:
> > 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.
> 
> The flag should always exist.

Sure. And 0 is perfectly fine value for the flag. Like with MAP_FILE.

> If it was defined to conflict with
> something else, that's a serious ABI problem.  But the flag
> should always exist, even if the kernel ends up ignoring it.
> 
> > 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.
> 
> No; even if you have an MMU (which is useful for things like fork()), a
> system without user separation (for instance, without CONFIG_MULTIUSER)
> can reasonably use MAP_UNINITIALIZED.

Can? Yes. Reasonably? I don't think so.

> > P.S. MAP_UNINITIALIZED itself looks very broken to me. I probably need dig
> > mailing list on why it was allowed.
> 
> That's what the config option *and* explicit flag are for; there are
> more than enough warnings about the implications.

I think it's misdesigned. It doesn't require explicid opt-in from a
process who owned the page allocated in MAP_UNINITIALIZED mapping before.

#define MAP_LEAK_ME_SOME_DATA MAP_UNINITIALIZED

-- 
 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/