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]

Message-ID: <20110531202450.GA28731@elte.hu>
Date:	Tue, 31 May 2011 22:24:50 +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:

> [Sorry, possible resend.]
> 
> On 5/31/11, Ingo Molnar <mingo@...e.hu> wrote:
> >
> > * Ingo Molnar <mingo@...e.hu> wrote:
> >
> >> [...] 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.
> >
> > Note that this solution would allow the vsyscall page to be
> > 'filtered' to the 3 allowed system calls rather efficiently, via a
> > second level check.
> >
> > This second check does not affect the fastpath, and it could be put
> > behind a CONFIG_COMPAT_VSYSCALL deprecation define once glibc does
> > not put vsyscall references anywhere - but we could even keep it
> > around forever, as this way it's defanged permanently.
> >
> 
> Are you thinking about the 32-bit vDSO? I think that 64-bit code puts
> syscalls instructions all over the place.

Yeah, it does in a few dozen places so RCX filtering would only work 
if we 'knew' about glibc's syscall range (it's available from the 
vma) and restricted syscalls to that boundary.

... which makes this solution rather fragile so i think we can 
disregard it.

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/