linux-kernel - Re: [RFC 1/3] mm: mmap make 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]

Message-ID: <20150429075238.GA16097@dhcp22.suse.cz>
Date:	Wed, 29 Apr 2015 09:52:38 +0200
From:	Michal Hocko <mhocko@...e.cz>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-mm@...ck.org, Cyril Hrubis <chrubis@...e.cz>,
	Hugh Dickins <hughd@...gle.com>,
	Michel Lespinasse <walken@...gle.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Rik van Riel <riel@...hat.com>,
	Michael Kerrisk <mtk.manpages@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Linux API <linux-api@...r.kernel.org>
Subject: Re: [RFC 1/3] mm: mmap make MAP_LOCKED really mlock semantic

On Tue 28-04-15 16:10:01, Andrew Morton wrote:
> On Tue, 28 Apr 2015 14:11:49 +0200 Michal Hocko <mhocko@...e.cz> wrote:
> 
> > The man page however says
> > "
> > MAP_LOCKED (since Linux 2.5.37)
> >       Lock the pages of the mapped region into memory in the manner of
> >       mlock(2).  This flag is ignored in older kernels.
> > "
> 
> I'm trying to remember why we implemented MAP_LOCKED in the first
> place.  Was it better than mmap+mlock in some fashion?
> 
> afaict we had a #define MAP_LOCKED in the header file but it wasn't
> implemented, so we went and wired it up.  13 years ago:
> https://lkml.org/lkml/2002/9/18/108

Yeah I have encountered this one while digging though the history as
well but there was no real usecase described - except "it doesn't work
currently".

The only sensible usecase I was able to come up with was a userspace
fault handling when we need to mmap and lock the faulting address in an
atomic way so that other threads cannot possibly leak data to the swap.
These guys can live with the current implementation, though.

I do not really believe that 2 instead of 1 syscall really justifies the
complexity.

> Anyway...  the third way of doing this is to use plain old mmap() while
> mlockall(MCL_FUTURE) is in force.  Has anyone looked at that, checked
> that the behaviour is sane and compared it with the mmap+mlock
> behaviour, the MAP_LOCKED behaviour and the manpages?

AFAICS this will behave the same way as mmap(MAP_LOCKED). VMA will be
marked VM_LOCKED but the popullation might fail for the very same
reason.

-- 
Michal Hocko
SUSE Labs
--
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/