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 14:31:26 -0700
From:	Andi Kleen <andi@...stfloor.org>
To:	Andy Lutomirski <luto@....EDU>
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	x86@...nel.org, linux-kernel@...r.kernel.org,
	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

Andy Lutomirski <luto@....EDU> writes:
>
> On KVM on Sandy Bridge, I can emulate a vsyscall that does nothing in 400ns or so.  I'll try to make this code emulate real vsyscalls over the weekend.  This was much easier than I expected.

How about the performance of all the statically linked programs? I guess
you just declared they don't matter? gettimeofday is quite critical
and adding a exception into it is just a performance desaster.

Also it's always a dangerous assumption to think that all
programs on Linux use glibc ("all world is a Vax")

In fact more and more of Linux users are using different libcs these
days (like Android or embedded systems or languages with special runtime
systems) Who knows if all those other libraries use vDSO?

And then there are of course the old glibcs. A lot of people
(including me) use new kernels with old userland.

For me this seems like a very risky move -- breaking performance of
previously perfectly good set ups for very little reason.

Given the old vsyscall code is somewhat ugly -- I wouldn't argue that --
but compatibility (including performance compatibility) has always
been importand in Linux and we have far uglier code around in the name of 
compatibility..

And the "security problem" you keep talking about can be fixed
much easier and more compatible as I pointed out.

As far as I'm concered the change is a bad idea.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ