linux-kernel - RE: [PATCH] x86: Export tsc related information in sysfs

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, 18 May 2010 08:13:34 -0700 (PDT)
From:	Dan Magenheimer <dan.magenheimer@...cle.com>
To:	Peter Zijlstra <peterz@...radead.org>,
	Andi Kleen <andi@...stfloor.org>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Venkatesh Pallipadi <venki@...gle.com>,
	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	chris.mason@...cle.com, linux-kernel@...r.kernel.org
Subject: RE: [PATCH] x86: Export tsc related information in sysfs

> From: Peter Zijlstra [mailto:peterz@...radead.org]
> Subject: Re: [PATCH] x86: Export tsc related information in sysfs
> 
> On Tue, 2010-05-18 at 13:25 +0200, Andi Kleen wrote:
> > On Tue, May 18, 2010 at 11:58:18AM +0200, Peter Zijlstra wrote:
> > > On Sun, 2010-05-16 at 22:06 -0700, Arjan van de Ven wrote:
> > > > look we're not disabling ring 3 tsc. We could, but we don't.
> > >
> > > Maybe we should.
> >
> > That would kill the vsyscall too. Remember it's running in ring 3.
> >
> > That is in theory you could disable it on systems where the vsyscall
> > doesn't use it, but then you would likely break huge amounts of
> software,
> > unless you emulate it.
> 
> Well, software shouldn't use it, so breaking it sounds like a fine
> idea ;-)

Last fall, I discovered that EVERY program on RHEL5 (U2?) uses rdtsc
because RHEL5 ld.so uses rdtsc.  The uses are few and harmless but
are there nonetheless.  Clearly that can be fixed, but you might
be surprised how big "huge amounts of software" is.

> Also, a slow emulation is an incentive to actually do the right thing.

Emulation is not particularly slow, especially compared to accessing
the HPET.  If the kernel deems TSC is unsafe, the ring 3 vsyscall
shouldn't be using rdtsc either so the additional trap overhead
might be in the noise.

As long as there is a sysfs file that can override the setting
and there is a counter (accessible via sysfs) that can count
the number of emulated rdtsc/rdtscp instructions (possibly
optionally by pid so the "offending" userland threads can
be tracked down), setting CR4.TSD whenever the kernel deems
TSC is unsafe and emulating rdtsc might be a reasonable solution.
Infrequent rdtsc users won't know or care, and frequent users
will at least be able to learn the frequency of their "sin".

And to help Thomas/Arjan/Ingo/Andi educate users, every read
or write to any of these sysfs files could also result in a
printk of "Use of rdtsc is deprecated... use vsyscalls instead.
See Documentation/friends_dont_let_friends_use_rdtsc."
(Half ;-)

And the sysfs file could have a "strict" setting which kills any
thread that uses rdtsc, so Thomas can tell future problem
reporters: "Set the rdtsc setting to strict and if you still
have problems, call me back."  (Other half of ;-)
--
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/