From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: citrix.com, ip: 216.71.155.168, mailfrom: roger.pau@citrix.com) Received: from esa5.hc3370-68.iphmx.com (esa5.hc3370-68.iphmx.com [216.71.155.168]) by groups.io with SMTP; Wed, 07 Aug 2019 08:03:54 -0700 Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=roger.pau@citrix.com; spf=Pass smtp.mailfrom=roger.pau@citrix.com; spf=None smtp.helo=postmaster@mail.citrix.com Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender authenticity information available from domain of roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com; envelope-from="roger.pau@citrix.com"; x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of roger.pau@citrix.com designates 162.221.158.21 as permitted sender) identity=mailfrom; client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com; envelope-from="roger.pau@citrix.com"; x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83 ~all" Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender authenticity information available from domain of postmaster@mail.citrix.com) identity=helo; client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com; envelope-from="roger.pau@citrix.com"; x-sender="postmaster@mail.citrix.com"; x-conformance=sidf_compatible IronPort-SDR: tW2fyX3Fh+Ynrspd+qFTc0r9VJP7Wm02H/9vHcQw9UEW4zMugq6mBe6pNbkM/ZMMdGbJ5Jq0DT 9goyGNbyiY5Mkv8qfvTeekij86VQuggDdK8svKhXQYj/acmjUUbHVVNOoGZs56byCv5Y7u+qSa oRpsOw9zkxZ/DNwF1eYxZ6wSODzPQt8psdchJN67CXQHzwb6sDzG9unA7JQQQERoR5jvx99s15 6jZ0tF4b1Kq4auyrDgiN10zZHKJjTzztrGW207sO7ueLLTebbnkx+VsB2v3aEopcrKVRNi83lf Qwg= X-SBRS: 2.7 X-MesageID: 4115552 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.64,357,1559534400"; d="scan'208";a="4115552" Date: Wed, 7 Aug 2019 17:03:46 +0200 From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= To: , CC: Julien Grall , , Jordan Justen , Ard Biesheuvel , Laszlo Ersek Subject: Re: [edk2-devel] [PATCH v4 20/35] OvmfPkg/XenPlatformPei: Introduce XenPvhDetected Message-ID: <20190807150346.upizhcngos3prol4@Air-de-Roger> References: <20190729153944.24239-1-anthony.perard@citrix.com> <20190729153944.24239-21-anthony.perard@citrix.com> MIME-Version: 1.0 In-Reply-To: <20190729153944.24239-21-anthony.perard@citrix.com> User-Agent: NeoMutt/20180716 Return-Path: roger.pau@citrix.com X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline On Mon, Jul 29, 2019 at 04:39:29PM +0100, Anthony PERARD wrote: > XenPvhDetected() can be used to figure out if OVMF has started via the > Xen PVH entry point. > > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 > Signed-off-by: Anthony PERARD > Acked-by: Laszlo Ersek Thanks, I've got a comment, but it can be fixed afterwards if required. > --- > OvmfPkg/XenPlatformPei/Platform.h | 5 +++++ > OvmfPkg/XenPlatformPei/Xen.c | 13 +++++++++++++ > 2 files changed, 18 insertions(+) > > diff --git a/OvmfPkg/XenPlatformPei/Platform.h b/OvmfPkg/XenPlatformPei/Platform.h > index 4a80057bdc..db9a62572f 100644 > --- a/OvmfPkg/XenPlatformPei/Platform.h > +++ b/OvmfPkg/XenPlatformPei/Platform.h > @@ -99,6 +99,11 @@ XenHvmloaderDetected ( > VOID > ); > > +BOOLEAN > +XenPvhDetected ( > + VOID > + ); > + > VOID > AmdSevInitialize ( > VOID > diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c > index 29b42b746c..71fe5de446 100644 > --- a/OvmfPkg/XenPlatformPei/Xen.c > +++ b/OvmfPkg/XenPlatformPei/Xen.c > @@ -214,6 +214,19 @@ XenHvmloaderDetected ( > return (mXenHvmloaderInfo != NULL); > } > > +BOOLEAN > +XenPvhDetected ( > + VOID > + ) > +{ > + // > + // This function should only be used after XenConnect > + // > + ASSERT (mXenInfo.VersionMajor != 0); That's IMO dangerous. Using the version as an indication that XenConnect has run seems like a bad idea, since returning a major version of 0 is a valid number to return. Can't you check against something else that doesn't depends on hypervisor provided data? (ie: like some allocations or such that happen in XenConnect) A paranoid could provider could even return major == 0 and minor == 0 in order to attempt to hide the Xen version used, since guests are not supposed to infer anything from the Xen version, available hypervisor features are reported by other means. Thanks, Roger.