linux-kernel - Re: [PATCH v4 0/6] Micro-optimize vclock

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, 17 May 2011 00:40:38 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Andrew Lutomirski <luto@....edu>
cc:	Andi Kleen <andi@...stfloor.org>, x86@...nel.org,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Borislav Petkov <bp@...64.org>
Subject: Re: [PATCH v4 0/6] Micro-optimize vclock_gettime

On Mon, 16 May 2011, Andrew Lutomirski wrote:
> On Mon, May 16, 2011 at 5:53 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
> > On Mon, 16 May 2011, Andi Kleen wrote:
> >> Andrew Lutomirski <luto@....edu> writes:
> >> > Longer term, it would be nice to mark the vsyscall page NX.  That
> >> > involves a few things:
> >>
> >> Why NX? What would make sense is to call the VDSO from it.
> >> The problem is that the vDSO is randomized and there's no good memory
> >> location to store the pointer to it.
> >>
> >> The real reason for all this dance is to have some less non randomized
> >> code around. What I implemented back then was instead code to patch out
> >> the SYSCALL in there if not needed to lower the attack surface (not sure
> >> if that still works though, but that was the idea). For most cases
> >> (TSC/HPET read) it's not needed.
> >>
> >> Checking: someone removed the code meanwhile.
> >
> > For a damned good reason.
> >
> >> > And we won't have a
> >> > syscall instruction sitting at a predictable address.
> >>
> >> The easy way to fix this is to just re-add the patching.
> >
> > If you can address _all_ reasons why it was removed then we might
> > revisit that issue, but that's going to be an interesting patch.
> 
> We're now completely offtopic for the RDTSC patches, but do you have
> any moral objection to rigging the vsyscall page to generate a fault
> and emulating it after a couple years of deprecation?  If not, I can

Moral objections are pretty irrelevant, but I have no technical
objections either. :)

> see if I can persuade Uli to take accept a glibc patch to stop calling
> it in future static glibc versions.

How wide spread is this in reality on 64bit systems ?

IOW, what's the damage if we take a trap and emulate it in the most
painful way we can come up with ?

Thanks,

	tglx