linux-kernel - Re: [RFC] mlock/stack guard interaction fixup

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: <1282585221.2605.2088.camel@laptop>
Date:	Mon, 23 Aug 2010 19:40:21 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Ian Jackson <ijackson@...ark.greenend.org.uk>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg KH <gregkh@...e.de>, Ian Campbell <ijc@...lion.org.uk>,
	linux-kernel@...r.kernel.org, stable@...nel.org,
	stable-review@...nel.org, akpm@...ux-foundation.org,
	alan@...rguk.ukuu.org.uk, Jeremy Fitzhardinge <jeremy@...p.org>
Subject: Re: [RFC] mlock/stack guard interaction fixup

On Mon, 2010-08-23 at 18:18 +0100, Ian Jackson wrote:
> Peter Zijlstra writes ("Re: [RFC] mlock/stack guard interaction fixup"):
> > On Mon, 2010-08-23 at 16:42 +0100, ijackson@...ark.greenend.org.uk
> > wrote:
> > > mlocking the stack is entirely sensible and normal for a real-time
> > > program.  Most such programs use mlockall but there is no particular
> > > reason why a program that has some more specific requirements should
> > > use mlock to lock only a part of the stack.  (Perhaps it has only one
> > > real-time thread?) 
> > 
> > RT apps should pre-allocate and mlock their stack in advance (and
> > pre-fault too for the paranoid).
> 
> Are you allowed to mlock a stack page which has not yet been faulted
> in ?  What effect does it have ?  I wasn't able to find a convincing
> de jure answer to this question.

mlock() seems to call make_pages_present(), so its a moot point.

> But you seem, like me, to be disagreeing with Linus's assertion that
> calling mlock() on the stack is something no sane programs does ?

I think the case that Linus called daft is splitting the stack vma
through mlock/mprotect, which is indeed something rarely done.

> > mlockall is a very bad interface and should really not be used.
> 
> You are directly contradicting the advice in SuS, to which I just gave
> a reference.  You're free to do so of course but it might be worth
> explaining in a bit more detail why the advice in SuS is wrong.

Because a real RT program will have a significant !RT part, and calling
mlock on everything is a massive resource waste.

Furthermore, mlockall gives the false impression that everything is good
to go for RT, disregarding pretty much everything that makes a RT app.

There's lots more to RT than sched_setscheduler() and
mlockall(MCL_FUTURE).

If a library is RT suited, it will already mlock() all relevant memory
allocations (or provide an option to do so, or strictly work on
externally allocated memory, which the user will then have mlock()'ed).


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