linux-kernel - Re: [PATCH v5 8/9] x86-64: Emulate legacy vsyscalls

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:	Mon, 06 Jun 2011 17:58:16 +0200
From:	pageexec@...email.hu
To:	Ingo Molnar <mingo@...e.hu>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Lutomirski <luto@....edu>, x86@...nel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, Jesper Juhl <jj@...osbits.net>,
	Borislav Petkov <bp@...en8.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Jan Beulich <JBeulich@...ell.com>,
	richard -rw- weinberger <richard.weinberger@...il.com>,
	Mikael Pettersson <mikpe@...uu.se>,
	Andi Kleen <andi@...stfloor.org>,
	Brian Gerst <brgerst@...il.com>,
	Louis Rilling <Louis.Rilling@...labs.com>,
	Valdis.Kletnieks@...edu
Subject: Re: [PATCH v5 8/9] x86-64: Emulate legacy vsyscalls

On 6 Jun 2011 at 17:33, Ingo Molnar wrote:

> Is it this commit:
> 
>  320b2b8de126: mm: keep a guard page below a grow-down stack segment

yes and all the related ones.

> But you say that there's a Sun JVM breakage still left, right? Is 
> there a bugzilla # or simple .c reproducer for that?

i don't know if only that JVM is affected, the fact is that breaking
the maps API breaks everyone who relied on it the same way.

also it's not fixable without reverting the *entire* approach. see,
it's very simple: if the kernel lies about the stack boundary, it
breaks the JVM and similar approaches, if it doesn't lie about it
then it breaks other apps as you already found out.

as for bz/reproduction, neither exists, i read the JVM code carefully
at the time (had actually remembered from other times) and just went
ahead and fixed it properly in PaX.

for reproduction you'd have to trigger a stack overflow (not to be
confused with a buffer overflow) on the main jvm thread, iirc, i have
no idea how to pull that off. but you can easily write a small test
app based on what i explained and test it but i hope it's obvious
how the JVM logic breaks down with the maps changes.

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