linux-kernel - Re: [PATCH v4 10/10] x86-64: Add CONFIG_UNSAFE

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:	Tue, 31 May 2011 21:28:33 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Andrew Lutomirski <luto@....edu>
Cc:	Andi Kleen <andi@...stfloor.org>, x86@...nel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, Jesper Juhl <jj@...osbits.net>,
	Borislav Petkov <bp@...en8.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	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>
Subject: Re: [PATCH v4 10/10] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to
 feature-removal-schedule


* Andrew Lutomirski <luto@....edu> wrote:

> > And it's still a bad idea. Especially since there's a much better 
> > alternative anyways for the "security problem" which has none of 
> > these drawbacks.
> 
> What's the alternative?

Well, Andi likes to draw out such answers and likes to keep any 
answer as minimally helpful as possible (to demonstrate his 
superiority), but my guess would be that he is thinking of the 
(trivial) solution that filters the caller RIP at the generic syscall 
entry point and checks RCX against the 'expected' SYSCALL instruction 
address, which is the (per task) vdso-address + constant-offset.

That method has a big disadvantage:

 - it slows down the syscall fastpath with two or three unnecessary 
   instructions.

It has two advantages:

 - it's the simplest method of all

 - it also *only* allows the vdso address to be used for system calls,
   so if an attacker manages to find an executable SYSCALL 
   instruction somewhere in the executable space of an application,
   that entry point will not be usable.

... so this method is not completely off the table.

If everyone agrees that the generic syscall overhead is acceptable we 
could try this too.

Thoughts?

Thanks,

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