From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 752C6D116F3 for ; Mon, 1 Dec 2025 14:52:51 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.1175779.1500400 (Exim 4.92) (envelope-from ) id 1vQ5GW-0007aD-Fl; Mon, 01 Dec 2025 14:52:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1175779.1500400; Mon, 01 Dec 2025 14:52:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vQ5GW-0007a6-C6; Mon, 01 Dec 2025 14:52:36 +0000 Received: by outflank-mailman (input) for mailman id 1175779; Mon, 01 Dec 2025 14:52:35 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vQ5GU-0007Zv-Vp for xen-devel@lists.xenproject.org; Mon, 01 Dec 2025 14:52:35 +0000 Received: from PH7PR06CU001.outbound.protection.outlook.com (mail-westus3azlp170100009.outbound.protection.outlook.com [2a01:111:f403:c107::9]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5d301524-cec5-11f0-9d19-b5c5bf9af7f9; Mon, 01 Dec 2025 15:52:32 +0100 (CET) Received: from SN7P220CA0002.NAMP220.PROD.OUTLOOK.COM (2603:10b6:806:123::7) by SJ5PPFDF5E260D0.namprd12.prod.outlook.com (2603:10b6:a0f:fc02::9a6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9366.17; Mon, 1 Dec 2025 14:52:28 +0000 Received: from SA2PEPF0000150A.namprd04.prod.outlook.com (2603:10b6:806:123:cafe::b1) by SN7P220CA0002.outlook.office365.com (2603:10b6:806:123::7) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9366.17 via Frontend Transport; Mon, 1 Dec 2025 14:52:28 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SA2PEPF0000150A.mail.protection.outlook.com (10.167.242.42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9388.8 via Frontend Transport; Mon, 1 Dec 2025 14:52:28 +0000 Received: from localhost (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Mon, 1 Dec 2025 08:52:27 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5d301524-cec5-11f0-9d19-b5c5bf9af7f9 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=nTYH/clSaopUKzLl0I9afAr++7RLDdvp+kaPda1y1cy8WsOFFlFNQggipN/QcpQkRtFfdZUMa4AXirCsXLnR/8LGKPOpQvowVDw0skO5HgI1z2LpDWzv/PoqXeXabKsPr+FzvNCjfo61o42NVIKgyZ9bwcHK3zt/9zgl8Qj+u7SmE3dhth8nNcdzClsWocwPXZMcxpbYtkBtTqbt9NZrMf39sbn1ccV/lP60HiLUzBoV8+7JGz2U/BxUZfR+/tYgeZPjHHKvCsiTNYpm4/7swHZIOMro8lpZdeSbsUVkNyAS2gTPj1SPa97Gbt2Do23LNMlp/bs4EIFgPO4JqfPDsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=yOY/Avr0hMF8iRDljlBhbQHWq1KQbIodyYkw40oSnBQ=; b=hZy7hxsg6C12jtyJe5AZY3i1TdXgbSU8Sd8MZgSr5yaK1ygwZSZSIxtS5hURuHpzn4oDwI1CEpwDD92zA98SPz2yS/Kuu7PsNp0O6GVfh++GoJNkpg/Fe0XNz/tl9YxYzoUIGphodfwF215qwPxz7Mdi/bNG+cbigWf5texEiY3+lb5gflmtg4Xcy7FLYOY0ISeeVNdj/oi8NuuZIrSkyBKWVaXervNKoZ+TuATu1zMvA4AVy7y9EYVQsWQ8a1UwB8nZStxHntXKOnUHKOfXs/V0kYTDQPgM3jp7XPBWhovS6h5H2PJi3fUoRkXvIWlVTerHjt3JKlXrsI5Lwpe/Ig== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=citrix.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yOY/Avr0hMF8iRDljlBhbQHWq1KQbIodyYkw40oSnBQ=; b=kYh7FijPXnl3xW35cI8iTwVkCm+rHmJJnqPVtCaS1m6lmuddlMGQZOYbSArPZdmXmyPGxP/f8sjAasvmyhGkdL8c9rpIJCex9EupMeGF8zMSoB60ELuIkliVmq4vrtepyVTLe/VBTcaxPVIxgDhfSLHeYgt+3MHebqoM9HFFz+8= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Date: Mon, 1 Dec 2025 15:52:25 +0100 Message-ID: CC: Jan Beulich , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Xen-devel Subject: Re: [PATCH] x86/hvm: Unilaterally inject #UD for unknown VMExits From: Alejandro Vallejo To: Andrew Cooper , Xen-devel X-Mailer: aerc 0.20.1 References: <20251128174735.1238055-1-andrew.cooper3@citrix.com> In-Reply-To: <20251128174735.1238055-1-andrew.cooper3@citrix.com> X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SA2PEPF0000150A:EE_|SJ5PPFDF5E260D0:EE_ X-MS-Office365-Filtering-Correlation-Id: d865f9c9-1292-4f0a-df4a-08de30e93f7e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|36860700013|1800799024|82310400026; X-Microsoft-Antispam-Message-Info: =?utf-8?B?ZDN3dTlocmZ2WEgwalBZaXczTGVCQmdlT3hGWHFsY3huU3h4aGZqZ1ViTHBl?= =?utf-8?B?QmhwRlh3U2dtcWpzbWlRTnoxdkI5ZkxLVUM1TGdhYkptRjVXeDlaZUhTRXgx?= =?utf-8?B?NVYvQytnVUcrVWJvZlhnTThzNUR5VGxPR011OHphMUEyUXFqaWJJM2dYZGJv?= =?utf-8?B?RS9adHp5UW8yYm53Zk1YMmNUUlRPdVdBMWEvWFd0NFZzYnJULzJudzVyUXlw?= =?utf-8?B?ZTUzZktNZ0R4UEM3MHZFRU9EZVBDR051SXhmS29OSEZkdjVrelhia1I4eXli?= =?utf-8?B?Y2ZMd2RDMC9nMTFFM3pQM1JENTNNaG5pbU9jbWtCdWhiT09qcXVxVmFqN29H?= =?utf-8?B?ODZ6TVZJa1pwOWpWcUlxZS9QdHh3RTdQZEdZWlZLMkx6OGFvVWpJZ2Z1c0ZN?= =?utf-8?B?ek5WQVlDejFBVnBpWGJYN2JSd3YzTnB2VzhSVXNEemhCeUR2RlJZQnZqNm1E?= =?utf-8?B?bEdQL2hqbDZQK1VGLzh6QWxNSjFUUEhHajdabHNPL1NVaDg4bWpRdFMvdm5j?= =?utf-8?B?eU1DWTY2MWlaLzhEd3pzbTJMYTFRVHczVVJPa2krdW9DcW5tVnoydldiOFp3?= =?utf-8?B?WStkcjVGWjEvWDJxTGFaY0dVcHJFdjE2dXlXeWd5enpYOWdWTUN6WC9ucUdU?= =?utf-8?B?bTdteGhHUyt4cisrellGVXNFZnRMUUxRaVcvUFVvNmh4NnptdThRQkxuUWQw?= =?utf-8?B?aUpvSEM2eXFsYXNVODU4MmVIWVIwK24ybGgzYjhnaEY0dzJ5VmVSVU5xVGNU?= =?utf-8?B?ZnZQcC9hMFZaTE92QW9DQTBMQU5kQ1d6NTRhbjFkNytWUUpVSmpUYllrWGE0?= =?utf-8?B?aDZKWUhhUkdHZGgyaTc0L2lpcklxc0ZWNk9ESkF4d3IwY09BZzdTYUdDRTV3?= =?utf-8?B?Z2NWK0NUSVJjUWxjNDdERGJubHE4RjdIV09LYk5JRU9nek5QcjJrNDI2c0dN?= =?utf-8?B?QTNNenJwMDQyZWJSOUd1Q002cmxyWlVqS0k0Q3FNSXI1a1V6N1RCQTFlVmZU?= =?utf-8?B?NnFISDlacVFnQVF0eGVLWmVpdmR2Z0pVVXd6SGRHUGhRUWp5ZVA0WG5VRVZK?= =?utf-8?B?N3Y5MnBLNmcyZDFQTlV4Mk9UTWZrbEt3eWtKb0VqNVBRNUpoTmVMQWdCTHh1?= =?utf-8?B?MWV1MnQvY1NQdnVoQUhlZStaSE9jWjJoSTB2dUdnd1J1bVdaVEszeVB3WkxD?= =?utf-8?B?Yk9ORkJJMzNwZm1UMkFQYzRDQkorNjg2MjQrR3lSZTU3L2RLNDljYzUyZFlP?= =?utf-8?B?SFNOcEtDVzhRNjE3ZCtPRFNiaHBBVlVoeHpHSzBNVGtXVmY1cG5xSjZNdlpj?= =?utf-8?B?TFMxNjR0SXlYRjMwQW5Yb1NveFhDZXIyM3hTZk10QmpsZmhCcml3V3NYYWxp?= =?utf-8?B?TE1zaEN1ZG9QalJGVEQzZVFZeVNYcUtaTHllemJaMHBIRjRjMDJGK3E0b3pn?= =?utf-8?B?NGtrNGhpN2l0V0drdmlDSEtzdXg4enhReENaYnQxVzRyaGZyWlF4amd2OWE1?= =?utf-8?B?d254ZFNLMWpYb1ZqbVh5UGJXQjZUNFc0RDlOWXdydjBVaGhLQlY3cVRhTXFa?= =?utf-8?B?aVJTTkhOR1RkVUVId1ExRkdaNFJyazlZbkN5dCt6a0phZHY3enR3b25mOTZp?= =?utf-8?B?MWNmTzc0WlR4N0RQVUV6S2poR0swOHUyKy9NVVpkdGFKVHlZSGdXUkJWTTVV?= =?utf-8?B?OCs4ZnRnUzlSZnkrellhakU5dnpUMGhWSmFQVGtYc2VIV2taZ29TZWZjK0VM?= =?utf-8?B?Q3p6TUFmZEorWHdzTkpmcERrdzlHdExXanE2b2VDRTZIcStiTDFtazdhcmhm?= =?utf-8?B?WUFUL2pqaTVDNkp5VXhQZStiQTZvaVRqZHZCNXY5aFpGVnNaSGVuUkloSXRU?= =?utf-8?B?TmI2U2Q1Y3BTeWh3eU01akp0MjJZNUwwZEdOYU00NXlvbzJNdmM4NEFvSm9G?= =?utf-8?B?VGNCTHU4Z0w2dHBSL2xZZGlMNGtGZGpLWU84ano4dE9MeWRxMHBYY2JnVStQ?= =?utf-8?B?Rnl0UGVqOGo0cUR1VjRRYmJGRFUzYmoxOW5mY2U1dWprcmFEWGg3aTEvdzRu?= =?utf-8?B?V1Z4OWZ5YW9FK3JOVnp3TDFVQTlZNU5CZG00UE4wdTIyUmNJV1Q3ZC9pZUdV?= =?utf-8?Q?4HOI=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(1800799024)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Dec 2025 14:52:28.3331 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d865f9c9-1292-4f0a-df4a-08de30e93f7e X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SA2PEPF0000150A.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ5PPFDF5E260D0 On Fri Nov 28, 2025 at 6:47 PM CET, Andrew Cooper wrote: > While we do this for unknown user mode exits, crashing for supervisor mod= e > exits is unhelpful. Intel in particular expect the unknown case to be #U= D > because they do introduce new instructions with new VMEXIT_* codes withou= t > other enablement controls. e.g. MSRLIST, USER_MSR, MSR_IMM, but AMD have > RDPRU and SKINIT as examples too. I don't know how often Intel adds intercepts (or whatever the VMX equivalen= t is) without default-off knobs, but there's a potentially dangerous assumption h= ere about all intercepts being synchronous with the executed instruction. Some = might depend on other events (i.e: NMIs, IRQs, IPIs, etc) and injecting #UD in th= ose cases would be very insecure for the guest. It might encourage the kernel t= o interpret the current instruction that the kernel can't know wasn't meant t= o ever trigger #UD. This would be an integrity-compromising mistake to make. IOW, I think this is a dangerous default to have and Xen should just crash = the domain irrespective of CPL. At least on SVM. If a guest executes SKINIT and= it doesn't exist=20 > > A guest which gets its CPUID checks wrong can trigger the VMExit, and the > VMexit handler would need to emulate the CPUID check and #UD anyway. Thi= s > would be a guest bug, and giving it an exception is the right course of > action. You you need a guest bug compounded with an outdated hypervisor to reproduc= e the crash, and even then it's perfectly benign. Beats the alternative described above, IMO. > > Drop the "#UD or crash" semantics and make it exclusively #UD. Rename th= e > lables to match the changed semantics. Fold the cases which were plain #= UD's > too. nit: typo s/lables/labels Also, does why emacs double spaces after each sentence on reflow? You have = them in a number of places. > > One case that was wrong beforehand was EPT_MISCONFIG. Failing to resolve= is > always a Xen bug, and not even necesserily due to the instruction under %= rip. > Convert it to be an unconditional domain_crash() with applicable diagnost= ic > information. One example of the above synchronous vs asynchronous events. > > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Roger Pau Monn=C3=A9 > --- > xen/arch/x86/hvm/svm/svm.c | 29 +++++++++-------------------- > xen/arch/x86/hvm/vmx/vmx.c | 26 +++++++++++--------------- > 2 files changed, 20 insertions(+), 35 deletions(-) > > diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c > index 2d7c598ffe99..637b47084c25 100644 > --- a/xen/arch/x86/hvm/svm/svm.c > +++ b/xen/arch/x86/hvm/svm/svm.c > @@ -66,15 +66,6 @@ static bool amd_erratum383_found __read_mostly; > static uint64_t osvw_length, osvw_status; > static DEFINE_SPINLOCK(osvw_lock); > =20 > -/* Only crash the guest if the problem originates in kernel mode. */ > -static void svm_crash_or_fault(struct vcpu *v) > -{ > - if ( vmcb_get_cpl(v->arch.hvm.svm.vmcb) ) > - hvm_inject_hw_exception(X86_EXC_UD, X86_EVENT_NO_EC); > - else > - domain_crash(v->domain); > -} > - > void __update_guest_eip(struct cpu_user_regs *regs, unsigned int inst_le= n) > { > struct vcpu *curr =3D current; > @@ -85,7 +76,7 @@ void __update_guest_eip(struct cpu_user_regs *regs, uns= igned int inst_len) > if ( unlikely(inst_len > MAX_INST_LEN) ) > { > gdprintk(XENLOG_ERR, "Bad instruction length %u\n", inst_len); > - svm_crash_or_fault(curr); > + hvm_inject_hw_exception(X86_EXC_UD, X86_EVENT_NO_EC); This seems more than fair enough. > return; > } > =20 > @@ -2872,7 +2863,7 @@ void asmlinkage svm_vmexit_handler(void) > * task switch. Decode under %rip to find its length. > */ > if ( insn_len < 0 && (insn_len =3D svm_get_task_switch_insn_len(= )) =3D=3D 0 ) > - goto crash_or_fault; > + goto inject_ud; And so does this (semantically). > =20 > hvm_task_switch(vmcb->ei.task_switch.sel, > vmcb->ei.task_switch.iret ? TSW_iret : > @@ -2984,13 +2975,6 @@ void asmlinkage svm_vmexit_handler(void) > svm_vmexit_do_rdtsc(regs, exit_reason =3D=3D VMEXIT_RDTSCP); > break; > =20 > - case VMEXIT_MONITOR: > - case VMEXIT_MWAIT: > - case VMEXIT_SKINIT: > - case VMEXIT_RDPRU: > - hvm_inject_hw_exception(X86_EXC_UD, X86_EVENT_NO_EC); > - break; > - > case VMEXIT_VMRUN: > svm_vmexit_do_vmrun(regs, v, regs->rax); > break; > @@ -3083,8 +3067,13 @@ void asmlinkage svm_vmexit_handler(void) > gprintk(XENLOG_ERR, "Unexpected vmexit: reason %#"PRIx64", " > "exitinfo1 %#"PRIx64", exitinfo2 %#"PRIx64"\n", > exit_reason, vmcb->exitinfo1, vmcb->exitinfo2); > - crash_or_fault: > - svm_crash_or_fault(v); > + fallthrough; > + case VMEXIT_MONITOR: > + case VMEXIT_MWAIT: > + case VMEXIT_SKINIT: > + case VMEXIT_RDPRU: > + inject_ud: > + hvm_inject_hw_exception(X86_EXC_UD, X86_EVENT_NO_EC); I understand monitor, mwait, skinit and rdpru triggering #UD, but in the default case (and we're also covering "default" out of context) injecting #= UD might be meaningless, plain wrong or highly misleading (e.g: imagine receiv= ing #UD on IRQ). VMEXITs happen due to optional or mandatory intercepts about synchronous and asynchronous events. If Xen receives a VMEXIT it doesn't understand the ideal would be to BUG(), because they don't just come out of= thin air. You're meant to enable the intercepts in the VMCB. For defensive purpo= ses a domain_crash() would be fine too, as it partly is now. I don't understand the CPL distinction. The kernel might trigger highly dangerous and integrity-compromising paths if it chooses to interpret #UD and it happens = to to be an externally triggered event rather than something related to the curre= nt instruction. (dropped VMX, because I don't know about it) Cheers, Alejandro