Message ID | 20231016132819.1002933-5-michael.roth@amd.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp3473657vqb; Mon, 16 Oct 2023 06:49:49 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGgIzLzG4+LgtNOVb2Dvc/W91UBgH4ZX4L9E7P+RHvrSahU9zf/iSHUWS+mYxMXlqcpuE2p X-Received: by 2002:a17:902:e5d2:b0:1c4:1cd3:8062 with SMTP id u18-20020a170902e5d200b001c41cd38062mr38627234plf.2.1697464189554; Mon, 16 Oct 2023 06:49:49 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1697464189; cv=pass; d=google.com; s=arc-20160816; b=glR/UMOpqhDMhG5SOU/QQT5lx+ZfN/kY9C2z00eiQK7Z5oDDjRSQ7slArCFXiccfOE pKX9MAxQEfXcH5yXwbNvy0XX7Aif8jCJyd++6mY38XWlvQUE6bJrlAp2/2FUtuHU5DKM 1p22xcd/EWNBygXX6CmoDXUiQQFK1KSziMg9f5+ZjfHFxlIq7VONpbS+qqVj+ZcwOGDV Lub0uVsK7SXrJHM7yyuTSA3votjDbgqwdyguRv749HdFJjK37d5LbxbcZ8hru5QE37pU XzhCCtsFVH5yeIBBxwGuY3VFgGFiymA9XJwdE2+b5OZg2X/Q8gJeOgbsKIcSl1s/tNiE rvvg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=3+JCtj3ASOKkhljKB2Eu8gzmxNkQyvn/YzFk7ZCXbFg=; fh=oGe+EVJn4rd8fUFEyuJgyJjUcTaHwe+JNwigxKGM8gU=; b=pIvPTttMF9xSZvj7yZpnEF2IXRsFOafrAnjpGcQ4bTNBDA3+fS3fEt/N+i3emQee01 qj/ke2smiv4yzKzf1FujosMdy7GxWpn50PJ6PG2tYPGPpm1njSL2UbQs/oZ9W2H2p9M2 XdHgYsveV94hFeXbYOR5kqHZCOp3flCgJV+C0aslZYYooNwPjZKaYZNOHvQ1kdGcHiSd iAH+3OTZlVaYP39BmmxMULcLKTX5jUfkFTkwi8ZLNX7d9U43Q802SSqZJ8y3ll85MlLk 1ZsQ7wlSMCxviXAAtkJU5feyBwJPqKwKcajk2fnD+qSlzmLmb98njesqehMdY0KlU5vp 10Mg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@amd.com header.s=selector1 header.b=nMrUdFpa; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: from agentk.vger.email (agentk.vger.email. [2620:137:e000::3:2]) by mx.google.com with ESMTPS id x18-20020a170902ec9200b001c58401354dsi6054635plg.565.2023.10.16.06.49.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Oct 2023 06:49:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2; Authentication-Results: mx.google.com; dkim=pass header.i=@amd.com header.s=selector1 header.b=nMrUdFpa; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id 18B62804C4A8; Mon, 16 Oct 2023 06:49:43 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234042AbjJPNtX (ORCPT <rfc822;hjfbswb@gmail.com> + 18 others); Mon, 16 Oct 2023 09:49:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53368 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233864AbjJPNsv (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 16 Oct 2023 09:48:51 -0400 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on2060.outbound.protection.outlook.com [40.107.96.60]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4F32C110; Mon, 16 Oct 2023 06:48:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W75ayojfAnzWRfgUMl3zW5Bj4u94ap7WkL1hQ09KNwfwWlRBNKCmwPr0l9Nlh7LlqJhKBwhJqFgJppW3R8GwUjtRrbZihTUbDD6XV8PsABLXEt135Xv8V2l6QBiX+ayj1jDI+nGNw1KywkFitsHrk13z+VGAlBo6eKxVhQrIb6u+UU8IlMKtUOs676pWkrtH5XcvtbxrfYdVYvkXfFfW3avsUYy5cLMnEkGtvDaqPO2kvMq7UGbmHUw5SNv4LCz17WLPKy/9916TJEtF+kiArcdj9Rjq3ZUS7S2S4bv8wq2v4aBHxpmovM4LQ1HrFHeDQWJ/QKtWwQqR6SnwbwAWsQ== 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:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3+JCtj3ASOKkhljKB2Eu8gzmxNkQyvn/YzFk7ZCXbFg=; b=jsN2yZAhdxr1PylZJusjfSMHD5hQ7qbE1toJucjTIVomXZs6mjkdKXPQWP5ORth58DqaoX0swj8QE2G5yuJcZ/MYO78nd/8w+wiDwbCqs3cRSwZU/PGchPxY3gbqS3o7Fu2WGarZrgiBLGLbrdynff2h8jANqjZSFMhBDfGQvuCkkxm4Hnw2slzHPlr5aXadrKTv/1X37i3Ar4o19vvZECuIITcsZY9rLffU+x6f/iYBZ5l688mQwFWgbls0Z1h0QNohCpo5/AjRXg0n6kppJQtRboMsgOSSW6l2B+rY3FOXl+T9BM+/4lOMeulQBn9+84TPmN3aA1jZq8hwvDD2lg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=vger.kernel.org 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 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=3+JCtj3ASOKkhljKB2Eu8gzmxNkQyvn/YzFk7ZCXbFg=; b=nMrUdFpayLVy4ZnqWFNDDa3eloJV/yURxbuR0pwbNwOZW6+QUVm5KyKyZd3aaoM1N1RGlEWxFg92EU7KTb1tW7fvDzxEuLEjC4h/93AAJEGltZKJwwRBrp4TRdyWgMEl0NdhHnb1pS6xXbEH9Va1ATcXoPd8YgplPnqnQpmxHUY= Received: from BL1PR13CA0139.namprd13.prod.outlook.com (2603:10b6:208:2bb::24) by BY5PR12MB4275.namprd12.prod.outlook.com (2603:10b6:a03:20a::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6863.38; Mon, 16 Oct 2023 13:48:18 +0000 Received: from MN1PEPF0000F0E5.namprd04.prod.outlook.com (2603:10b6:208:2bb:cafe::e8) by BL1PR13CA0139.outlook.office365.com (2603:10b6:208:2bb::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6907.17 via Frontend Transport; Mon, 16 Oct 2023 13:48:18 +0000 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=SATLEXMB04.amd.com; pr=C Received: from SATLEXMB04.amd.com (165.204.84.17) by MN1PEPF0000F0E5.mail.protection.outlook.com (10.167.242.43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.6838.22 via Frontend Transport; Mon, 16 Oct 2023 13:48:18 +0000 Received: from localhost (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Mon, 16 Oct 2023 08:48:04 -0500 From: Michael Roth <michael.roth@amd.com> To: <kvm@vger.kernel.org> CC: <linux-coco@lists.linux.dev>, <linux-mm@kvack.org>, <linux-crypto@vger.kernel.org>, <x86@kernel.org>, <linux-kernel@vger.kernel.org>, <tglx@linutronix.de>, <mingo@redhat.com>, <jroedel@suse.de>, <thomas.lendacky@amd.com>, <hpa@zytor.com>, <ardb@kernel.org>, <pbonzini@redhat.com>, <seanjc@google.com>, <vkuznets@redhat.com>, <jmattson@google.com>, <luto@kernel.org>, <dave.hansen@linux.intel.com>, <slp@redhat.com>, <pgonda@google.com>, <peterz@infradead.org>, <srinivas.pandruvada@linux.intel.com>, <rientjes@google.com>, <dovmurik@linux.ibm.com>, <tobin@ibm.com>, <bp@alien8.de>, <vbabka@suse.cz>, <kirill@shutemov.name>, <ak@linux.intel.com>, <tony.luck@intel.com>, <marcorr@google.com>, <sathyanarayanan.kuppuswamy@linux.intel.com>, <alpergun@google.com>, <jarkko@kernel.org>, <ashish.kalra@amd.com>, <nikunj.dadhania@amd.com>, <pankaj.gupta@amd.com>, <liam.merwick@oracle.com>, <zhi.a.wang@intel.com>, Brijesh Singh <brijesh.singh@amd.com>, Jarkko Sakkinen <jarkko@profian.com>, Ashish Kalra <Ashish.Kalra@amd.com> Subject: [PATCH v10 04/50] x86/cpufeatures: Add SEV-SNP CPU feature Date: Mon, 16 Oct 2023 08:27:33 -0500 Message-ID: <20231016132819.1002933-5-michael.roth@amd.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20231016132819.1002933-1-michael.roth@amd.com> References: <20231016132819.1002933-1-michael.roth@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN1PEPF0000F0E5:EE_|BY5PR12MB4275:EE_ X-MS-Office365-Filtering-Correlation-Id: d5ef2022-c8c3-4c22-d16c-08dbce4e8dc4 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ioBpLAic7HOUAApfm9MZ5s/sFi4mzT0X4C3CElX2lWX2Dy5ynnyXstwdc+5gvz0nfzSNVPXV+afsBtFysPmlerxPuU7THUGNaH+g/3fUrs/A36G+cOhv9p1kmTVRtksvXy1cBAxI4/e9gKmKlXmyLW3GsIDzdtiA7Ycy5BAAnmFVrotuGqKGVow7JYZ75lGSYxi4fsyfxc4JSaodM4MhU2u/I/rlS8f2qJ5pvS1SOQfM34Uzvmilyz2WUiDKiIRS7i1nXeptcdfecUX5sxKDEX5L+EMJiK4Fkq37mUJT1eD5KaHI7aCPBs49DCsc3NExO8KWf5GqusE2OTR4XpVUyclO6UrG/DeOuMhdkQV8FannJA6ZVt/76X8gM8/lw1E4I3KmRNMv0WqqCWb3/Gm7JYNn9cgheOel45ttoQ20F4Sq0Vy/NnjyQ70bWwmRA9geTbTOB3L/hGJko8PLrbN66hYAs4YvXUUz6CLICQTshD4f/FM1yTJ/aS6u4S6bBhf5iq7I3iA0r/AV8c+Xl0UXOYM9Uudfd4IOhkS8rbfxFY7Ue/p6ZjXtDTrzPhh62psmaeuyX5xXe3nnsJ+Q0zMa19VAHQN9OMPz2Iwzzp0AqPCnU8UGIXWQomGDOQyuFGBJfdZeMLsjBo+berP0oF5AIrH3A5IjCLMFVC8FkKgJMVNEOT9a233Q5GE++ysn5kv1pmGR6eRQH0z0NMnHCFzH0I7EW5EVnUM6hesikXVuQZzmFSqzaiaFuK60CzKBy+zwwpIKWW/J8Qj4AE3oEGJfcQ== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(4636009)(376002)(396003)(346002)(39860400002)(136003)(230922051799003)(186009)(82310400011)(451199024)(1800799009)(64100799003)(36840700001)(40470700004)(46966006)(5660300002)(41300700001)(1076003)(16526019)(426003)(2616005)(26005)(336012)(83380400001)(6666004)(8936002)(47076005)(70206006)(316002)(8676002)(478600001)(7416002)(44832011)(7406005)(6916009)(4326008)(54906003)(70586007)(40480700001)(36756003)(86362001)(81166007)(82740400003)(2906002)(40460700003)(356005)(36860700001)(36900700001);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2023 13:48:18.3689 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d5ef2022-c8c3-4c22-d16c-08dbce4e8dc4 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: MN1PEPF0000F0E5.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4275 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Mon, 16 Oct 2023 06:49:43 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779920210306963485 X-GMAIL-MSGID: 1779920210306963485 |
Series |
Add AMD Secure Nested Paging (SEV-SNP) Hypervisor Support
|
|
Commit Message
Michael Roth
Oct. 16, 2023, 1:27 p.m. UTC
From: Brijesh Singh <brijesh.singh@amd.com> Add CPU feature detection for Secure Encrypted Virtualization with Secure Nested Paging. This feature adds a strong memory integrity protection to help prevent malicious hypervisor-based attacks like data replay, memory re-mapping, and more. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Jarkko Sakkinen <jarkko@profian.com> Signed-off-by: Ashish Kalra <Ashish.Kalra@amd.com> Signed-off-by: Michael Roth <michael.roth@amd.com> --- arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/kernel/cpu/amd.c | 5 +++-- tools/arch/x86/include/asm/cpufeatures.h | 1 + 3 files changed, 5 insertions(+), 2 deletions(-)
Comments
On 10/16/23 15:27, Michael Roth wrote: > From: Brijesh Singh <brijesh.singh@amd.com> > > Add CPU feature detection for Secure Encrypted Virtualization with > Secure Nested Paging. This feature adds a strong memory integrity > protection to help prevent malicious hypervisor-based attacks like > data replay, memory re-mapping, and more. > > Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> > Signed-off-by: Jarkko Sakkinen <jarkko@profian.com> > Signed-off-by: Ashish Kalra <Ashish.Kalra@amd.com> > Signed-off-by: Michael Roth <michael.roth@amd.com> Queued, thanks. Paolo > --- > arch/x86/include/asm/cpufeatures.h | 1 + > arch/x86/kernel/cpu/amd.c | 5 +++-- > tools/arch/x86/include/asm/cpufeatures.h | 1 + > 3 files changed, 5 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h > index 58cb9495e40f..1640cedd77f1 100644 > --- a/arch/x86/include/asm/cpufeatures.h > +++ b/arch/x86/include/asm/cpufeatures.h > @@ -437,6 +437,7 @@ > #define X86_FEATURE_SEV (19*32+ 1) /* AMD Secure Encrypted Virtualization */ > #define X86_FEATURE_VM_PAGE_FLUSH (19*32+ 2) /* "" VM Page Flush MSR is supported */ > #define X86_FEATURE_SEV_ES (19*32+ 3) /* AMD Secure Encrypted Virtualization - Encrypted State */ > +#define X86_FEATURE_SEV_SNP (19*32+ 4) /* AMD Secure Encrypted Virtualization - Secure Nested Paging */ > #define X86_FEATURE_V_TSC_AUX (19*32+ 9) /* "" Virtual TSC_AUX */ > #define X86_FEATURE_SME_COHERENT (19*32+10) /* "" AMD hardware-enforced cache coherency */ > #define X86_FEATURE_DEBUG_SWAP (19*32+14) /* AMD SEV-ES full debug state swap support */ > diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c > index dd8379d84445..14ee7f750cc7 100644 > --- a/arch/x86/kernel/cpu/amd.c > +++ b/arch/x86/kernel/cpu/amd.c > @@ -630,8 +630,8 @@ static void early_detect_mem_encrypt(struct cpuinfo_x86 *c) > * SME feature (set in scattered.c). > * If the kernel has not enabled SME via any means then > * don't advertise the SME feature. > - * For SEV: If BIOS has not enabled SEV then don't advertise the > - * SEV and SEV_ES feature (set in scattered.c). > + * For SEV: If BIOS has not enabled SEV then don't advertise SEV and > + * any additional functionality based on it. > * > * In all cases, since support for SME and SEV requires long mode, > * don't advertise the feature under CONFIG_X86_32. > @@ -666,6 +666,7 @@ static void early_detect_mem_encrypt(struct cpuinfo_x86 *c) > clear_sev: > setup_clear_cpu_cap(X86_FEATURE_SEV); > setup_clear_cpu_cap(X86_FEATURE_SEV_ES); > + setup_clear_cpu_cap(X86_FEATURE_SEV_SNP); > } > } > > diff --git a/tools/arch/x86/include/asm/cpufeatures.h b/tools/arch/x86/include/asm/cpufeatures.h > index 798e60b5454b..669f45eefa0c 100644 > --- a/tools/arch/x86/include/asm/cpufeatures.h > +++ b/tools/arch/x86/include/asm/cpufeatures.h > @@ -432,6 +432,7 @@ > #define X86_FEATURE_SEV (19*32+ 1) /* AMD Secure Encrypted Virtualization */ > #define X86_FEATURE_VM_PAGE_FLUSH (19*32+ 2) /* "" VM Page Flush MSR is supported */ > #define X86_FEATURE_SEV_ES (19*32+ 3) /* AMD Secure Encrypted Virtualization - Encrypted State */ > +#define X86_FEATURE_SEV_SNP (19*32+ 4) /* AMD Secure Encrypted Virtualization - Secure Nested Paging */ > #define X86_FEATURE_V_TSC_AUX (19*32+ 9) /* "" Virtual TSC_AUX */ > #define X86_FEATURE_SME_COHERENT (19*32+10) /* "" AMD hardware-enforced cache coherency */ > #define X86_FEATURE_DEBUG_SWAP (19*32+14) /* AMD SEV-ES full debug state swap support */
On Wed, Dec 13, 2023 at 01:51:58PM +0100, Paolo Bonzini wrote: > On 10/16/23 15:27, Michael Roth wrote: > > From: Brijesh Singh <brijesh.singh@amd.com> > > > > Add CPU feature detection for Secure Encrypted Virtualization with > > Secure Nested Paging. This feature adds a strong memory integrity > > protection to help prevent malicious hypervisor-based attacks like > > data replay, memory re-mapping, and more. > > > > Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> > > Signed-off-by: Jarkko Sakkinen <jarkko@profian.com> > > Signed-off-by: Ashish Kalra <Ashish.Kalra@amd.com> > > Signed-off-by: Michael Roth <michael.roth@amd.com> > > Queued, thanks. Paolo, please stop queueing x86 patches through your tree. I'll give you an immutable branch with the x86 bits when the stuff has been reviewed. Thx.
On 12/13/23 14:13, Borislav Petkov wrote: > On Wed, Dec 13, 2023 at 01:51:58PM +0100, Paolo Bonzini wrote: >> On 10/16/23 15:27, Michael Roth wrote: >>> From: Brijesh Singh <brijesh.singh@amd.com> >>> >>> Add CPU feature detection for Secure Encrypted Virtualization with >>> Secure Nested Paging. This feature adds a strong memory integrity >>> protection to help prevent malicious hypervisor-based attacks like >>> data replay, memory re-mapping, and more. >>> >>> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> >>> Signed-off-by: Jarkko Sakkinen <jarkko@profian.com> >>> Signed-off-by: Ashish Kalra <Ashish.Kalra@amd.com> >>> Signed-off-by: Michael Roth <michael.roth@amd.com> >> >> Queued, thanks. > > Paolo, please stop queueing x86 patches through your tree. I'll give you > an immutable branch with the x86 bits when the stuff has been reviewed. Sure, I only queued it because you gave Acked-by for 05/50 and this is an obvious dependency. I would like to get things in as they are ready (whenever it makes sense), so if you want to include those two in the x86 tree for 6.8, that would work for me. Paolo
On Wed, Dec 13, 2023 at 02:31:05PM +0100, Paolo Bonzini wrote: > Sure, I only queued it because you gave Acked-by for 05/50 and this is an > obvious dependency. I would like to get things in as they are ready > (whenever it makes sense), so if you want to include those two in the x86 > tree for 6.8, that would work for me. It doesn't make sense to include them into 6.8 because the two alone are simply dead code in 6.8. The plan is to put the x86 patches first in the next submission, I'll pick them up for 6.9 and then give you an immutable branch to apply the KVM bits ontop. This way it all goes together. Thx.
On 12/13/23 14:36, Borislav Petkov wrote: >> Sure, I only queued it because you gave Acked-by for 05/50 and this is an >> obvious dependency. I would like to get things in as they are ready >> (whenever it makes sense), so if you want to include those two in the x86 >> tree for 6.8, that would work for me. > > It doesn't make sense to include them into 6.8 because the two alone are > simply dead code in 6.8. Why are they dead code? X86_FEATURE_SEV_SNP is set automatically based on CPUID, therefore patch 5 is a performance improvement on all processors that support SEV-SNP. This is independent of whether KVM can create SEV-SNP guests or not. If this is wrong, there is a problem in the commit messages. Paolo > The plan is to put the x86 patches first in the next submission, I'll > pick them up for 6.9 and then give you an immutable branch to apply the > KVM bits ontop. This way it all goes together.
On Wed, Dec 13, 2023 at 02:40:24PM +0100, Paolo Bonzini wrote: > Why are they dead code? X86_FEATURE_SEV_SNP is set automatically based on > CPUID, therefore patch 5 is a performance improvement on all processors that > support SEV-SNP. This is independent of whether KVM can create SEV-SNP > guests or not. No, it is not. This CPUID bit means: "RMP table can be enabled to protect memory even from hypervisor." Without the SNP host patches, it is dead code. And regardless, arch/x86/kvm/ patches go through the kvm tree. The rest of arch/x86/ through the tip tree. We've been over this a bunch of times already. If you don't agree with this split, let's discuss it offlist with all tip and kvm maintainers, reach an agreement who picks up what and to put an end to this nonsense. Thx.
On 12/13/23 14:49, Borislav Petkov wrote: > On Wed, Dec 13, 2023 at 02:40:24PM +0100, Paolo Bonzini wrote: >> Why are they dead code? X86_FEATURE_SEV_SNP is set automatically based on >> CPUID, therefore patch 5 is a performance improvement on all processors that >> support SEV-SNP. This is independent of whether KVM can create SEV-SNP >> guests or not. > > No, it is not. This CPUID bit means: > > "RMP table can be enabled to protect memory even from hypervisor." > > Without the SNP host patches, it is dead code. - if ((ia32_cap & ARCH_CAP_IBRS_ALL) || cpu_has(c, X86_FEATURE_AUTOIBRS)) { + if ((ia32_cap & ARCH_CAP_IBRS_ALL) || + (cpu_has(c, X86_FEATURE_AUTOIBRS) && + !cpu_feature_enabled(X86_FEATURE_SEV_SNP))) { Surely we can agree that cpu_feature_enabled(X86_FEATURE_SEV_SNP) has nothing to do with SEV-SNP host patches being present? And that therefore retpolines are preferred even without any SEV-SNP support in KVM? And can we agree that "Acked-by" means "feel free and take it if you wish, I don't care enough to merge it through my tree or provide a topic branch"? I'm asking because I'm not sure if we agree on these two things, but they really seem basic to me? Paolo > And regardless, arch/x86/kvm/ patches go through the kvm tree. The rest > of arch/x86/ through the tip tree. We've been over this a bunch of times > already. > If you don't agree with this split, let's discuss it offlist with all > tip and kvm maintainers, reach an agreement who picks up what and to put > an end to this nonsense. > > Thx. >
On Wed, Dec 13, 2023 at 03:18:17PM +0100, Paolo Bonzini wrote: > Surely we can agree that cpu_feature_enabled(X86_FEATURE_SEV_SNP) has nothing > to do with SEV-SNP host patches being present? It does - we're sanitizing the meaning of a CPUID flag present in /proc/cpuinfo, see here: https://git.kernel.org/tip/79c603ee43b2674fba0257803bab265147821955 > And that therefore retpolines are preferred even without any SEV-SNP > support in KVM? No, automatic IBRS should be disabled when SNP is enabled. Not CPUID present - enabled. We clear that bit on a couple of occasions in the SNP host patchset if we determine that SNP host support is not possible so 4/50 needs to go together with the rest to mean something. > And can we agree that "Acked-by" means "feel free and take it if you wish, I can see how it can mean that and I'm sorry for the misunderstanding I caused. Two things here: * I acked it because I did a lengthly digging internally on whether disabling AIBRS makes sense on SNP and this was a note more to myself to say, yes, that's a good change. * If I wanted for you to pick it up, I would've acked 4/50 too. Which I haven't. > I'm asking because I'm not sure if we agree on these two things, but they > really seem basic to me? I think KVM and x86 maintainers should sit down and discuss who picks up what and through which tree so that there's no more confusion in the future. It seems things need discussion... Thx.
On 12/13/23 16:41, Borislav Petkov wrote: > On Wed, Dec 13, 2023 at 03:18:17PM +0100, Paolo Bonzini wrote: >> Surely we can agree that cpu_feature_enabled(X86_FEATURE_SEV_SNP) has nothing >> to do with SEV-SNP host patches being present? > > It does - we're sanitizing the meaning of a CPUID flag present in > /proc/cpuinfo, see here: > > https://git.kernel.org/tip/79c603ee43b2674fba0257803bab265147821955 > >> And that therefore retpolines are preferred even without any SEV-SNP >> support in KVM? > > No, automatic IBRS should be disabled when SNP is enabled. Not CPUID > present - enabled. Ok, so the root cause of the problem is commit message/patch ordering: 1) patch 4 should have unconditionally cleared the feature (until the initialization code comes around in patch 6); and it should have mentioned in the commit message that we don't want X86_FEATURE_SEV_SNP to be set, unless SNP can be enabled via MSR_AMD64_SYSCFG. 2) possibly, the commit message of patch 5 could have said something like "at this point in the kernel SNP is never enabled". 3) Patch 23 should have been placed before the SNP initialization, because as things stand the patches (mildly) break bisectability. > We clear that bit on a couple of occasions in the SNP > host patchset if we determine that SNP host support is not possible so > 4/50 needs to go together with the rest to mean something. Understood now. With the patch ordering and commit message edits I suggested above, indeed I would not have picked up patch 4. But with your explanation, I would even say that "4/50 needs to go together with the rest" *for correctness*, not just to mean something. Paolo
On Wed, Dec 13, 2023 at 06:35:35PM +0100, Paolo Bonzini wrote: > 1) patch 4 should have unconditionally cleared the feature (until the > initialization code comes around in patch 6); and it should have mentioned > in the commit message that we don't want X86_FEATURE_SEV_SNP to be set, > unless SNP can be enabled via MSR_AMD64_SYSCFG. I guess. > 2) possibly, the commit message of patch 5 could have said something like > "at this point in the kernel SNP is never enabled". Sure. > 3) Patch 23 should have been placed before the SNP initialization, because > as things stand the patches (mildly) break bisectability. Ok, I still haven't reached that one. > Understood now. With the patch ordering and commit message edits I > suggested above, indeed I would not have picked up patch 4. In the future, please simply refrain from picking up x86 patches if you haven't gotten an explicit ACK. We could have conflicting changes in tip, we could be reworking that part of the code and the thing the patch touches could be completely gone, and so on and so on... Also, we want to have a full picture of what goes in. Exactly the same as how you'd like to have a full picture of what goes into kvm and how we don't apply kvm patches unless there's some extraordinary circumstance or we have received an explicit ACK. > But with your explanation, I would even say that "4/50 needs to go > together with the rest" *for correctness*, not just to mean something. Yes, but for ease of integration it would be easier if they go in two groups - kvm and x86 bits. Not: some x86 bits first, then kvm bits through your tree and then some more x86 bits. That would be a logistical nightmare. And even if you bisect and land at 4/50 and you disable AIBRS even without SNP being really enabled, that is not a big deal - you're only bisecting and not really using that kernel and it's not like it breaks builds so... Thx.
diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h index 58cb9495e40f..1640cedd77f1 100644 --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -437,6 +437,7 @@ #define X86_FEATURE_SEV (19*32+ 1) /* AMD Secure Encrypted Virtualization */ #define X86_FEATURE_VM_PAGE_FLUSH (19*32+ 2) /* "" VM Page Flush MSR is supported */ #define X86_FEATURE_SEV_ES (19*32+ 3) /* AMD Secure Encrypted Virtualization - Encrypted State */ +#define X86_FEATURE_SEV_SNP (19*32+ 4) /* AMD Secure Encrypted Virtualization - Secure Nested Paging */ #define X86_FEATURE_V_TSC_AUX (19*32+ 9) /* "" Virtual TSC_AUX */ #define X86_FEATURE_SME_COHERENT (19*32+10) /* "" AMD hardware-enforced cache coherency */ #define X86_FEATURE_DEBUG_SWAP (19*32+14) /* AMD SEV-ES full debug state swap support */ diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index dd8379d84445..14ee7f750cc7 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -630,8 +630,8 @@ static void early_detect_mem_encrypt(struct cpuinfo_x86 *c) * SME feature (set in scattered.c). * If the kernel has not enabled SME via any means then * don't advertise the SME feature. - * For SEV: If BIOS has not enabled SEV then don't advertise the - * SEV and SEV_ES feature (set in scattered.c). + * For SEV: If BIOS has not enabled SEV then don't advertise SEV and + * any additional functionality based on it. * * In all cases, since support for SME and SEV requires long mode, * don't advertise the feature under CONFIG_X86_32. @@ -666,6 +666,7 @@ static void early_detect_mem_encrypt(struct cpuinfo_x86 *c) clear_sev: setup_clear_cpu_cap(X86_FEATURE_SEV); setup_clear_cpu_cap(X86_FEATURE_SEV_ES); + setup_clear_cpu_cap(X86_FEATURE_SEV_SNP); } } diff --git a/tools/arch/x86/include/asm/cpufeatures.h b/tools/arch/x86/include/asm/cpufeatures.h index 798e60b5454b..669f45eefa0c 100644 --- a/tools/arch/x86/include/asm/cpufeatures.h +++ b/tools/arch/x86/include/asm/cpufeatures.h @@ -432,6 +432,7 @@ #define X86_FEATURE_SEV (19*32+ 1) /* AMD Secure Encrypted Virtualization */ #define X86_FEATURE_VM_PAGE_FLUSH (19*32+ 2) /* "" VM Page Flush MSR is supported */ #define X86_FEATURE_SEV_ES (19*32+ 3) /* AMD Secure Encrypted Virtualization - Encrypted State */ +#define X86_FEATURE_SEV_SNP (19*32+ 4) /* AMD Secure Encrypted Virtualization - Secure Nested Paging */ #define X86_FEATURE_V_TSC_AUX (19*32+ 9) /* "" Virtual TSC_AUX */ #define X86_FEATURE_SME_COHERENT (19*32+10) /* "" AMD hardware-enforced cache coherency */ #define X86_FEATURE_DEBUG_SWAP (19*32+14) /* AMD SEV-ES full debug state swap support */