linux-kernel - RE: [PATCH] x86: Hyper-V: register clocksource only if its advertised

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: <542f1d12e3ee46f48a85a143361c113d@SN2PR03MB061.namprd03.prod.outlook.com>
Date:	Fri, 25 Jan 2013 17:39:22 +0000
From:	KY Srinivasan <kys@...rosoft.com>
To:	Olaf Hering <olaf@...fle.de>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	"Jan Beulich (JBeulich@...e.com)" <JBeulich@...e.com>
Subject: RE: [PATCH] x86: Hyper-V: register clocksource only if its
 advertised

> -----Original Message-----
> From: Olaf Hering [mailto:olaf@...fle.de]
> Sent: Friday, January 25, 2013 12:19 PM
> To: KY Srinivasan
> Cc: linux-kernel@...r.kernel.org; Greg KH; Jan Beulich (JBeulich@...e.com)
> Subject: Re: [PATCH] x86: Hyper-V: register clocksource only if its advertised
> 
> On Fri, Jan 25, KY Srinivasan wrote:
> 
> > My fear is that there is no guarantee that Xen would not emulate this
> > feature in the spirit of making Hyper-V emulation "more" complete.
> > Since all this problem is because Xen thinks it is running a viridian
> > domain (when in fact it is running Linux), I felt we should explore
> > why the viridian tag got set for a Linux VM. If we can fix that we
> > would have a solution that does not depend upon assuming that Xen
> > would not emulate a particular Hyper-V feature.
> 
> In my opinion this logic is backwards. A host provides a set of
> functionality/features to a given guest, no matter what runs inside the
> guest. And the guest can query the feature list and configure itself
> accordingly. In this specific case the guest finds feature A (the cpuid
> result) and expects that feature B (a clock source) is present as well,
> even if feature B has its very own availability flag.

I would agree with you in the abstract but not in this specific case. First,
the current Hyper-V code in Linux verifies that the underlying hypervisor is
Hyper-V and proceeds to setup state that is needed to run Linux on Hyper-V.
If Xen were not emulating Hyper-V, we would not have any issue here. However,
Xen does emulate Hyper-V and it is emulating Hyper-V not to run Linux, but to run
enlightened Windows (making Windows think it is running on Hyper-V). We have a 
mechanism in place for controlling this Hyper-V emulation in Xen - the viridian flag.
In my view, ensuring that this flag is not set for a non -Windows guest is the only safe
approach to dealing with this issue. Your current approach of using the "Partition Reference
Counter" feature bit is very fragile. Let us assume that future Windows guests depend on this
feature; Xen would certainly emulate this to have a "good" emulation of Hyper-V and we are
back to square one.

Regards,

K. Y
> 
> Maybe I miss your point.
> 
> Olaf
>