[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] x86/svm: Intercept and terminate RDPRU with #UD

  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Thu, 9 Sep 2021 12:34:00 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6nn9WxfhhUGRAcX7rmQNrfi/mWoK2G/7C/2HhLQ7WOY=; b=FYiBYkeGx3OQQZJ89OuU7acc4J6D++U7fIBg34cPL5vdfYxMnjMsPlYKtTT2MymUBsXeVr2+t6hU8HKkRP0Q+cqBm1p+OB6LPCfSYK5Lwr/wTgfKCGPGRt3qXBOO57kH4+yYuiCTxaXLKqvWwIwazvwgr6qA+3TGp9S/0lGTWObYK3NpuHcnzEcNW3pp1vW056NweAKIefV1UmdcPnNlUoqZqFuVDiezuKvE1osAIyrpy4x1Rom9RSWouwcQmohNYHRIgnG/UWtRKGQcIE+/+pYYEBmmEVjFr2qOwS/rig2AKc3XiobA2UBu1ErqiitPNo1uZKVp7oziT8qSbZM1Wg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cpdw5A444n7/PMecXpNTIFQQRZn8jdW0huYC+tD8hoA0S/v3WxS72Y8/Vx9wcAfPuy4UcdcvHvmD/CRJBoNrqMJjqmfV5cPjFvx02VlbqcunGrv7oudkKvVjA/ypd251cQC98nLWWW1n3fFGmJodBTTSdUcmt39Mnn9Se9BBmqKsEvKOVQXkozc/vwuxKnuUecXz4OUsts7D5vj3l9s19eUfcsdNALPQal2y08n6Zxq/qlwaFMJBvMSqKU0PJ9aSTzbvU031haOhijJj+45Z7HCCuvAsuUnepSzwfSCxmzrZ6F63Eo+5wwtqUdPh3My43YD06cxm9vDVAVihVqqujg==
  • Authentication-results: esa5.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 09 Sep 2021 11:34:17 +0000
  • Ironport-hdrordr: A9a23:Xo7vB6wtOfX9UJFoHCxlKrPxbuskLtp133Aq2lEZdPULSKzo77 HcoB1L736E8UdgZJh/o77wXtjwfZq9z+8Q3WDeB8biYOCGghrpEGgG1/qY/9SOIVyyygcw79 YrT0E6Mqy6MbCV5fyKvTVRPb4bsYO6GeOT9KHjJ04Ed3AwV0gC1XYxNu4veXcGAzWuZ6BJWK Z0vfA34wZIEE5/Bq/LZAhjLpez1ay+qH//W29idmsaAUu1/HuVAdbBYnulN3wlInxyKNkZgC b4e82Q3NTej9iLjjP76k+71eUU6YeRleerx/bntiCkQQ+c0jpAqL4MZ1WO1wpF5d1GGD0R4Z vxSt4bUqsDkQKtDx/F1mqa5yDQlAw243un416Vi3nurIjYQ3YVEMxcnOtiA0Lk13Y=
  • Ironport-sdr: lxtmIx3RJKTlGWXmlpCxSB6eULd/P5BwmRO9hYBjqfvz0P7qrLtW9xtl721yAKGp3SvfBrgdzE 6jr2pKYneGEgH9Pg/sB56syjoGMHXLBBWbtkAH+oWuyTiLybNi8CNtJxWCrrJDYgxLf1YkoHY4 fvl7gOqTOtKYhmYycb70WaXHy5ouY5jZHCSB3TnuLY6DQdYTzhax1prwpHWwBJFVIawhiVDQ0s EOZT9gaS771T2f2LXGMC1eBIhj0dtNFN6pU4gn2Vh5JlWA4++f1/+4VGwC8HjxtmP0xnZSMQR+ rb5qJ7lMBT2KFl1MmAyqm3GN
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 09/09/2021 10:57, Jan Beulich wrote:
> On 08.09.2021 18:19, Andrew Cooper wrote:
>> The RDPRU instruction isn't supported at all (and it is unclear how this can
>> ever be offered safely to guests).
> An implicit hint to me to consider "x86emul: support RDPRU" rejected? That's
> still in my queue waiting for ...
>>  However, a guest which ignores CPUID and
>> blindly executes RDPRU will find that it functions.
>> Use the intercept and terminate with #UD.  While at it, fold SKINIT into the
>> same "unconditionally disabled" path.
>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>> ---
>> CC: Jan Beulich <JBeulich@xxxxxxxx>
>> CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
>> CC: Wei Liu <wl@xxxxxxx>
>> I could have sworn that I'd posted this before, but I can't locate any
>> evidence of it.  I've got a separate patch adding the CPUID infrastructure 
>> for
>> rdpru, but that is better left until we've got more libx86 levelling logic in
>> place.
> ... this. Which - if exposure to guests makes no sense - would seem pretty
> pointless then as well?

Well - given how many people want aperf/mperf, I suspect we might end up
having it as an opt-in only thing, so no - this isn't a rejection of the
x86emul work.

We can *almost* provide a safe way for VM's to use this infrastructure
if we had something like Linux's restartable sequences infrastructure. 
In that case, only an SMI would mess things up, from the guest kernel's

On the other hand, it's probably easier to lobby Intel and AMD for an
interface here which isn't fundamentally broken in the face of NMI/SMI/etc.

>> --- a/xen/arch/x86/hvm/svm/vmcb.c
>> +++ b/xen/arch/x86/hvm/svm/vmcb.c
>> @@ -70,7 +70,8 @@ static int construct_vmcb(struct vcpu *v)
> Some of the other intercepts here suggest it is okay to enable ones
> in the absence of support in the underlying hardware, but I thought
> I'd double check. I couldn't find any statement either way in the PM.
> Assuming this is fine

They're just bits in memory.  Older CPUs will ignore them, and indeed -
pre-RDPRU hardware is fine running with this intercept bit set.

Honestly, I've got half a mind to default the intercepts to ~0 rather
than 0.  For running older Xen on new hardware, it will lead to fewer
unexpected surprises.

> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>





Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.