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

> > I'm still not sure if you are in favor of optionally emulating
> > PL3 rdtsc instructions or not?  I thought my proposal was
> > just filling out some details of your proposal and suggesting
> > a default.
> 
> I'm not in favor of emulating rdtsc instructions.  I would consider
> letting them SIGILL (actually SIGSEGV since RDTSC #GP in userspace)
> 
> It's not clear to me that it's possible, though, since that also
> affects RDTSCP.

(All the variations are boggling so hard to discuss in
a linear email thread.)

IIUC, tglx/arjan consider RDTSC and RDTSCP to be in the same
category.  RDTSCP simply eliminates one large class of TSC
problems, but not all the possible system TSC problems that
the kernel can (or can't) detect.  So userspace (non-vsyscall)
shouldn't use either one

Further, this one redeeming feature of RDTSCP can be useless
and/or misleading in a virtual machine the way the kernel
sets up TSC_AUX.

> when the TSC is unavailable, though.

Do you mean "when the processor doesn't support a TSC instruction"
(very rare nowadays AFAIK) or "when the kernel determines that
TSC is not safe to use as a clocksource"?
--
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