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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 23 Aug 2010 19:59:45 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Ian Jackson <ijackson@...ark.greenend.org.uk>,
	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 10:34 -0700, Linus Torvalds wrote:
> I suspect that if you use mlock for _any_ other reason than protecting
> a particular very sensitive piece of information, you should use
> mlockall(MCL_FUTURE). IOW, if you use mlock because you have realtime
> issues, there is no excuse to ever use anything else, imho. And even
> then, I guarantee that things like copy-on-write is going to be
> "interesting".
> 
> I realize that people hate mlockall() (and particularly MCL_FUTURE),
> and yes, it's a bloated thing that you can't reasonably use on a large
> process. But dammit, if you have RT issues, you shouldn't _have_ some
> big bloated process. You should have a small statically linked server
> that is RT, and nothing else. 

Us real-time people have been telling people to not use mlockall() at
all.

While small !glibc statically linked RT components using shared memory
interfaces to !RT apps could work its not how people actually write
their apps. They write big monolithic threaded apps where some threads
are RT.

[ in part because there doesn't seem to be a usable !glibc
libpthread/librt implementation out there, in part because people use
crap like Java-RT ]


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