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]

Message-ID: <BANLkTinVnr1ZM2wOxuH-rHZGh+_SBWT-+g@mail.gmail.com>
Date:	Mon, 16 May 2011 18:17:29 -0400
From:	Andrew Lutomirski <luto@....edu>
To:	Thomas Gleixner <tglx@...utronix.de>
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, 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
see if I can persuade Uli to take accept a glibc patch to stop calling
it in future static glibc versions.

The long-term cost to the kernel will be a special case (and, compare,
unlikely branch) in whichever fault trap gets used.  The best way
might be to use a page full of 0xCC so that an int3 fault (presumably
not a performance-critical path) is taken.

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