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:	Mon, 16 May 2011 13:22:04 -0700
From:	Andi Kleen <andi@...stfloor.org>
To:	Andrew Lutomirski <luto@....edu>
Cc:	Thomas Gleixner <tglx@...utronix.de>, 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

Andrew Lutomirski <luto@....edu> writes:

> On Mon, May 16, 2011 at 12:49 PM, Andi Kleen <andi@...stfloor.org> wrote:
>>> And unless you or someone else changes the primitive state of the
>>> kernel, framepointers are going to stay simply because removing them
>>> breaks profiling backtraces when the hit is inside vread().
>>
>> This doesn't work anyways because the glibc stub code calling vgettimeofday
>> normally doesn't set up a frame pointer frame.
>>
>> The only way to unwind there is dwarf2.
>
> For code in the vsyscall page, I think using CFI data is a lost cause.
>  How is any user code supposed to find the CFI data?

It only works for the vDSO. vsyscall is legacy.

> For the vDSO, we could be nice to userspace and install the debugging
> symbols somewhere sensible.  Currently we generate a buildid but we
> don't install the symbols anywhere by default.

Actually we include the dwarf2 tables and signal unwinding works
(for the vDSO)

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

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

-Andi
-- 
ak@...ux.intel.com -- Speaking for myself only
--
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/