From nobody Mon Apr 13 15:48:44 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 01988C4332F for ; Mon, 14 Nov 2022 16:50:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238065AbiKNQu4 (ORCPT ); Mon, 14 Nov 2022 11:50:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59264 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236205AbiKNQua (ORCPT ); Mon, 14 Nov 2022 11:50:30 -0500 Received: from smtp-fw-80006.amazon.com (smtp-fw-80006.amazon.com [99.78.197.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5A0B62FC03; Mon, 14 Nov 2022 08:49:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209; t=1668444574; x=1699980574; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=W/HB3Xe0IyEpEgjwwlHeRnwekQHUqIvwFTZpMp6G+lM=; b=MYO5uvfaSqroRvZ+kbNFu8HME5ahb2CYN+S5Aa73qb01yHrQliB4VfOW rFWfzOth9iYlZ6Z9prGPptvaK0oJeulDefCrDbROUUsLRObnNza0oShLS DGe1nad1iQ4ComO0j9L6et6ol2aHcm5Cb8cZ3/kJFRL2+LP9UJsZroAqQ E=; X-IronPort-AV: E=Sophos;i="5.96,164,1665446400"; d="scan'208";a="150552225" Received: from pdx4-co-svc-p1-lb2-vlan2.amazon.com (HELO email-inbound-relay-pdx-2b-m6i4x-26a610d2.us-west-2.amazon.com) ([10.25.36.210]) by smtp-border-fw-80006.pdx80.corp.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Nov 2022 16:49:23 +0000 Received: from EX13D06EUC001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan2.pdx.amazon.com [10.236.137.194]) by email-inbound-relay-pdx-2b-m6i4x-26a610d2.us-west-2.amazon.com (Postfix) with ESMTPS id D197041726; Mon, 14 Nov 2022 16:49:18 +0000 (UTC) Received: from EX19D033EUC002.ant.amazon.com (10.252.61.215) by EX13D06EUC001.ant.amazon.com (10.43.164.225) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Mon, 14 Nov 2022 16:49:17 +0000 Received: from dev-dsk-hborghor-1a-30381df9.eu-west-1.amazon.com (10.43.162.178) by EX19D033EUC002.ant.amazon.com (10.252.61.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.1118.20; Mon, 14 Nov 2022 16:49:13 +0000 From: Hendrik Borghorst To: CC: , Sean Christopherson , Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , , "H. Peter Anvin" , , Subject: [PATCH] KVM: x86/vmx: Do not skip segment attributes if unusable bit is set Date: Mon, 14 Nov 2022 16:48:23 +0000 Message-ID: <20221114164823.69555-1-hborghor@amazon.de> X-Mailer: git-send-email 2.37.1 MIME-Version: 1.0 X-Originating-IP: [10.43.162.178] X-ClientProxiedBy: EX13D21UWB001.ant.amazon.com (10.43.161.108) To EX19D033EUC002.ant.amazon.com (10.252.61.215) Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" When serializing and deserializing kvm_sregs, attributes of the segment descriptors are stored by user space. For unusable segments, vmx_segment_access_rights skips all attributes and sets them to 0. This means we zero out the DPL (Descriptor Privilege Level) for unusable entries. Unusable segments are - contrary to their name - usable in 64bit mode and are used by guests to for example create a linear map through the NULL selector. VMENTER checks if SS.DPL is correct depending on the CS segment type. For types 9 (Execute Only) and 11 (Execute Read), CS.DPL must be equal to SS.DPL [1]. We have seen real world guests setting CS to a usable segment with DPL=3D3 and SS to an unusable segment with DPL=3D3. Once we go through an sregs get/set cycle, SS.DPL turns to 0. This causes the virtual machine to crash reproducibly. This commit changes the attribute logic to always preserve attributes for unusable segments. According to [2] SS.DPL is always saved on VM exits, regardless of the unusable bit so user space applications should have saved the information on serialization correctly. [3] specifies that besides SS.DPL the rest of the attributes of the descriptors are undefined after VM entry if unusable bit is set. So, there should be no harm in setting them all to the previous state. [1] Intel SDM Vol 3C 26.3.1.2 Checks on Guest Segment Registers [2] Intel SDM Vol 3C 27.3.2 Saving Segment Registers and Descriptor-Table Registers [3] Intel SDM Vol 3C 26.3.2.2 Loading Guest Segment Registers and Descriptor-Table Registers Cc: Alexander Graf Signed-off-by: Hendrik Borghorst Reviewed-by: Alexander Graf Reviewed-by: Jim Mattson --- arch/x86/kvm/vmx/vmx.c | 21 +++++++++------------ 1 file changed, 9 insertions(+), 12 deletions(-) diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index 63247c57c72c..4ae248e87f5e 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -3412,18 +3412,15 @@ static u32 vmx_segment_access_rights(struct kvm_seg= ment *var) { u32 ar; =20 - if (var->unusable || !var->present) - ar =3D 1 << 16; - else { - ar =3D var->type & 15; - ar |=3D (var->s & 1) << 4; - ar |=3D (var->dpl & 3) << 5; - ar |=3D (var->present & 1) << 7; - ar |=3D (var->avl & 1) << 12; - ar |=3D (var->l & 1) << 13; - ar |=3D (var->db & 1) << 14; - ar |=3D (var->g & 1) << 15; - } + ar =3D var->type & 15; + ar |=3D (var->s & 1) << 4; + ar |=3D (var->dpl & 3) << 5; + ar |=3D (var->present & 1) << 7; + ar |=3D (var->avl & 1) << 12; + ar |=3D (var->l & 1) << 13; + ar |=3D (var->db & 1) << 14; + ar |=3D (var->g & 1) << 15; + ar |=3D (var->unusable || !var->present) << 16; =20 return ar; } --=20 2.37.1 Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879