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: <20081024072320.GE27492@one.firstfloor.org>
Date:	Fri, 24 Oct 2008 09:23:20 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Andi Kleen <andi@...stfloor.org>, 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.

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

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.

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.

-Andi
-- 
ak@...ux.intel.com
--
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