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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BANLkTintkmnkN3kW06oa+TjT7W0Q1yQQGA@mail.gmail.com>
Date:	Mon, 16 May 2011 13:05:12 -0400
From:	Andrew Lutomirski <luto@....edu>
To:	Andi Kleen <andi@...stfloor.org>
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

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?

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.

Longer term, it would be nice to mark the vsyscall page NX.  That
involves a few things:

1. Move vread to the vDSO.  That's not very hard.
2. Get glibc to stop using the old vsyscalls.  I think it still does
for static-linked programs.
3. Have a bit of a deprecation period.
4. Come up with some way to make old programs keep working even with
NX set.  Maybe just delete the vsyscall functions and emulate them on
a trap (with a printk_once warning about the performance loss).

That way all user code has (in principle) dwarf2.  And we won't have a
syscall instruction sitting at a predictable address.

--Andy

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