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: <4C72C390.90802@goop.org>
Date:	Mon, 23 Aug 2010 11:53:04 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Ian Jackson <ijackson@...ark.greenend.org.uk>
CC:	Peter Zijlstra <peterz@...radead.org>,
	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
Subject: Re: [RFC] mlock/stack guard interaction fixup

 On 08/23/2010 10:18 AM, Ian Jackson wrote:
> 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.
>
> But you seem, like me, to be disagreeing with Linus's assertion that
> calling mlock() on the stack is something no sane programs does ?

Doing hypercalls from userspace is a silly hack to avoid putting dom0
hypercall knowledge into the kernel.  mlock in that area has always been
problematic (initially on Solaris, and increasingly on Linux) and we're
going to have to fix it at some point.  I wouldn't spend a lot of time
defending it.

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