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]

Message-ID: <b190a20b-6420-4bd0-a261-f66c520ae983@default>
Date:	Mon, 17 May 2010 16:33:20 -0700 (PDT)
From:	Dan Magenheimer <dan.magenheimer@...cle.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Arjan van de Ven <arjan@...radead.org>,
	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: Thomas Gleixner [mailto:tglx@...utronix.de]
> 
> On Mon, 17 May 2010, Dan Magenheimer wrote:
> >
> > OK, so let's invert the sense of the sysfs file and call it (for now)
> > "tsc_detected_as_UNreliable".  Then anytime the kernel detects
> > a failed warp test (or any other suspicious condition), it changes
> > the bit from 0 to 1 effectively saying "if you are using rdtsc
> > against our recommendation, we told you that it might go bad and
> > it has, so consider yourself warned that some of the timestamps
> > you've taken since the last time you've checked this flag
> > may be b*rked"
> >
> > IMHO, addressing the issue directly and clearly documenting it
> > (instead of trying to hide the dirty laundry in the kernel)
> > will result in far better education of systems programmers
> > and far fewer end user problems. Which raises another good analogy:
> >
> > You are telling teenagers to abstain and I am proposing that we
> > instead encourage them to use a condom.
> 
> Wrong. A vsyscall _is_ the protection which you want them to pull over
> the rdtsc.
> 
> You are basically telling them: Go ahead, but keep in mind to look for
> that well hidden tag behind the left earlobe which might change
> suddenly from "no disease" to "infectous".

OK, well ignoring the metaphor, it's clear we disagree on a point
that neither one of us can prove: You think your decision to avoid
sharing kernel information will stop system programmers from using
rdtsc, and I think some are going to use rdtsc anyway and blame
Linux when something eventually and silently breaks.

Given that I'm not going to win this argument even by pointing
to examples, let's move forward with your solution.  Can you say
more about your vget_tsc_raw() directions?  Or at least describe
the API if there is anything special?  I'm getting beaten on for
an answer *today*, they say (and I quote from an email today)
they "have been using vsyscalls for a while and still have a
performance headache", and rdtsc looks awfully tempting, even
if it is not 100% perfect.  So what can I give them as an
alternative?

(And, yes, I understand this is not your problem, but I do worry
that it is perceived as *Linux's* problem.  And as we all have
painfully learned in our careers, it's almost impossible to
beat back a perception by presenting a set of byzantine facts
that only a handful of people in the world truly understand.)

Thanks!
Dan
--
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/