linux-kernel - Re: [PATCH] Skip tsc synchronization checks if CONSTANT

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:	Fri, 24 Oct 2008 08:30:28 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Andi Kleen <andi@...stfloor.org>
CC:	akataria@...are.com, Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>,
	the arch/x86 maintainers <x86@...nel.org>,
	Daniel Hecht <dhecht@...are.com>
Subject: Re: [PATCH] Skip tsc synchronization checks if CONSTANT_TSC bit is
 set.

Andi Kleen wrote:
>> That is at least to some degree nonsense, simply because we are all well 
>> down that particular "slippery slope": we have hardware blacklists and 
> 
> The big difference is that hardware cannot be easily fixed, hypervisors
> are just software and can as simply as Linux. Also there are at least 
> standardized simple ways to detect hardware and platforms using standard 
> enumeration interfaces like PCI or DMI, while each Hypervisor detection 
> seems to need huge amounts of custom (and likely fragile) complicated code.
> iirc there was a vmware detection patch around and it was disgusting iirc.
> 

BIOSes are also just software, and we have to deal with bugs in them 
*all the time*.  The reality is that we're going to have to deal with 
both vendor and user reluctance to upgrade, and therefore have to deal 
with brokenness in the field.  As far as detection code is concerned, I 
certainly have pushed back on the most disgusting (and broken) attempts, 
as well insisted that the code be properly centralized.

> Also I think this concept of "not PV, but then again a little"
> concept that is mandated here is not a useful one.
 >
> Either do a proper PV interface and then just write a custom
> clock driver and paravirt ops interface to make everything really fast,
> or just use the direct hardware interface and fix the hypervisor
> to do it properly.

It's functionally equivalent to hardware workarounds.  There is always a 
judgement call when something should be forked off into a separate 
driver, which is exactly what this amounts to.

> Especially VMware has this already (although 32bit only).
> 
> Ok the tsc_sync issue is borderline, but that one seems 
> to be more a case of tweaking the existing algorithms
> to be a little more tolerant.

That is a possibility, but that is a technical issue versus a 
pseudo-philosophical issue.  However, there are clearly a few different 
problems here with the start-and-stop nature of the virtual environment 
versus the needs of physical environments, and it's not clear to me that 
they are inherently compatible, or whether that would entail dangerous 
compromises.

	-hpa

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