Message ID | 1696011549-28036-4-git-send-email-mikelley@microsoft.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:6359:6f87:b0:13f:353d:d1ed with SMTP id tl7csp3516062rwb; Fri, 29 Sep 2023 12:27:15 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGVm9hFLa9UPR1nXZPlMA9v27/Ffkr4UyKjNTnkVTSyYmJECJCC5Z8DvDskFQf5UpIcSUbw X-Received: by 2002:a05:6a20:430a:b0:153:40c3:aa71 with SMTP id h10-20020a056a20430a00b0015340c3aa71mr6035078pzk.43.1696015634969; Fri, 29 Sep 2023 12:27:14 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1696015634; cv=pass; d=google.com; s=arc-20160816; b=FRn6t9I0zbiVWhLO58Raxlu1Dmi3FbdB2iOO85B82MqxqllK9IN1b9gx6WAQSNcw55 9ixqAg1NLt+Dr1Y1lo41yhM6RAiJsA1uY29AeRFZ15YICqBlOT1o/bhZqGY5MkgnIhX2 O1Wzi5yVqQLBNVhgKzN2Abwa4HykvTgOJ0g6uvhGHd6W2uhmzigIJDck8IQZDFgWity3 xBjwksCQQrHo26ocaDizuSnck4amdMsDQq2zzmBZ7nXup6htBipScsIGUoIFqyZVpauq W7OvxqUYaiPpDW0nTgkyvesCR/nWaDPehJEl3jKGEtttH7I5c07tJL/NgQfu318M50od SGRQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=xVtMPBDElysEOjbegf4nL2dYZfzxFly9Up4BTuDtAyo=; fh=8wk8lqEkM4zMNBA3klGd2o6ugh/N14d5WOE9geYUU7M=; b=BIiwFt8+XeZYecsPLuB1xchMgZkQL/zw6mCU7qY6piZz5jCQLYT4QhPT5pEUlo+iPV cltar2gz1lPQh3eUvawy89dEWIgpPq59gm+xHi4tYoRZL4fuU51P/VqOAd2nd1zg8AN5 PMWoShwJj5UK2/avnKp3l9cLcpo5TblUYU/HYEvIRh8XLRzVvQisOQdkStzh2/C6vIqL LlBhzqNp8RxFSNmOmxZwyZjifQUOYZ4vOnlGh/Ofaae5WtVASQLKbJbi0wsoRmx3cyFI i5VnnCZRT4WgLCaSDOQiLAdc4OG8nU6srLFJiXrNFPtnYAeWqBF5nbqkIH5P0V/DA3R5 0+ew== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@microsoft.com header.s=selector2 header.b=d9MRSlPQ; arc=pass (i=1 spf=pass spfdomain=microsoft.com dkim=pass dkdomain=microsoft.com dmarc=pass fromdomain=microsoft.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=microsoft.com Received: from snail.vger.email (snail.vger.email. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id o15-20020a656a4f000000b00563a0c1bf06si25122404pgu.428.2023.09.29.12.27.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Sep 2023 12:27:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; dkim=pass header.i=@microsoft.com header.s=selector2 header.b=d9MRSlPQ; arc=pass (i=1 spf=pass spfdomain=microsoft.com dkim=pass dkdomain=microsoft.com dmarc=pass fromdomain=microsoft.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=microsoft.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 2443983452A3; Fri, 29 Sep 2023 11:20:55 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233897AbjI2SUt (ORCPT <rfc822;pwkd43@gmail.com> + 19 others); Fri, 29 Sep 2023 14:20:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45146 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233887AbjI2SUj (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 29 Sep 2023 14:20:39 -0400 Received: from DM6FTOPR00CU001.outbound.protection.outlook.com (mail-centralusazon11020024.outbound.protection.outlook.com [52.101.61.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 852561B6; Fri, 29 Sep 2023 11:20:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d+68mP4K5AlfZAcx4OLfdGPfBJhD4vqYR7BcGGptnuk2gTKIxHMF41Xol72Z59yHGfXaZbfa+einXd7Qe5BsVP/NvExgJWu9tmqzUISPuOUGbsrwNvFQk9anPXJoPpxKA+0y6WDlPoT33GRvyFyRTu1k2QAFFgbrQD27Htd1TZJEe3TP9c95j/qMlT/UHUtPbKLQsc9KglGaa36O2wFmut6NX1ikmfLyuEvg3Hbqicw+3dYAsa4XPXdY1SzuPh/8x44gbr7xIjl60G9o2dvDFTyj4Crzs3HLvNB4hQHyIUqfEY3QI+mB1jGOa2BKGIwjmnwSVJ/yoEjPg6XFnYL18A== 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=xVtMPBDElysEOjbegf4nL2dYZfzxFly9Up4BTuDtAyo=; b=FG/pIe+y/a3BbzyJ60nuI/fYGVnB/ccrFGTg3n519bLDDxQg+CQxmGrY3kJ75jQLblB5gM0B4d88qUS1SyM3PKdE92PNE9kRZkg5IVdT9kfUysUJWeOcOIOzwUFfy9hWbt6BgfSrJx2qTpjmw0L7L9xfLGbWLz/bPg1uKQxwfGHseUIhwbSI+/W/IyWCCea1GKUGHVk/CtLD5MN6R/GMC2HuCLNq4Pwf1wsgySwHdKlKUBd9eBWrtObrWtwo80a/7tpKYwzH/WSt0V6X/5NLT8b532EPEY4Njae5NuQvORSHPoJy67wD78ZxTmQA6UydO3Y29Nz/mUUHiX+UQ6YOnQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xVtMPBDElysEOjbegf4nL2dYZfzxFly9Up4BTuDtAyo=; b=d9MRSlPQHcSMP72CycbFZecKCHZCiiO21mozluRZPm17Pd5acDTFGmRr8RnNUCAifEBVZuX3vBFVSBFauqqKdi6sdN+9Tqv+Ih59zXmlf93He/Y5F2UGCE17Hv5M/hY40H13rAZs5bPcyIIkHP2bhcfLC5qQwtmRFAb2R7Nbd7M= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=microsoft.com; Received: from DM6PR21MB1370.namprd21.prod.outlook.com (2603:10b6:5:16b::28) by BL1PR21MB3377.namprd21.prod.outlook.com (2603:10b6:208:39d::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6863.14; Fri, 29 Sep 2023 18:20:26 +0000 Received: from DM6PR21MB1370.namprd21.prod.outlook.com ([fe80::eff:aea7:be24:8e44]) by DM6PR21MB1370.namprd21.prod.outlook.com ([fe80::eff:aea7:be24:8e44%4]) with mapi id 15.20.6863.013; Fri, 29 Sep 2023 18:20:26 +0000 From: Michael Kelley <mikelley@microsoft.com> To: kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, luto@kernel.org, peterz@infradead.org, thomas.lendacky@amd.com, sathyanarayanan.kuppuswamy@linux.intel.com, kirill.shutemov@linux.intel.com, seanjc@google.com, rick.p.edgecombe@intel.com, linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, x86@kernel.org Cc: mikelley@microsoft.com Subject: [PATCH 3/5] x86/mm: Mark CoCo VM pages not present while changing encrypted state Date: Fri, 29 Sep 2023 11:19:07 -0700 Message-Id: <1696011549-28036-4-git-send-email-mikelley@microsoft.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1696011549-28036-1-git-send-email-mikelley@microsoft.com> References: <1696011549-28036-1-git-send-email-mikelley@microsoft.com> Content-Type: text/plain X-ClientProxiedBy: CY5PR22CA0048.namprd22.prod.outlook.com (2603:10b6:930:1d::29) To DM6PR21MB1370.namprd21.prod.outlook.com (2603:10b6:5:16b::28) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM6PR21MB1370:EE_|BL1PR21MB3377:EE_ X-MS-Office365-Filtering-Correlation-Id: 3a16ca76-b309-46be-6291-08dbc118c0d1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: QfCyQXzBLif9q3mrD4aro364Ker/qXf/g/+GzRbSpZbigwIzBiBxaexYQk985Fe0FRluu/598+zCs1GDR41CCnNGvwKrOwiwZfVngIKH7xvzmEbMzhhqcY6Gva5qwGnkNhi1Z9mSJFGTwuR5kuBQoY9TRkIwp0eCj4tyQ6Uu0QNAhrFjKafLXbtnO43uAIDZ6VmZAGdoxF4fBjsOjFPcCT6UjZWP/iDfi+Am0Qv564gsvTmBm3G4Y30PwonjoU/+5kM+FNwHkwdWOxuEqIKLNo+ojXXdOsZTynwaW++GGEJJECTez5XZrIXGoqerCLNnXEdJy9/Z4qRG5UGSMIk6nWDoYLnUYw7wnaWVc1duUOgJmy7KSvqIHb8L4qVwF0SKfl0ubqb18RBe0rmKS2wY1HiCJiB/NiU8O65wT9gG7sulVuCvhwSBKUIr6r2xxGknPBlWVCPH0nJmfcff7tYGiwYQHPNKDm/FN+n4RR6u66uDH6jgDAnSjdwNoiZ9v9nYFHpWdJhalv2Bo3vBcvJrY342ixK4JATWynTYctsvca3K047Q7PVt/nyZoTwZIUC87d0G73753vR8zjLJBnil+9ODXm9lhlmSuV7vyjWGqHw1J3Hzp16s7uRpZDLutNHhM4dBoWy+3VxQxKI7iShCDVG28UvZkVk6HDg6dfXIvl8xwz+MeSAb6WeMlf8bSqe2 X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM6PR21MB1370.namprd21.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(6029001)(396003)(39860400002)(136003)(346002)(376002)(366004)(230922051799003)(186009)(451199024)(64100799003)(1800799009)(41300700001)(6506007)(6512007)(6486002)(52116002)(478600001)(6666004)(2616005)(2906002)(316002)(66946007)(66556008)(66476007)(5660300002)(107886003)(10290500003)(8676002)(8936002)(4326008)(26005)(30864003)(7416002)(921005)(82950400001)(82960400001)(36756003)(86362001)(83380400001)(38100700002)(38350700002);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: nEkBE0ET302MVTzYfRMOgyEaKMh7dwjgaL5k5iVUnUnPSARCcJyM4rce5Sj+HWtY2fJU+Fqb9ZpE+eu2RxmmyLHRiPSM0bdZ0vUU7EtnA0GOrwmGvYCFyhYMUiFqaSxlczcUJrUCm+TqBOhYIkUIHn5tsr/HV8s5gNQS7hbS4xgxdyL6vZ1y55cov4yp0hYvMkfMh9X12/lafa4QQccPmQhSw6HbMWD+ORxTGG5QHp/73G+kzgEnbHvoGN1wugQHj1q7GZjlBfu/IwQbhNxqmnrCp497Nn6Q5u1Nf0+0xb9RNkQEH0biBRWikO6G44WuY5s+DEXnYoyHll3pDSkyp83SYNzhEeLM8RXbdLQJhsDn5VHP9G2hoycQxh/Ktym7zXY8q6FdNtxAlHSm9/mQfRl3CZhywSnZ/FVC9NL5jkEuQuTH9LrLVXMAZuX3h9Tl1d0MSNdHV+/MdZsemVjD04PiuPkZpkGUv1lYuK3nOehdtp+pf3bUVF+7rHbR4g49mVV0gj19LSfJsbQn9VSxIUZQQ1yP5Ji/68mhDHgcuNVHy2fRdyTLsyArXEGb7+AcjV3fzeJHz0rblrMaRBh462R4uiPMGnkCuLlpNXXczD9WVlt4JRXPccNwaw+o2tRHEsnvtHVrAR71258vKhBvl2LNpuVryR4fZ9onf4V0iVh7eZ88fBDkLHvfKAIeY+IQMRAaVppq4ZW29Bee/FYoMYz/cBbZIJlgH4tqXVMp/YQxzyr2sPEegOMi3wHkTZvVAjtLj8Weg6/NI90S1Xnl+CMYcFJ2m0h8bjUvpfWNolXlOPMOqVE+7uJ7zI8M1Aup0ZXBGkxHnHTz1o+8p5gfFzFx+4yYlMNz2TCTyrHc3OKp1rj7MC8y74UokFKR7X5ioRQlj979fg9noEoBQpDccpGmEOty9MMT2BIGD7a7Da195G5PMmtT5sFUSU3Ed3/8E2xvEMAKPfN7nvIzmlUPhknG7joycyqtSA8kiACIuvvZklhbWxUgfT/ugjx6+5PwXw5Kl968hv5wd93rUiDEE/7dRws7OVB8H7YZkR4yffsgi2oNCs+rV16cFOCB6cTesVWRAWsizWWN6psU2NGJxd+5GQA4qwj+dPpGYDKuPwvrPuMhowOq3cJVRM40kJTT+8b05weDsNnCYl8poMLrm2tISim16Fh91czJpi5LDAYsODXYiMsgHyaOVqoLjLOavvzjMBMNv9KOBkNH/HsiZpKMQuyp/S0285A6tkvf+dc8UaSkRcaOgkyAxGVGqovtthSw7W9b2nNCVk3bA2aLVVYCTHok5PjJMxCbj+VgmeR7JzCLT0L52ihVk4yOueMcWbV67KsWgShRp4wRlxWDTFG0rFBz/6h94P8JffFwpT8ruVypgtFJ5a/q1dgB2aH1mKfSu1idJCKK2El54bS1I/N8FeeUgbnmSLOLyQ+5JObTIQBNmPHOKw+40Z4vo6mAc/4feagbmLRbgmTiV3rwPvcF1OgBXNfk+fBLpcPU95NeUfLWbsJpbwGnjEwwPjuD88qWpy0UWv69igMpYTaeN/Ftn15X5ZYw/sRzJV3gQN5MA+EPewY6UkRRnUC8CJE0qaSHSAwGaHUZQe5U0RECag== X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3a16ca76-b309-46be-6291-08dbc118c0d1 X-MS-Exchange-CrossTenant-AuthSource: DM6PR21MB1370.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Sep 2023 18:20:26.2619 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: iJuXp4PzvWMsL1PlchP/ZWqkxFIvDVHtT8GeLLjtsDXFQMRSi/d1kvT0yFg8XBme0xstNlDYXiagjQHXtJTVEg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR21MB3377 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO, RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net 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 (snail.vger.email [0.0.0.0]); Fri, 29 Sep 2023 11:20:55 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1778401290847952602 X-GMAIL-MSGID: 1778401290847952602 |
Series |
x86/coco: Mark CoCo VM pages not present when changing encrypted state
|
|
Commit Message
Michael Kelley (LINUX)
Sept. 29, 2023, 6:19 p.m. UTC
In a CoCo VM when a page transitions from encrypted to decrypted, or vice
versa, attributes in the PTE must be updated *and* the hypervisor must
be notified of the change. Because there are two separate steps, there's
a window where the settings are inconsistent. Normally the code that
initiates the transition (via set_memory_decrypted() or
set_memory_encrypted()) ensures that the memory is not being accessed
during a transition, so the window of inconsistency is not a problem.
However, the load_unaligned_zeropad() function can read arbitrary memory
pages at arbitrary times, which could access a transitioning page during
the window. In such a case, CoCo VM specific exceptions are taken
(depending on the CoCo architecture in use). Current code in those
exception handlers recovers and does "fixup" on the result returned by
load_unaligned_zeropad(). Unfortunately, this exception handling can't
work in paravisor scenarios (TDX Paritioning and SEV-SNP in vTOM mode).
The exceptions need to be forwarded from the paravisor to the Linux
guest, but there are no architectural specs for how to do that.
Fortunately, there's a simpler way to solve the problem by changing
the core transition code in __set_memory_enc_pgtable() to do the
following:
1. Remove aliasing mappings
2. Flush the data cache if needed
3. Remove the PRESENT bit from the PTEs of all transitioning pages
4. Set/clear the encryption attribute as appropriate
5. Flush the TLB so the changed encryption attribute isn't visible
6. Notify the hypervisor of the encryption status change
7. Add back the PRESENT bit, making the changed attribute visible
With this approach, load_unaligned_zeropad() just takes its normal
page-fault-based fixup path if it touches a page that is transitioning.
As a result, load_unaligned_zeropad() and CoCo VM page transitioning
are completely decoupled. CoCo VM page transitions can proceed
without needing to handle architecture-specific exceptions and fix
things up. This decoupling reduces the complexity due to separate
TDX and SEV-SNP fixup paths, and gives more freedom to revise and
introduce new capabilities in future versions of the TDX and SEV-SNP
architectures. Paravisor scenarios work properly without needing
to forward exceptions.
With this approach, the order of updating the guest PTEs and
notifying the hypervisor doesn't matter. As such, only a single
hypervisor callback is needed, rather one before and one after
the PTE update. Simplify the code by eliminating the extra
hypervisor callback along with the TDX and SEV-SNP code that
handles the before and after cases. The TLB flush callback is
also no longer required and is removed.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
---
arch/x86/coco/tdx/tdx.c | 66 +------------------------------------------
arch/x86/hyperv/ivm.c | 6 ----
arch/x86/kernel/x86_init.c | 4 ---
arch/x86/mm/mem_encrypt_amd.c | 27 ++++--------------
arch/x86/mm/pat/set_memory.c | 55 +++++++++++++++++++++++-------------
5 files changed, 43 insertions(+), 115 deletions(-)
Comments
Hi Michael, kernel test robot noticed the following build errors: [auto build test ERROR on tip/master] [also build test ERROR on tip/auto-latest linus/master v6.6-rc3 next-20230929] [cannot apply to tip/x86/mm tip/x86/core] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Michael-Kelley/x86-coco-Use-slow_virt_to_phys-in-page-transition-hypervisor-callbacks/20230930-041800 base: tip/master patch link: https://lore.kernel.org/r/1696011549-28036-4-git-send-email-mikelley%40microsoft.com patch subject: [PATCH 3/5] x86/mm: Mark CoCo VM pages not present while changing encrypted state config: i386-tinyconfig (https://download.01.org/0day-ci/archive/20230930/202309300620.S7uwOfcg-lkp@intel.com/config) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20230930/202309300620.S7uwOfcg-lkp@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp@intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202309300620.S7uwOfcg-lkp@intel.com/ All errors (new ones prefixed by >>): arch/x86/mm/pat/set_memory.c: In function '__set_memory_enc_pgtable': >> arch/x86/mm/pat/set_memory.c:2200:16: error: implicit declaration of function 'set_memory_p'; did you mean 'set_memory_np'? [-Werror=implicit-function-declaration] 2200 | return set_memory_p(&addr, numpages); | ^~~~~~~~~~~~ | set_memory_np cc1: some warnings being treated as errors vim +2200 arch/x86/mm/pat/set_memory.c 2132 2133 /* 2134 * __set_memory_enc_pgtable() is used for the hypervisors that get 2135 * informed about "encryption" status via page tables. 2136 */ 2137 static int __set_memory_enc_pgtable(unsigned long addr, int numpages, bool enc) 2138 { 2139 pgprot_t empty = __pgprot(0); 2140 struct cpa_data cpa; 2141 int ret; 2142 2143 /* Should not be working on unaligned addresses */ 2144 if (WARN_ONCE(addr & ~PAGE_MASK, "misaligned address: %#lx\n", addr)) 2145 addr &= PAGE_MASK; 2146 2147 memset(&cpa, 0, sizeof(cpa)); 2148 cpa.vaddr = &addr; 2149 cpa.numpages = numpages; 2150 2151 /* 2152 * The caller must ensure that the memory being transitioned between 2153 * encrypted and decrypted is not being accessed. But if 2154 * load_unaligned_zeropad() touches the "next" page, it may generate a 2155 * read access the caller has no control over. To ensure such accesses 2156 * cause a normal page fault for the load_unaligned_zeropad() handler, 2157 * mark the pages not present until the transition is complete. We 2158 * don't want a #VE or #VC fault due to a mismatch in the memory 2159 * encryption status, since paravisor configurations can't cleanly do 2160 * the load_unaligned_zeropad() handling in the paravisor. 2161 * 2162 * There's no requirement to do so, but for efficiency we can clear 2163 * _PAGE_PRESENT and set/clr encryption attr as a single operation. 2164 */ 2165 cpa.mask_set = enc ? pgprot_encrypted(empty) : pgprot_decrypted(empty); 2166 cpa.mask_clr = enc ? pgprot_decrypted(__pgprot(_PAGE_PRESENT)) : 2167 pgprot_encrypted(__pgprot(_PAGE_PRESENT)); 2168 cpa.pgd = init_mm.pgd; 2169 2170 /* Must avoid aliasing mappings in the highmem code */ 2171 kmap_flush_unused(); 2172 vm_unmap_aliases(); 2173 2174 /* Flush the caches as needed before changing the encryption attr. */ 2175 if (x86_platform.guest.enc_cache_flush_required()) 2176 cpa_flush(&cpa, 1); 2177 2178 ret = __change_page_attr_set_clr(&cpa, 1); 2179 if (ret) 2180 return ret; 2181 2182 /* 2183 * After clearing _PAGE_PRESENT and changing the encryption attribute, 2184 * we need to flush TLBs to ensure no further accesses to the memory can 2185 * be made with the old encryption attribute (but no need to flush caches 2186 * again). We could just use cpa_flush_all(), but in case TLB flushing 2187 * gets optimized in the cpa_flush() path use the same logic as above. 2188 */ 2189 cpa_flush(&cpa, 0); 2190 2191 /* Notify hypervisor that we have successfully set/clr encryption attr. */ 2192 if (!x86_platform.guest.enc_status_change_finish(addr, numpages, enc)) 2193 return -EIO; 2194 2195 /* 2196 * Now that the hypervisor is sync'ed with the page table changes 2197 * made here, add back _PAGE_PRESENT. set_memory_p() does not flush 2198 * the TLB. 2199 */ > 2200 return set_memory_p(&addr, numpages); 2201 } 2202
On 9/29/23 13:19, Michael Kelley wrote: > In a CoCo VM when a page transitions from encrypted to decrypted, or vice > versa, attributes in the PTE must be updated *and* the hypervisor must > be notified of the change. Because there are two separate steps, there's > a window where the settings are inconsistent. Normally the code that > initiates the transition (via set_memory_decrypted() or > set_memory_encrypted()) ensures that the memory is not being accessed > during a transition, so the window of inconsistency is not a problem. > However, the load_unaligned_zeropad() function can read arbitrary memory > pages at arbitrary times, which could access a transitioning page during > the window. In such a case, CoCo VM specific exceptions are taken > (depending on the CoCo architecture in use). Current code in those > exception handlers recovers and does "fixup" on the result returned by > load_unaligned_zeropad(). Unfortunately, this exception handling can't > work in paravisor scenarios (TDX Paritioning and SEV-SNP in vTOM mode). > The exceptions need to be forwarded from the paravisor to the Linux > guest, but there are no architectural specs for how to do that. > > Fortunately, there's a simpler way to solve the problem by changing > the core transition code in __set_memory_enc_pgtable() to do the > following: > > 1. Remove aliasing mappings > 2. Flush the data cache if needed > 3. Remove the PRESENT bit from the PTEs of all transitioning pages > 4. Set/clear the encryption attribute as appropriate > 5. Flush the TLB so the changed encryption attribute isn't visible > 6. Notify the hypervisor of the encryption status change Not sure why I didn't notice this before, but I will need to test this to be certain. As part of this notification, the SNP support will issue a PVALIDATE instruction (to either validate or rescind validation to the page). PVALIDATE takes a virtual address. If the PRESENT bit has been removed, the PVALIDATE instruction will take a #PF (see comments below). > 7. Add back the PRESENT bit, making the changed attribute visible > > With this approach, load_unaligned_zeropad() just takes its normal > page-fault-based fixup path if it touches a page that is transitioning. > As a result, load_unaligned_zeropad() and CoCo VM page transitioning > are completely decoupled. CoCo VM page transitions can proceed > without needing to handle architecture-specific exceptions and fix > things up. This decoupling reduces the complexity due to separate > TDX and SEV-SNP fixup paths, and gives more freedom to revise and > introduce new capabilities in future versions of the TDX and SEV-SNP > architectures. Paravisor scenarios work properly without needing > to forward exceptions. > > With this approach, the order of updating the guest PTEs and > notifying the hypervisor doesn't matter. As such, only a single > hypervisor callback is needed, rather one before and one after > the PTE update. Simplify the code by eliminating the extra > hypervisor callback along with the TDX and SEV-SNP code that > handles the before and after cases. The TLB flush callback is > also no longer required and is removed. > > Signed-off-by: Michael Kelley <mikelley@microsoft.com> > --- > arch/x86/coco/tdx/tdx.c | 66 +------------------------------------------ > arch/x86/hyperv/ivm.c | 6 ---- > arch/x86/kernel/x86_init.c | 4 --- > arch/x86/mm/mem_encrypt_amd.c | 27 ++++-------------- > arch/x86/mm/pat/set_memory.c | 55 +++++++++++++++++++++++------------- > 5 files changed, 43 insertions(+), 115 deletions(-) > > diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c > index 3e6dbd2..1bb2fff 100644 > --- a/arch/x86/coco/tdx/tdx.c > +++ b/arch/x86/coco/tdx/tdx.c > @@ -676,24 +676,6 @@ bool tdx_handle_virt_exception(struct pt_regs *regs, struct ve_info *ve) > return true; > } > > -static bool tdx_tlb_flush_required(bool private) > -{ > - /* > - * TDX guest is responsible for flushing TLB on private->shared > - * transition. VMM is responsible for flushing on shared->private. > - * > - * The VMM _can't_ flush private addresses as it can't generate PAs > - * with the guest's HKID. Shared memory isn't subject to integrity > - * checking, i.e. the VMM doesn't need to flush for its own protection. > - * > - * There's no need to flush when converting from shared to private, > - * as flushing is the VMM's responsibility in this case, e.g. it must > - * flush to avoid integrity failures in the face of a buggy or > - * malicious guest. > - */ > - return !private; > -} > - > static bool tdx_cache_flush_required(void) > { > /* > @@ -776,30 +758,6 @@ static bool tdx_enc_status_changed(unsigned long vaddr, int numpages, bool enc) > return true; > } > > -static bool tdx_enc_status_change_prepare(unsigned long vaddr, int numpages, > - bool enc) > -{ > - /* > - * Only handle shared->private conversion here. > - * See the comment in tdx_early_init(). > - */ > - if (enc) > - return tdx_enc_status_changed(vaddr, numpages, enc); > - return true; > -} > - > -static bool tdx_enc_status_change_finish(unsigned long vaddr, int numpages, > - bool enc) > -{ > - /* > - * Only handle private->shared conversion here. > - * See the comment in tdx_early_init(). > - */ > - if (!enc) > - return tdx_enc_status_changed(vaddr, numpages, enc); > - return true; > -} > - > void __init tdx_early_init(void) > { > struct tdx_module_args args = { > @@ -831,30 +789,8 @@ void __init tdx_early_init(void) > */ > physical_mask &= cc_mask - 1; > > - /* > - * The kernel mapping should match the TDX metadata for the page. > - * load_unaligned_zeropad() can touch memory *adjacent* to that which is > - * owned by the caller and can catch even _momentary_ mismatches. Bad > - * things happen on mismatch: > - * > - * - Private mapping => Shared Page == Guest shutdown > - * - Shared mapping => Private Page == Recoverable #VE > - * > - * guest.enc_status_change_prepare() converts the page from > - * shared=>private before the mapping becomes private. > - * > - * guest.enc_status_change_finish() converts the page from > - * private=>shared after the mapping becomes private. > - * > - * In both cases there is a temporary shared mapping to a private page, > - * which can result in a #VE. But, there is never a private mapping to > - * a shared page. > - */ > - x86_platform.guest.enc_status_change_prepare = tdx_enc_status_change_prepare; > - x86_platform.guest.enc_status_change_finish = tdx_enc_status_change_finish; > - > + x86_platform.guest.enc_status_change_finish = tdx_enc_status_changed; > x86_platform.guest.enc_cache_flush_required = tdx_cache_flush_required; > - x86_platform.guest.enc_tlb_flush_required = tdx_tlb_flush_required; > > /* > * TDX intercepts the RDMSR to read the X2APIC ID in the parallel > diff --git a/arch/x86/hyperv/ivm.c b/arch/x86/hyperv/ivm.c > index 084fab6..fbe2585 100644 > --- a/arch/x86/hyperv/ivm.c > +++ b/arch/x86/hyperv/ivm.c > @@ -550,11 +550,6 @@ static bool hv_vtom_set_host_visibility(unsigned long kbuffer, int pagecount, bo > return result; > } > > -static bool hv_vtom_tlb_flush_required(bool private) > -{ > - return true; > -} > - > static bool hv_vtom_cache_flush_required(void) > { > return false; > @@ -614,7 +609,6 @@ void __init hv_vtom_init(void) > > x86_platform.hyper.is_private_mmio = hv_is_private_mmio; > x86_platform.guest.enc_cache_flush_required = hv_vtom_cache_flush_required; > - x86_platform.guest.enc_tlb_flush_required = hv_vtom_tlb_flush_required; > x86_platform.guest.enc_status_change_finish = hv_vtom_set_host_visibility; > > /* Set WB as the default cache mode. */ > diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c > index a37ebd3..cf5179b 100644 > --- a/arch/x86/kernel/x86_init.c > +++ b/arch/x86/kernel/x86_init.c > @@ -131,9 +131,7 @@ struct x86_cpuinit_ops x86_cpuinit = { > > static void default_nmi_init(void) { }; > > -static bool enc_status_change_prepare_noop(unsigned long vaddr, int npages, bool enc) { return true; } > static bool enc_status_change_finish_noop(unsigned long vaddr, int npages, bool enc) { return true; } > -static bool enc_tlb_flush_required_noop(bool enc) { return false; } > static bool enc_cache_flush_required_noop(void) { return false; } > static bool is_private_mmio_noop(u64 addr) {return false; } > > @@ -154,9 +152,7 @@ struct x86_platform_ops x86_platform __ro_after_init = { > .hyper.is_private_mmio = is_private_mmio_noop, > > .guest = { > - .enc_status_change_prepare = enc_status_change_prepare_noop, > .enc_status_change_finish = enc_status_change_finish_noop, > - .enc_tlb_flush_required = enc_tlb_flush_required_noop, > .enc_cache_flush_required = enc_cache_flush_required_noop, > }, > }; > diff --git a/arch/x86/mm/mem_encrypt_amd.c b/arch/x86/mm/mem_encrypt_amd.c > index 6faea41..06960ba 100644 > --- a/arch/x86/mm/mem_encrypt_amd.c > +++ b/arch/x86/mm/mem_encrypt_amd.c > @@ -278,11 +278,6 @@ static unsigned long pg_level_to_pfn(int level, pte_t *kpte, pgprot_t *ret_prot) > return pfn; > } > > -static bool amd_enc_tlb_flush_required(bool enc) > -{ > - return true; > -} > - > static bool amd_enc_cache_flush_required(void) > { > return !cpu_feature_enabled(X86_FEATURE_SME_COHERENT); > @@ -318,18 +313,6 @@ static void enc_dec_hypercall(unsigned long vaddr, unsigned long size, bool enc) > #endif > } > > -static bool amd_enc_status_change_prepare(unsigned long vaddr, int npages, bool enc) > -{ > - /* > - * To maintain the security guarantees of SEV-SNP guests, make sure > - * to invalidate the memory before encryption attribute is cleared. > - */ > - if (cc_platform_has(CC_ATTR_GUEST_SEV_SNP) && !enc) > - snp_set_memory_shared(vaddr, npages); > - > - return true; > -} > - > /* Return true unconditionally: return value doesn't matter for the SEV side */ > static bool amd_enc_status_change_finish(unsigned long vaddr, int npages, bool enc) > { > @@ -337,8 +320,12 @@ static bool amd_enc_status_change_finish(unsigned long vaddr, int npages, bool e > * After memory is mapped encrypted in the page table, validate it > * so that it is consistent with the page table updates. > */ > - if (cc_platform_has(CC_ATTR_GUEST_SEV_SNP) && enc) > - snp_set_memory_private(vaddr, npages); > + if (cc_platform_has(CC_ATTR_GUEST_SEV_SNP)) { > + if (enc) > + snp_set_memory_private(vaddr, npages); > + else > + snp_set_memory_shared(vaddr, npages); > + } These calls will both result in a PVALIDATE being issued (either before or after the page state change to the hypervisor) using the virtual address, which will trigger a #PF is the present bit isn't set. > > if (!cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT)) > enc_dec_hypercall(vaddr, npages << PAGE_SHIFT, enc); > @@ -498,9 +485,7 @@ void __init sme_early_init(void) > /* Update the protection map with memory encryption mask */ > add_encrypt_protection_map(); > > - x86_platform.guest.enc_status_change_prepare = amd_enc_status_change_prepare; > x86_platform.guest.enc_status_change_finish = amd_enc_status_change_finish; > - x86_platform.guest.enc_tlb_flush_required = amd_enc_tlb_flush_required; > x86_platform.guest.enc_cache_flush_required = amd_enc_cache_flush_required; > > /* > diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c > index d7ef8d3..d062e01 100644 > --- a/arch/x86/mm/pat/set_memory.c > +++ b/arch/x86/mm/pat/set_memory.c > @@ -2147,40 +2147,57 @@ static int __set_memory_enc_pgtable(unsigned long addr, int numpages, bool enc) > memset(&cpa, 0, sizeof(cpa)); > cpa.vaddr = &addr; > cpa.numpages = numpages; > + > + /* > + * The caller must ensure that the memory being transitioned between > + * encrypted and decrypted is not being accessed. But if > + * load_unaligned_zeropad() touches the "next" page, it may generate a > + * read access the caller has no control over. To ensure such accesses > + * cause a normal page fault for the load_unaligned_zeropad() handler, > + * mark the pages not present until the transition is complete. We > + * don't want a #VE or #VC fault due to a mismatch in the memory > + * encryption status, since paravisor configurations can't cleanly do > + * the load_unaligned_zeropad() handling in the paravisor. > + * > + * There's no requirement to do so, but for efficiency we can clear > + * _PAGE_PRESENT and set/clr encryption attr as a single operation. > + */ > cpa.mask_set = enc ? pgprot_encrypted(empty) : pgprot_decrypted(empty); > - cpa.mask_clr = enc ? pgprot_decrypted(empty) : pgprot_encrypted(empty); > + cpa.mask_clr = enc ? pgprot_decrypted(__pgprot(_PAGE_PRESENT)) : > + pgprot_encrypted(__pgprot(_PAGE_PRESENT)); This should be lined up with the pgprot_decrypted above, e.g.: cpa.mask_clr = enc ? pgprot_decrypted(__pgprot(_PAGE_PRESENT)) : pgprot_encrypted(__pgprot(_PAGE_PRESENT)); or cpa.mask_clr = enc ? pgprot_decrypted(__pgprot(_PAGE_PRESENT)) : pgprot_encrypted(__pgprot(_PAGE_PRESENT)); > cpa.pgd = init_mm.pgd; > > /* Must avoid aliasing mappings in the highmem code */ > kmap_flush_unused(); > vm_unmap_aliases(); > > - /* Flush the caches as needed before changing the encryption attribute. */ > - if (x86_platform.guest.enc_tlb_flush_required(enc)) > - cpa_flush(&cpa, x86_platform.guest.enc_cache_flush_required()); > - > - /* Notify hypervisor that we are about to set/clr encryption attribute. */ > - if (!x86_platform.guest.enc_status_change_prepare(addr, numpages, enc)) > - return -EIO; > + /* Flush the caches as needed before changing the encryption attr. */ > + if (x86_platform.guest.enc_cache_flush_required()) > + cpa_flush(&cpa, 1); > > ret = __change_page_attr_set_clr(&cpa, 1); > + if (ret) > + return ret; > > /* > - * After changing the encryption attribute, we need to flush TLBs again > - * in case any speculative TLB caching occurred (but no need to flush > - * caches again). We could just use cpa_flush_all(), but in case TLB > - * flushing gets optimized in the cpa_flush() path use the same logic > - * as above. > + * After clearing _PAGE_PRESENT and changing the encryption attribute, > + * we need to flush TLBs to ensure no further accesses to the memory can > + * be made with the old encryption attribute (but no need to flush caches > + * again). We could just use cpa_flush_all(), but in case TLB flushing > + * gets optimized in the cpa_flush() path use the same logic as above. > */ > cpa_flush(&cpa, 0); > > - /* Notify hypervisor that we have successfully set/clr encryption attribute. */ > - if (!ret) { > - if (!x86_platform.guest.enc_status_change_finish(addr, numpages, enc)) > - ret = -EIO; > - } > + /* Notify hypervisor that we have successfully set/clr encryption attr. */ > + if (!x86_platform.guest.enc_status_change_finish(addr, numpages, enc)) > + return -EIO; Here's where the #PF is likely to be triggered. Thanks, Tom > > - return ret; > + /* > + * Now that the hypervisor is sync'ed with the page table changes > + * made here, add back _PAGE_PRESENT. set_memory_p() does not flush > + * the TLB. > + */ > + return set_memory_p(&addr, numpages); > } > > static int __set_memory_enc_dec(unsigned long addr, int numpages, bool enc)
On 10/2/23 11:35, Tom Lendacky wrote: > On 9/29/23 13:19, Michael Kelley wrote: >> In a CoCo VM when a page transitions from encrypted to decrypted, or vice >> versa, attributes in the PTE must be updated *and* the hypervisor must >> be notified of the change. Because there are two separate steps, there's >> a window where the settings are inconsistent. Normally the code that >> initiates the transition (via set_memory_decrypted() or >> set_memory_encrypted()) ensures that the memory is not being accessed >> during a transition, so the window of inconsistency is not a problem. >> However, the load_unaligned_zeropad() function can read arbitrary memory >> pages at arbitrary times, which could access a transitioning page during >> the window. In such a case, CoCo VM specific exceptions are taken >> (depending on the CoCo architecture in use). Current code in those >> exception handlers recovers and does "fixup" on the result returned by >> load_unaligned_zeropad(). Unfortunately, this exception handling can't >> work in paravisor scenarios (TDX Paritioning and SEV-SNP in vTOM mode). >> The exceptions need to be forwarded from the paravisor to the Linux >> guest, but there are no architectural specs for how to do that. >> >> Fortunately, there's a simpler way to solve the problem by changing >> the core transition code in __set_memory_enc_pgtable() to do the >> following: >> >> 1. Remove aliasing mappings >> 2. Flush the data cache if needed >> 3. Remove the PRESENT bit from the PTEs of all transitioning pages >> 4. Set/clear the encryption attribute as appropriate >> 5. Flush the TLB so the changed encryption attribute isn't visible >> 6. Notify the hypervisor of the encryption status change > > Not sure why I didn't notice this before, but I will need to test this to > be certain. As part of this notification, the SNP support will issue a > PVALIDATE instruction (to either validate or rescind validation to the > page). PVALIDATE takes a virtual address. If the PRESENT bit has been > removed, the PVALIDATE instruction will take a #PF (see comments below). Yes, this series results in a #PF booting an SNP guest: [ 0.807735] BUG: unable to handle page fault for address: ffff88803bef7000 [ 0.807829] #PF: supervisor read access in kernel mode [ 0.807829] #PF: error_code(0x0000) - not-present page [ 0.807829] PGD 8000004c01067 P4D 8000004c01067 PUD 8000004c02067 PMD 80001001f8063 PTE 8007ffffc4108062 [ 0.807829] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 0.807829] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.6.0-rc3-sos-testing #1 [ 0.807829] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 2/2/2022 [ 0.807829] RIP: 0010:pvalidate_pages+0x99/0x140 [ 0.807829] Code: 48 09 ca 0f b6 4c c7 0f 48 09 d6 0f b6 54 c7 0e 48 c1 e6 0c 4c 21 de 83 e2 f0 80 fa 10 4a 8d 2c 16 0f 94 c2 48 89 e8 83 e1 01 <f2> 0f 01 ff 41 89 c4 72 6 1 83 f8 06 75 45 84 c9 74 41 48 01 de 48 [ 0.807829] RSP: 0000:ffffffff82803bd0 EFLAGS: 00010246 [ 0.807829] RAX: ffff88803bef7000 RBX: ffff888000200000 RCX: 0000000000000000 [ 0.807829] RDX: 0000000000000000 RSI: 000000003bef7000 RDI: ffffffff82803c40 [ 0.807829] RBP: ffff88803bef7000 R08: 0000000000000000 R09: 0000000000000000 [ 0.807829] R10: ffff888000000000 R11: 000000ffffffffff R12: 0000000000000040 [ 0.807829] R13: 0000000000000020 R14: ffffffff82803e48 R15: ffff88803bf37000 [ 0.807829] FS: 0000000000000000(0000) GS:ffff88846fc00000(0000) knlGS:0000000000000000 [ 0.807829] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.807829] CR2: ffff88803bef7000 CR3: 000800000382e000 CR4: 00000000003506f0 [ 0.807829] Call Trace: [ 0.807829] <TASK> [ 0.807829] ? __die+0x1f/0x70 [ 0.807829] ? page_fault_oops+0x81/0x150 [ 0.807829] ? srso_return_thunk+0x5/0x5f [ 0.807829] ? kernelmode_fixup_or_oops+0x84/0x110 [ 0.807829] ? exc_page_fault+0xa8/0x150 [ 0.807829] ? asm_exc_page_fault+0x22/0x30 [ 0.807829] ? pvalidate_pages+0x99/0x140 [ 0.807829] __set_pages_state+0x280/0x2b0 [ 0.807829] set_pages_state+0x4e/0xa0 [ 0.807829] amd_enc_status_change_finish+0x4a/0x80 [ 0.807829] __set_memory_enc_dec+0xe1/0x190 [ 0.807829] mem_encrypt_init+0x15/0xc0 [ 0.807829] start_kernel+0x31b/0x5e0 [ 0.807829] x86_64_start_reservations+0x14/0x30 [ 0.807829] x86_64_start_kernel+0x79/0x80 [ 0.807829] secondary_startup_64_no_verify+0x16b/0x16b [ 0.807829] </TASK> [ 0.807829] Modules linked in: [ 0.807829] CR2: ffff88803bef7000 [ 0.807829] ---[ end trace 0000000000000000 ]--- [ 0.807829] RIP: 0010:pvalidate_pages+0x99/0x140 [ 0.807829] Code: 48 09 ca 0f b6 4c c7 0f 48 09 d6 0f b6 54 c7 0e 48 c1 e6 0c 4c 21 de 83 e2 f0 80 fa 10 4a 8d 2c 16 0f 94 c2 48 89 e8 83 e1 01 <f2> 0f 01 ff 41 89 c4 72 6 1 83 f8 06 75 45 84 c9 74 41 48 01 de 48 [ 0.807829] RSP: 0000:ffffffff82803bd0 EFLAGS: 00010246 [ 0.807829] RAX: ffff88803bef7000 RBX: ffff888000200000 RCX: 0000000000000000 [ 0.807829] RDX: 0000000000000000 RSI: 000000003bef7000 RDI: ffffffff82803c40 [ 0.807829] RBP: ffff88803bef7000 R08: 0000000000000000 R09: 0000000000000000 [ 0.807829] R10: ffff888000000000 R11: 000000ffffffffff R12: 0000000000000040 [ 0.807829] R13: 0000000000000020 R14: ffffffff82803e48 R15: ffff88803bf37000 [ 0.807829] FS: 0000000000000000(0000) GS:ffff88846fc00000(0000) knlGS:0000000000000000 [ 0.807829] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.807829] CR2: ffff88803bef7000 CR3: 000800000382e000 CR4: 00000000003506f0 [ 0.807829] Kernel panic - not syncing: Fatal exception [ 0.807829] ---[ end Kernel panic - not syncing: Fatal exception ]--- Thanks, Tom > >> 7. Add back the PRESENT bit, making the changed attribute visible >> >> With this approach, load_unaligned_zeropad() just takes its normal >> page-fault-based fixup path if it touches a page that is transitioning. >> As a result, load_unaligned_zeropad() and CoCo VM page transitioning >> are completely decoupled. CoCo VM page transitions can proceed >> without needing to handle architecture-specific exceptions and fix >> things up. This decoupling reduces the complexity due to separate >> TDX and SEV-SNP fixup paths, and gives more freedom to revise and >> introduce new capabilities in future versions of the TDX and SEV-SNP >> architectures. Paravisor scenarios work properly without needing >> to forward exceptions. >> >> With this approach, the order of updating the guest PTEs and >> notifying the hypervisor doesn't matter. As such, only a single >> hypervisor callback is needed, rather one before and one after >> the PTE update. Simplify the code by eliminating the extra >> hypervisor callback along with the TDX and SEV-SNP code that >> handles the before and after cases. The TLB flush callback is >> also no longer required and is removed. >> >> Signed-off-by: Michael Kelley <mikelley@microsoft.com> >> --- >> arch/x86/coco/tdx/tdx.c | 66 >> +------------------------------------------ >> arch/x86/hyperv/ivm.c | 6 ---- >> arch/x86/kernel/x86_init.c | 4 --- >> arch/x86/mm/mem_encrypt_amd.c | 27 ++++-------------- >> arch/x86/mm/pat/set_memory.c | 55 +++++++++++++++++++++++------------- >> 5 files changed, 43 insertions(+), 115 deletions(-) >> >> diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c >> index 3e6dbd2..1bb2fff 100644 >> --- a/arch/x86/coco/tdx/tdx.c >> +++ b/arch/x86/coco/tdx/tdx.c >> @@ -676,24 +676,6 @@ bool tdx_handle_virt_exception(struct pt_regs >> *regs, struct ve_info *ve) >> return true; >> } >> -static bool tdx_tlb_flush_required(bool private) >> -{ >> - /* >> - * TDX guest is responsible for flushing TLB on private->shared >> - * transition. VMM is responsible for flushing on shared->private. >> - * >> - * The VMM _can't_ flush private addresses as it can't generate PAs >> - * with the guest's HKID. Shared memory isn't subject to integrity >> - * checking, i.e. the VMM doesn't need to flush for its own >> protection. >> - * >> - * There's no need to flush when converting from shared to private, >> - * as flushing is the VMM's responsibility in this case, e.g. it must >> - * flush to avoid integrity failures in the face of a buggy or >> - * malicious guest. >> - */ >> - return !private; >> -} >> - >> static bool tdx_cache_flush_required(void) >> { >> /* >> @@ -776,30 +758,6 @@ static bool tdx_enc_status_changed(unsigned long >> vaddr, int numpages, bool enc) >> return true; >> } >> -static bool tdx_enc_status_change_prepare(unsigned long vaddr, int >> numpages, >> - bool enc) >> -{ >> - /* >> - * Only handle shared->private conversion here. >> - * See the comment in tdx_early_init(). >> - */ >> - if (enc) >> - return tdx_enc_status_changed(vaddr, numpages, enc); >> - return true; >> -} >> - >> -static bool tdx_enc_status_change_finish(unsigned long vaddr, int >> numpages, >> - bool enc) >> -{ >> - /* >> - * Only handle private->shared conversion here. >> - * See the comment in tdx_early_init(). >> - */ >> - if (!enc) >> - return tdx_enc_status_changed(vaddr, numpages, enc); >> - return true; >> -} >> - >> void __init tdx_early_init(void) >> { >> struct tdx_module_args args = { >> @@ -831,30 +789,8 @@ void __init tdx_early_init(void) >> */ >> physical_mask &= cc_mask - 1; >> - /* >> - * The kernel mapping should match the TDX metadata for the page. >> - * load_unaligned_zeropad() can touch memory *adjacent* to that >> which is >> - * owned by the caller and can catch even _momentary_ mismatches. Bad >> - * things happen on mismatch: >> - * >> - * - Private mapping => Shared Page == Guest shutdown >> - * - Shared mapping => Private Page == Recoverable #VE >> - * >> - * guest.enc_status_change_prepare() converts the page from >> - * shared=>private before the mapping becomes private. >> - * >> - * guest.enc_status_change_finish() converts the page from >> - * private=>shared after the mapping becomes private. >> - * >> - * In both cases there is a temporary shared mapping to a private >> page, >> - * which can result in a #VE. But, there is never a private >> mapping to >> - * a shared page. >> - */ >> - x86_platform.guest.enc_status_change_prepare = >> tdx_enc_status_change_prepare; >> - x86_platform.guest.enc_status_change_finish = >> tdx_enc_status_change_finish; >> - >> + x86_platform.guest.enc_status_change_finish = tdx_enc_status_changed; >> x86_platform.guest.enc_cache_flush_required = >> tdx_cache_flush_required; >> - x86_platform.guest.enc_tlb_flush_required = tdx_tlb_flush_required; >> /* >> * TDX intercepts the RDMSR to read the X2APIC ID in the parallel >> diff --git a/arch/x86/hyperv/ivm.c b/arch/x86/hyperv/ivm.c >> index 084fab6..fbe2585 100644 >> --- a/arch/x86/hyperv/ivm.c >> +++ b/arch/x86/hyperv/ivm.c >> @@ -550,11 +550,6 @@ static bool hv_vtom_set_host_visibility(unsigned >> long kbuffer, int pagecount, bo >> return result; >> } >> -static bool hv_vtom_tlb_flush_required(bool private) >> -{ >> - return true; >> -} >> - >> static bool hv_vtom_cache_flush_required(void) >> { >> return false; >> @@ -614,7 +609,6 @@ void __init hv_vtom_init(void) >> x86_platform.hyper.is_private_mmio = hv_is_private_mmio; >> x86_platform.guest.enc_cache_flush_required = >> hv_vtom_cache_flush_required; >> - x86_platform.guest.enc_tlb_flush_required = >> hv_vtom_tlb_flush_required; >> x86_platform.guest.enc_status_change_finish = >> hv_vtom_set_host_visibility; >> /* Set WB as the default cache mode. */ >> diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c >> index a37ebd3..cf5179b 100644 >> --- a/arch/x86/kernel/x86_init.c >> +++ b/arch/x86/kernel/x86_init.c >> @@ -131,9 +131,7 @@ struct x86_cpuinit_ops x86_cpuinit = { >> static void default_nmi_init(void) { }; >> -static bool enc_status_change_prepare_noop(unsigned long vaddr, int >> npages, bool enc) { return true; } >> static bool enc_status_change_finish_noop(unsigned long vaddr, int >> npages, bool enc) { return true; } >> -static bool enc_tlb_flush_required_noop(bool enc) { return false; } >> static bool enc_cache_flush_required_noop(void) { return false; } >> static bool is_private_mmio_noop(u64 addr) {return false; } >> @@ -154,9 +152,7 @@ struct x86_platform_ops x86_platform __ro_after_init >> = { >> .hyper.is_private_mmio = is_private_mmio_noop, >> .guest = { >> - .enc_status_change_prepare = enc_status_change_prepare_noop, >> .enc_status_change_finish = enc_status_change_finish_noop, >> - .enc_tlb_flush_required = enc_tlb_flush_required_noop, >> .enc_cache_flush_required = enc_cache_flush_required_noop, >> }, >> }; >> diff --git a/arch/x86/mm/mem_encrypt_amd.c b/arch/x86/mm/mem_encrypt_amd.c >> index 6faea41..06960ba 100644 >> --- a/arch/x86/mm/mem_encrypt_amd.c >> +++ b/arch/x86/mm/mem_encrypt_amd.c >> @@ -278,11 +278,6 @@ static unsigned long pg_level_to_pfn(int level, >> pte_t *kpte, pgprot_t *ret_prot) >> return pfn; >> } >> -static bool amd_enc_tlb_flush_required(bool enc) >> -{ >> - return true; >> -} >> - >> static bool amd_enc_cache_flush_required(void) >> { >> return !cpu_feature_enabled(X86_FEATURE_SME_COHERENT); >> @@ -318,18 +313,6 @@ static void enc_dec_hypercall(unsigned long vaddr, >> unsigned long size, bool enc) >> #endif >> } >> -static bool amd_enc_status_change_prepare(unsigned long vaddr, int >> npages, bool enc) >> -{ >> - /* >> - * To maintain the security guarantees of SEV-SNP guests, make sure >> - * to invalidate the memory before encryption attribute is cleared. >> - */ >> - if (cc_platform_has(CC_ATTR_GUEST_SEV_SNP) && !enc) >> - snp_set_memory_shared(vaddr, npages); >> - >> - return true; >> -} >> - >> /* Return true unconditionally: return value doesn't matter for the >> SEV side */ >> static bool amd_enc_status_change_finish(unsigned long vaddr, int >> npages, bool enc) >> { >> @@ -337,8 +320,12 @@ static bool amd_enc_status_change_finish(unsigned >> long vaddr, int npages, bool e >> * After memory is mapped encrypted in the page table, validate it >> * so that it is consistent with the page table updates. >> */ >> - if (cc_platform_has(CC_ATTR_GUEST_SEV_SNP) && enc) >> - snp_set_memory_private(vaddr, npages); >> + if (cc_platform_has(CC_ATTR_GUEST_SEV_SNP)) { >> + if (enc) >> + snp_set_memory_private(vaddr, npages); >> + else >> + snp_set_memory_shared(vaddr, npages); >> + } > > These calls will both result in a PVALIDATE being issued (either before or > after the page state change to the hypervisor) using the virtual address, > which will trigger a #PF is the present bit isn't set. > >> if (!cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT)) >> enc_dec_hypercall(vaddr, npages << PAGE_SHIFT, enc); >> @@ -498,9 +485,7 @@ void __init sme_early_init(void) >> /* Update the protection map with memory encryption mask */ >> add_encrypt_protection_map(); >> - x86_platform.guest.enc_status_change_prepare = >> amd_enc_status_change_prepare; >> x86_platform.guest.enc_status_change_finish = >> amd_enc_status_change_finish; >> - x86_platform.guest.enc_tlb_flush_required = >> amd_enc_tlb_flush_required; >> x86_platform.guest.enc_cache_flush_required = >> amd_enc_cache_flush_required; >> /* >> diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c >> index d7ef8d3..d062e01 100644 >> --- a/arch/x86/mm/pat/set_memory.c >> +++ b/arch/x86/mm/pat/set_memory.c >> @@ -2147,40 +2147,57 @@ static int __set_memory_enc_pgtable(unsigned >> long addr, int numpages, bool enc) >> memset(&cpa, 0, sizeof(cpa)); >> cpa.vaddr = &addr; >> cpa.numpages = numpages; >> + >> + /* >> + * The caller must ensure that the memory being transitioned between >> + * encrypted and decrypted is not being accessed. But if >> + * load_unaligned_zeropad() touches the "next" page, it may generate a >> + * read access the caller has no control over. To ensure such accesses >> + * cause a normal page fault for the load_unaligned_zeropad() handler, >> + * mark the pages not present until the transition is complete. We >> + * don't want a #VE or #VC fault due to a mismatch in the memory >> + * encryption status, since paravisor configurations can't cleanly do >> + * the load_unaligned_zeropad() handling in the paravisor. >> + * >> + * There's no requirement to do so, but for efficiency we can clear >> + * _PAGE_PRESENT and set/clr encryption attr as a single operation. >> + */ >> cpa.mask_set = enc ? pgprot_encrypted(empty) : >> pgprot_decrypted(empty); >> - cpa.mask_clr = enc ? pgprot_decrypted(empty) : >> pgprot_encrypted(empty); >> + cpa.mask_clr = enc ? pgprot_decrypted(__pgprot(_PAGE_PRESENT)) : >> + pgprot_encrypted(__pgprot(_PAGE_PRESENT)); > > This should be lined up with the pgprot_decrypted above, e.g.: > > cpa.mask_clr = enc ? pgprot_decrypted(__pgprot(_PAGE_PRESENT)) : > pgprot_encrypted(__pgprot(_PAGE_PRESENT)); > > or > > cpa.mask_clr = enc ? pgprot_decrypted(__pgprot(_PAGE_PRESENT)) > : pgprot_encrypted(__pgprot(_PAGE_PRESENT)); > >> cpa.pgd = init_mm.pgd; >> /* Must avoid aliasing mappings in the highmem code */ >> kmap_flush_unused(); >> vm_unmap_aliases(); >> - /* Flush the caches as needed before changing the encryption >> attribute. */ >> - if (x86_platform.guest.enc_tlb_flush_required(enc)) >> - cpa_flush(&cpa, x86_platform.guest.enc_cache_flush_required()); >> - >> - /* Notify hypervisor that we are about to set/clr encryption >> attribute. */ >> - if (!x86_platform.guest.enc_status_change_prepare(addr, numpages, >> enc)) >> - return -EIO; >> + /* Flush the caches as needed before changing the encryption attr. */ >> + if (x86_platform.guest.enc_cache_flush_required()) >> + cpa_flush(&cpa, 1); >> ret = __change_page_attr_set_clr(&cpa, 1); >> + if (ret) >> + return ret; >> /* >> - * After changing the encryption attribute, we need to flush TLBs >> again >> - * in case any speculative TLB caching occurred (but no need to flush >> - * caches again). We could just use cpa_flush_all(), but in case TLB >> - * flushing gets optimized in the cpa_flush() path use the same logic >> - * as above. >> + * After clearing _PAGE_PRESENT and changing the encryption attribute, >> + * we need to flush TLBs to ensure no further accesses to the >> memory can >> + * be made with the old encryption attribute (but no need to flush >> caches >> + * again). We could just use cpa_flush_all(), but in case TLB >> flushing >> + * gets optimized in the cpa_flush() path use the same logic as above. >> */ >> cpa_flush(&cpa, 0); >> - /* Notify hypervisor that we have successfully set/clr encryption >> attribute. */ >> - if (!ret) { >> - if (!x86_platform.guest.enc_status_change_finish(addr, >> numpages, enc)) >> - ret = -EIO; >> - } >> + /* Notify hypervisor that we have successfully set/clr encryption >> attr. */ >> + if (!x86_platform.guest.enc_status_change_finish(addr, numpages, enc)) >> + return -EIO; > > Here's where the #PF is likely to be triggered. > > Thanks, > Tom > >> - return ret; >> + /* >> + * Now that the hypervisor is sync'ed with the page table changes >> + * made here, add back _PAGE_PRESENT. set_memory_p() does not flush >> + * the TLB. >> + */ >> + return set_memory_p(&addr, numpages); >> } >> static int __set_memory_enc_dec(unsigned long addr, int numpages, bool >> enc)
From: Tom Lendacky <thomas.lendacky@amd.com> Sent: Monday, October 2, 2023 11:59 AM > > On 10/2/23 11:35, Tom Lendacky wrote: > > On 9/29/23 13:19, Michael Kelley wrote: > >> In a CoCo VM when a page transitions from encrypted to decrypted, or vice > >> versa, attributes in the PTE must be updated *and* the hypervisor must > >> be notified of the change. Because there are two separate steps, there's > >> a window where the settings are inconsistent. Normally the code that > >> initiates the transition (via set_memory_decrypted() or > >> set_memory_encrypted()) ensures that the memory is not being accessed > >> during a transition, so the window of inconsistency is not a problem. > >> However, the load_unaligned_zeropad() function can read arbitrary memory > >> pages at arbitrary times, which could access a transitioning page during > >> the window. In such a case, CoCo VM specific exceptions are taken > >> (depending on the CoCo architecture in use). Current code in those > >> exception handlers recovers and does "fixup" on the result returned by > >> load_unaligned_zeropad(). Unfortunately, this exception handling can't > >> work in paravisor scenarios (TDX Paritioning and SEV-SNP in vTOM mode). > >> The exceptions need to be forwarded from the paravisor to the Linux > >> guest, but there are no architectural specs for how to do that. > >> > >> Fortunately, there's a simpler way to solve the problem by changing > >> the core transition code in __set_memory_enc_pgtable() to do the > >> following: > >> > >> 1. Remove aliasing mappings > >> 2. Flush the data cache if needed > >> 3. Remove the PRESENT bit from the PTEs of all transitioning pages > >> 4. Set/clear the encryption attribute as appropriate > >> 5. Flush the TLB so the changed encryption attribute isn't visible > >> 6. Notify the hypervisor of the encryption status change > > > > Not sure why I didn't notice this before, but I will need to test this to > > be certain. As part of this notification, the SNP support will issue a > > PVALIDATE instruction (to either validate or rescind validation to the > > page). PVALIDATE takes a virtual address. If the PRESENT bit has been > > removed, the PVALIDATE instruction will take a #PF (see comments below). > > Yes, this series results in a #PF booting an SNP guest: Bummer :-( Interestingly, an SNP guest on Hyper-V with a paravisor works, presumably because the paravisor is doing the PVALIDATE with a different guest virtual address for the physical page. TDX operates on physical addresses, and I've tested that it works. The spec for PVALIDATE says it performs the same segmentation and paging checks as a 1-byte read, so indeed, the #PF is expected. But in the spec, the pseudo-code for PVALIDATE uses the GUEST_VA only to derive the GUEST_PA and the SYSTEM_PA. The GUEST_VA isn't otherwise relevant, so any GUEST_VA that validly maps to the GUEST_PA would work, as long as we can be assured that load_unaligned_zeropad() won't touch that GUEST_VA. Let me think about if there's a not-too-hacky way to make this work with some temporary GVA. Michael > > [ 0.807735] BUG: unable to handle page fault for address: ffff88803bef7000 > [ 0.807829] #PF: supervisor read access in kernel mode > [ 0.807829] #PF: error_code(0x0000) - not-present page > [ 0.807829] PGD 8000004c01067 P4D 8000004c01067 PUD 8000004c02067 PMD > 80001001f8063 PTE 8007ffffc4108062 > [ 0.807829] Oops: 0000 [#1] PREEMPT SMP NOPTI > [ 0.807829] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.6.0-rc3-sos-testing #1 > [ 0.807829] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown > 2/2/2022 > [ 0.807829] RIP: 0010:pvalidate_pages+0x99/0x140 > [ 0.807829] Code: 48 09 ca 0f b6 4c c7 0f 48 09 d6 0f b6 54 c7 0e 48 c1 e6 0c 4c 21 > de 83 e2 f0 80 fa 10 4a 8d 2c 16 0f 94 c2 48 89 e8 83 e1 01 <f2> 0f 01 ff 41 89 c4 72 6 > 1 83 f8 06 75 45 84 c9 74 41 48 01 de 48 > [ 0.807829] RSP: 0000:ffffffff82803bd0 EFLAGS: 00010246 > [ 0.807829] RAX: ffff88803bef7000 RBX: ffff888000200000 RCX: > 0000000000000000 > [ 0.807829] RDX: 0000000000000000 RSI: 000000003bef7000 RDI: ffffffff82803c40 > [ 0.807829] RBP: ffff88803bef7000 R08: 0000000000000000 R09: > 0000000000000000 > [ 0.807829] R10: ffff888000000000 R11: 000000ffffffffff R12: 0000000000000040 > [ 0.807829] R13: 0000000000000020 R14: ffffffff82803e48 R15: ffff88803bf37000 > [ 0.807829] FS: 0000000000000000(0000) GS:ffff88846fc00000(0000) > knlGS:0000000000000000 > [ 0.807829] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 0.807829] CR2: ffff88803bef7000 CR3: 000800000382e000 CR4: > 00000000003506f0 > [ 0.807829] Call Trace: > [ 0.807829] <TASK> > [ 0.807829] ? __die+0x1f/0x70 > [ 0.807829] ? page_fault_oops+0x81/0x150 > [ 0.807829] ? srso_return_thunk+0x5/0x5f > [ 0.807829] ? kernelmode_fixup_or_oops+0x84/0x110 > [ 0.807829] ? exc_page_fault+0xa8/0x150 > [ 0.807829] ? asm_exc_page_fault+0x22/0x30 > [ 0.807829] ? pvalidate_pages+0x99/0x140 > [ 0.807829] __set_pages_state+0x280/0x2b0 > [ 0.807829] set_pages_state+0x4e/0xa0 > [ 0.807829] amd_enc_status_change_finish+0x4a/0x80 > [ 0.807829] __set_memory_enc_dec+0xe1/0x190 > [ 0.807829] mem_encrypt_init+0x15/0xc0 > [ 0.807829] start_kernel+0x31b/0x5e0 > [ 0.807829] x86_64_start_reservations+0x14/0x30 > [ 0.807829] x86_64_start_kernel+0x79/0x80 > [ 0.807829] secondary_startup_64_no_verify+0x16b/0x16b > [ 0.807829] </TASK> > [ 0.807829] Modules linked in: > [ 0.807829] CR2: ffff88803bef7000 > [ 0.807829] ---[ end trace 0000000000000000 ]--- > [ 0.807829] RIP: 0010:pvalidate_pages+0x99/0x140 > [ 0.807829] Code: 48 09 ca 0f b6 4c c7 0f 48 09 d6 0f b6 54 c7 0e 48 c1 e6 0c 4c 21 > de 83 e2 f0 80 fa 10 4a 8d 2c 16 0f 94 c2 48 89 e8 83 e1 01 <f2> 0f 01 ff 41 89 c4 72 6 > 1 83 f8 06 75 45 84 c9 74 41 48 01 de 48 > [ 0.807829] RSP: 0000:ffffffff82803bd0 EFLAGS: 00010246 > [ 0.807829] RAX: ffff88803bef7000 RBX: ffff888000200000 RCX: > 0000000000000000 > [ 0.807829] RDX: 0000000000000000 RSI: 000000003bef7000 RDI: ffffffff82803c40 > [ 0.807829] RBP: ffff88803bef7000 R08: 0000000000000000 R09: > 0000000000000000 > [ 0.807829] R10: ffff888000000000 R11: 000000ffffffffff R12: 0000000000000040 > [ 0.807829] R13: 0000000000000020 R14: ffffffff82803e48 R15: ffff88803bf37000 > [ 0.807829] FS: 0000000000000000(0000) GS:ffff88846fc00000(0000) > knlGS:0000000000000000 > [ 0.807829] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 0.807829] CR2: ffff88803bef7000 CR3: 000800000382e000 CR4: > 00000000003506f0 > [ 0.807829] Kernel panic - not syncing: Fatal exception > [ 0.807829] ---[ end Kernel panic - not syncing: Fatal exception ]--- > > > Thanks, > Tom > > > > >> 7. Add back the PRESENT bit, making the changed attribute visible > >> > >> With this approach, load_unaligned_zeropad() just takes its normal > >> page-fault-based fixup path if it touches a page that is transitioning. > >> As a result, load_unaligned_zeropad() and CoCo VM page transitioning > >> are completely decoupled. CoCo VM page transitions can proceed > >> without needing to handle architecture-specific exceptions and fix > >> things up. This decoupling reduces the complexity due to separate > >> TDX and SEV-SNP fixup paths, and gives more freedom to revise and > >> introduce new capabilities in future versions of the TDX and SEV-SNP > >> architectures. Paravisor scenarios work properly without needing > >> to forward exceptions. > >> > >> With this approach, the order of updating the guest PTEs and > >> notifying the hypervisor doesn't matter. As such, only a single > >> hypervisor callback is needed, rather one before and one after > >> the PTE update. Simplify the code by eliminating the extra > >> hypervisor callback along with the TDX and SEV-SNP code that > >> handles the before and after cases. The TLB flush callback is > >> also no longer required and is removed. > >> > >> Signed-off-by: Michael Kelley <mikelley@microsoft.com> > >> --- > >> arch/x86/coco/tdx/tdx.c | 66 > >> +------------------------------------------ > >> arch/x86/hyperv/ivm.c | 6 ---- > >> arch/x86/kernel/x86_init.c | 4 --- > >> arch/x86/mm/mem_encrypt_amd.c | 27 ++++-------------- > >> arch/x86/mm/pat/set_memory.c | 55 +++++++++++++++++++++++------------- > >> 5 files changed, 43 insertions(+), 115 deletions(-) > >> > >> diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c > >> index 3e6dbd2..1bb2fff 100644 > >> --- a/arch/x86/coco/tdx/tdx.c > >> +++ b/arch/x86/coco/tdx/tdx.c > >> @@ -676,24 +676,6 @@ bool tdx_handle_virt_exception(struct pt_regs > >> *regs, struct ve_info *ve) > >> return true; > >> } > >> -static bool tdx_tlb_flush_required(bool private) > >> -{ > >> - /* > >> - * TDX guest is responsible for flushing TLB on private->shared > >> - * transition. VMM is responsible for flushing on shared->private. > >> - * > >> - * The VMM _can't_ flush private addresses as it can't generate PAs > >> - * with the guest's HKID. Shared memory isn't subject to integrity > >> - * checking, i.e. the VMM doesn't need to flush for its own > >> protection. > >> - * > >> - * There's no need to flush when converting from shared to private, > >> - * as flushing is the VMM's responsibility in this case, e.g. it must > >> - * flush to avoid integrity failures in the face of a buggy or > >> - * malicious guest. > >> - */ > >> - return !private; > >> -} > >> - > >> static bool tdx_cache_flush_required(void) > >> { > >> /* > >> @@ -776,30 +758,6 @@ static bool tdx_enc_status_changed(unsigned long > >> vaddr, int numpages, bool enc) > >> return true; > >> } > >> -static bool tdx_enc_status_change_prepare(unsigned long vaddr, int > >> numpages, > >> - bool enc) > >> -{ > >> - /* > >> - * Only handle shared->private conversion here. > >> - * See the comment in tdx_early_init(). > >> - */ > >> - if (enc) > >> - return tdx_enc_status_changed(vaddr, numpages, enc); > >> - return true; > >> -} > >> - > >> -static bool tdx_enc_status_change_finish(unsigned long vaddr, int > >> numpages, > >> - bool enc) > >> -{ > >> - /* > >> - * Only handle private->shared conversion here. > >> - * See the comment in tdx_early_init(). > >> - */ > >> - if (!enc) > >> - return tdx_enc_status_changed(vaddr, numpages, enc); > >> - return true; > >> -} > >> - > >> void __init tdx_early_init(void) > >> { > >> struct tdx_module_args args = { > >> @@ -831,30 +789,8 @@ void __init tdx_early_init(void) > >> */ > >> physical_mask &= cc_mask - 1; > >> - /* > >> - * The kernel mapping should match the TDX metadata for the page. > >> - * load_unaligned_zeropad() can touch memory *adjacent* to that > >> which is > >> - * owned by the caller and can catch even _momentary_ mismatches. Bad > >> - * things happen on mismatch: > >> - * > >> - * - Private mapping => Shared Page == Guest shutdown > >> - * - Shared mapping => Private Page == Recoverable #VE > >> - * > >> - * guest.enc_status_change_prepare() converts the page from > >> - * shared=>private before the mapping becomes private. > >> - * > >> - * guest.enc_status_change_finish() converts the page from > >> - * private=>shared after the mapping becomes private. > >> - * > >> - * In both cases there is a temporary shared mapping to a private > >> page, > >> - * which can result in a #VE. But, there is never a private > >> mapping to > >> - * a shared page. > >> - */ > >> - x86_platform.guest.enc_status_change_prepare = > >> tdx_enc_status_change_prepare; > >> - x86_platform.guest.enc_status_change_finish = > >> tdx_enc_status_change_finish; > >> - > >> + x86_platform.guest.enc_status_change_finish = tdx_enc_status_changed; > >> x86_platform.guest.enc_cache_flush_required = > >> tdx_cache_flush_required; > >> - x86_platform.guest.enc_tlb_flush_required = tdx_tlb_flush_required; > >> /* > >> * TDX intercepts the RDMSR to read the X2APIC ID in the parallel > >> diff --git a/arch/x86/hyperv/ivm.c b/arch/x86/hyperv/ivm.c > >> index 084fab6..fbe2585 100644 > >> --- a/arch/x86/hyperv/ivm.c > >> +++ b/arch/x86/hyperv/ivm.c > >> @@ -550,11 +550,6 @@ static bool hv_vtom_set_host_visibility(unsigned > >> long kbuffer, int pagecount, bo > >> return result; > >> } > >> -static bool hv_vtom_tlb_flush_required(bool private) > >> -{ > >> - return true; > >> -} > >> - > >> static bool hv_vtom_cache_flush_required(void) > >> { > >> return false; > >> @@ -614,7 +609,6 @@ void __init hv_vtom_init(void) > >> x86_platform.hyper.is_private_mmio = hv_is_private_mmio; > >> x86_platform.guest.enc_cache_flush_required = > >> hv_vtom_cache_flush_required; > >> - x86_platform.guest.enc_tlb_flush_required = > >> hv_vtom_tlb_flush_required; > >> x86_platform.guest.enc_status_change_finish = > >> hv_vtom_set_host_visibility; > >> /* Set WB as the default cache mode. */ > >> diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c > >> index a37ebd3..cf5179b 100644 > >> --- a/arch/x86/kernel/x86_init.c > >> +++ b/arch/x86/kernel/x86_init.c > >> @@ -131,9 +131,7 @@ struct x86_cpuinit_ops x86_cpuinit = { > >> static void default_nmi_init(void) { }; > >> -static bool enc_status_change_prepare_noop(unsigned long vaddr, int > >> npages, bool enc) { return true; } > >> static bool enc_status_change_finish_noop(unsigned long vaddr, int > >> npages, bool enc) { return true; } > >> -static bool enc_tlb_flush_required_noop(bool enc) { return false; } > >> static bool enc_cache_flush_required_noop(void) { return false; } > >> static bool is_private_mmio_noop(u64 addr) {return false; } > >> @@ -154,9 +152,7 @@ struct x86_platform_ops x86_platform __ro_after_init > >> = { > >> .hyper.is_private_mmio = is_private_mmio_noop, > >> .guest = { > >> - .enc_status_change_prepare = enc_status_change_prepare_noop, > >> .enc_status_change_finish = enc_status_change_finish_noop, > >> - .enc_tlb_flush_required = enc_tlb_flush_required_noop, > >> .enc_cache_flush_required = enc_cache_flush_required_noop, > >> }, > >> }; > >> diff --git a/arch/x86/mm/mem_encrypt_amd.c > b/arch/x86/mm/mem_encrypt_amd.c > >> index 6faea41..06960ba 100644 > >> --- a/arch/x86/mm/mem_encrypt_amd.c > >> +++ b/arch/x86/mm/mem_encrypt_amd.c > >> @@ -278,11 +278,6 @@ static unsigned long pg_level_to_pfn(int level, > >> pte_t *kpte, pgprot_t *ret_prot) > >> return pfn; > >> } > >> -static bool amd_enc_tlb_flush_required(bool enc) > >> -{ > >> - return true; > >> -} > >> - > >> static bool amd_enc_cache_flush_required(void) > >> { > >> return !cpu_feature_enabled(X86_FEATURE_SME_COHERENT); > >> @@ -318,18 +313,6 @@ static void enc_dec_hypercall(unsigned long vaddr, > >> unsigned long size, bool enc) > >> #endif > >> } > >> -static bool amd_enc_status_change_prepare(unsigned long vaddr, int > >> npages, bool enc) > >> -{ > >> - /* > >> - * To maintain the security guarantees of SEV-SNP guests, make sure > >> - * to invalidate the memory before encryption attribute is cleared. > >> - */ > >> - if (cc_platform_has(CC_ATTR_GUEST_SEV_SNP) && !enc) > >> - snp_set_memory_shared(vaddr, npages); > >> - > >> - return true; > >> -} > >> - > >> /* Return true unconditionally: return value doesn't matter for the > >> SEV side */ > >> static bool amd_enc_status_change_finish(unsigned long vaddr, int > >> npages, bool enc) > >> { > >> @@ -337,8 +320,12 @@ static bool amd_enc_status_change_finish(unsigned > >> long vaddr, int npages, bool e > >> * After memory is mapped encrypted in the page table, validate it > >> * so that it is consistent with the page table updates. > >> */ > >> - if (cc_platform_has(CC_ATTR_GUEST_SEV_SNP) && enc) > >> - snp_set_memory_private(vaddr, npages); > >> + if (cc_platform_has(CC_ATTR_GUEST_SEV_SNP)) { > >> + if (enc) > >> + snp_set_memory_private(vaddr, npages); > >> + else > >> + snp_set_memory_shared(vaddr, npages); > >> + } > > > > These calls will both result in a PVALIDATE being issued (either before or > > after the page state change to the hypervisor) using the virtual address, > > which will trigger a #PF is the present bit isn't set. > > > >> if (!cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT)) > >> enc_dec_hypercall(vaddr, npages << PAGE_SHIFT, enc); > >> @@ -498,9 +485,7 @@ void __init sme_early_init(void) > >> /* Update the protection map with memory encryption mask */ > >> add_encrypt_protection_map(); > >> - x86_platform.guest.enc_status_change_prepare = > >> amd_enc_status_change_prepare; > >> x86_platform.guest.enc_status_change_finish = > >> amd_enc_status_change_finish; > >> - x86_platform.guest.enc_tlb_flush_required = > >> amd_enc_tlb_flush_required; > >> x86_platform.guest.enc_cache_flush_required = > >> amd_enc_cache_flush_required; > >> /* > >> diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c > >> index d7ef8d3..d062e01 100644 > >> --- a/arch/x86/mm/pat/set_memory.c > >> +++ b/arch/x86/mm/pat/set_memory.c > >> @@ -2147,40 +2147,57 @@ static int __set_memory_enc_pgtable(unsigned > >> long addr, int numpages, bool enc) > >> memset(&cpa, 0, sizeof(cpa)); > >> cpa.vaddr = &addr; > >> cpa.numpages = numpages; > >> + > >> + /* > >> + * The caller must ensure that the memory being transitioned between > >> + * encrypted and decrypted is not being accessed. But if > >> + * load_unaligned_zeropad() touches the "next" page, it may generate a > >> + * read access the caller has no control over. To ensure such accesses > >> + * cause a normal page fault for the load_unaligned_zeropad() handler, > >> + * mark the pages not present until the transition is complete. We > >> + * don't want a #VE or #VC fault due to a mismatch in the memory > >> + * encryption status, since paravisor configurations can't cleanly do > >> + * the load_unaligned_zeropad() handling in the paravisor. > >> + * > >> + * There's no requirement to do so, but for efficiency we can clear > >> + * _PAGE_PRESENT and set/clr encryption attr as a single operation. > >> + */ > >> cpa.mask_set = enc ? pgprot_encrypted(empty) : > >> pgprot_decrypted(empty); > >> - cpa.mask_clr = enc ? pgprot_decrypted(empty) : > >> pgprot_encrypted(empty); > >> + cpa.mask_clr = enc ? pgprot_decrypted(__pgprot(_PAGE_PRESENT)) : > >> + pgprot_encrypted(__pgprot(_PAGE_PRESENT)); > > > > This should be lined up with the pgprot_decrypted above, e.g.: > > > > cpa.mask_clr = enc ? pgprot_decrypted(__pgprot(_PAGE_PRESENT)) : > > pgprot_encrypted(__pgprot(_PAGE_PRESENT)); > > > > or > > > > cpa.mask_clr = enc ? pgprot_decrypted(__pgprot(_PAGE_PRESENT)) > > : pgprot_encrypted(__pgprot(_PAGE_PRESENT)); > > > >> cpa.pgd = init_mm.pgd; > >> /* Must avoid aliasing mappings in the highmem code */ > >> kmap_flush_unused(); > >> vm_unmap_aliases(); > >> - /* Flush the caches as needed before changing the encryption > >> attribute. */ > >> - if (x86_platform.guest.enc_tlb_flush_required(enc)) > >> - cpa_flush(&cpa, x86_platform.guest.enc_cache_flush_required()); > >> - > >> - /* Notify hypervisor that we are about to set/clr encryption > >> attribute. */ > >> - if (!x86_platform.guest.enc_status_change_prepare(addr, numpages, > >> enc)) > >> - return -EIO; > >> + /* Flush the caches as needed before changing the encryption attr. */ > >> + if (x86_platform.guest.enc_cache_flush_required()) > >> + cpa_flush(&cpa, 1); > >> ret = __change_page_attr_set_clr(&cpa, 1); > >> + if (ret) > >> + return ret; > >> /* > >> - * After changing the encryption attribute, we need to flush TLBs > >> again > >> - * in case any speculative TLB caching occurred (but no need to flush > >> - * caches again). We could just use cpa_flush_all(), but in case TLB > >> - * flushing gets optimized in the cpa_flush() path use the same logic > >> - * as above. > >> + * After clearing _PAGE_PRESENT and changing the encryption attribute, > >> + * we need to flush TLBs to ensure no further accesses to the > >> memory can > >> + * be made with the old encryption attribute (but no need to flush > >> caches > >> + * again). We could just use cpa_flush_all(), but in case TLB > >> flushing > >> + * gets optimized in the cpa_flush() path use the same logic as above. > >> */ > >> cpa_flush(&cpa, 0); > >> - /* Notify hypervisor that we have successfully set/clr encryption > >> attribute. */ > >> - if (!ret) { > >> - if (!x86_platform.guest.enc_status_change_finish(addr, > >> numpages, enc)) > >> - ret = -EIO; > >> - } > >> + /* Notify hypervisor that we have successfully set/clr encryption > >> attr. */ > >> + if (!x86_platform.guest.enc_status_change_finish(addr, numpages, enc)) > >> + return -EIO; > > > > Here's where the #PF is likely to be triggered. > > > > Thanks, > > Tom > > > >> - return ret; > >> + /* > >> + * Now that the hypervisor is sync'ed with the page table changes > >> + * made here, add back _PAGE_PRESENT. set_memory_p() does not flush > >> + * the TLB. > >> + */ > >> + return set_memory_p(&addr, numpages); > >> } > >> static int __set_memory_enc_dec(unsigned long addr, int numpages, bool > >> enc)
From: Michael Kelley (LINUX) <mikelley@microsoft.com> Sent: Monday, October 2, 2023 1:43 PM > > From: Tom Lendacky <thomas.lendacky@amd.com> Sent: Monday, October 2, 2023 > 11:59 AM > > > > On 10/2/23 11:35, Tom Lendacky wrote: > > > On 9/29/23 13:19, Michael Kelley wrote: > > >> In a CoCo VM when a page transitions from encrypted to decrypted, or vice > > >> versa, attributes in the PTE must be updated *and* the hypervisor must > > >> be notified of the change. Because there are two separate steps, there's > > >> a window where the settings are inconsistent. Normally the code that > > >> initiates the transition (via set_memory_decrypted() or > > >> set_memory_encrypted()) ensures that the memory is not being accessed > > >> during a transition, so the window of inconsistency is not a problem. > > >> However, the load_unaligned_zeropad() function can read arbitrary memory > > >> pages at arbitrary times, which could access a transitioning page during > > >> the window. In such a case, CoCo VM specific exceptions are taken > > >> (depending on the CoCo architecture in use). Current code in those > > >> exception handlers recovers and does "fixup" on the result returned by > > >> load_unaligned_zeropad(). Unfortunately, this exception handling can't > > >> work in paravisor scenarios (TDX Paritioning and SEV-SNP in vTOM mode). > > >> The exceptions need to be forwarded from the paravisor to the Linux > > >> guest, but there are no architectural specs for how to do that. > > >> > > >> Fortunately, there's a simpler way to solve the problem by changing > > >> the core transition code in __set_memory_enc_pgtable() to do the > > >> following: > > >> > > >> 1. Remove aliasing mappings > > >> 2. Flush the data cache if needed > > >> 3. Remove the PRESENT bit from the PTEs of all transitioning pages > > >> 4. Set/clear the encryption attribute as appropriate > > >> 5. Flush the TLB so the changed encryption attribute isn't visible > > >> 6. Notify the hypervisor of the encryption status change > > > > > > Not sure why I didn't notice this before, but I will need to test this to > > > be certain. As part of this notification, the SNP support will issue a > > > PVALIDATE instruction (to either validate or rescind validation to the > > > page). PVALIDATE takes a virtual address. If the PRESENT bit has been > > > removed, the PVALIDATE instruction will take a #PF (see comments below). > > > > Yes, this series results in a #PF booting an SNP guest: > > Bummer :-( Interestingly, an SNP guest on Hyper-V with a paravisor > works, presumably because the paravisor is doing the PVALIDATE with > a different guest virtual address for the physical page. TDX operates > on physical addresses, and I've tested that it works. > > The spec for PVALIDATE says it performs the same segmentation > and paging checks as a 1-byte read, so indeed, the #PF is expected. > But in the spec, the pseudo-code for PVALIDATE uses the GUEST_VA > only to derive the GUEST_PA and the SYSTEM_PA. The GUEST_VA isn't > otherwise relevant, so any GUEST_VA that validly maps to the GUEST_PA > would work, as long as we can be assured that load_unaligned_zeropad() > won't touch that GUEST_VA. > > Let me think about if there's a not-too-hacky way to make this work > with some temporary GVA. > It seems like there are two possible approaches to make this work: 1. Create a temporary virtual mapping in vmalloc space and pass that virtual address to PVALIDATE. (But only do this when PVALIDATE is being used for private <-> shared transitions, and not for memory acceptance.) The temporary mapping is updated with each invocation of PVALIDATE. To make this work, the temp virtual addr must be aligned on a 2 Meg boundary and must have a guard page preceding it so that load_unaligned_zeropad() can't stumble into the temporary mapping. I've wrestled with a few approaches to coding this over the past two weeks, and have something that's not too bad. This approach certainly takes some additional CPU cycles. I've tested doing the temp mapping in the context of a Hyper-V vTOM VM, but don't see any measurable impact on boot time, even when converting a 1 Gbyte swiotlb space from private to shared. I'm setting up now to test in a regular SNP VM where snp_enc_status_change_finish() is used, to have end-to-end confirmation that it really does work. 2. A completely different approach is for __set_memory_enc_pgtable() to clear and restore the PRESENT bit only when REFLECT_VC is set in the MSR_AMD64_SEV, and the equivalent on TDX. This is the case that's problematic for doing the load_unaligned_zeropad() fix up in the SNP #VC or TDX #VE exception handler. I think you said some additional work was needed for the fixup to be done properly in the SNP #VC case, so that would have to be done. The cleared PRESENT bit is handled by the paravisor because the paravisor already has a virtual mapping to pass to PVALIDATE. Any thoughts? I'll try to get the code for #1 posted in the next few days, so you can judge the level of additional complexity to manage the temp virtual mapping. Michael
diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c index 3e6dbd2..1bb2fff 100644 --- a/arch/x86/coco/tdx/tdx.c +++ b/arch/x86/coco/tdx/tdx.c @@ -676,24 +676,6 @@ bool tdx_handle_virt_exception(struct pt_regs *regs, struct ve_info *ve) return true; } -static bool tdx_tlb_flush_required(bool private) -{ - /* - * TDX guest is responsible for flushing TLB on private->shared - * transition. VMM is responsible for flushing on shared->private. - * - * The VMM _can't_ flush private addresses as it can't generate PAs - * with the guest's HKID. Shared memory isn't subject to integrity - * checking, i.e. the VMM doesn't need to flush for its own protection. - * - * There's no need to flush when converting from shared to private, - * as flushing is the VMM's responsibility in this case, e.g. it must - * flush to avoid integrity failures in the face of a buggy or - * malicious guest. - */ - return !private; -} - static bool tdx_cache_flush_required(void) { /* @@ -776,30 +758,6 @@ static bool tdx_enc_status_changed(unsigned long vaddr, int numpages, bool enc) return true; } -static bool tdx_enc_status_change_prepare(unsigned long vaddr, int numpages, - bool enc) -{ - /* - * Only handle shared->private conversion here. - * See the comment in tdx_early_init(). - */ - if (enc) - return tdx_enc_status_changed(vaddr, numpages, enc); - return true; -} - -static bool tdx_enc_status_change_finish(unsigned long vaddr, int numpages, - bool enc) -{ - /* - * Only handle private->shared conversion here. - * See the comment in tdx_early_init(). - */ - if (!enc) - return tdx_enc_status_changed(vaddr, numpages, enc); - return true; -} - void __init tdx_early_init(void) { struct tdx_module_args args = { @@ -831,30 +789,8 @@ void __init tdx_early_init(void) */ physical_mask &= cc_mask - 1; - /* - * The kernel mapping should match the TDX metadata for the page. - * load_unaligned_zeropad() can touch memory *adjacent* to that which is - * owned by the caller and can catch even _momentary_ mismatches. Bad - * things happen on mismatch: - * - * - Private mapping => Shared Page == Guest shutdown - * - Shared mapping => Private Page == Recoverable #VE - * - * guest.enc_status_change_prepare() converts the page from - * shared=>private before the mapping becomes private. - * - * guest.enc_status_change_finish() converts the page from - * private=>shared after the mapping becomes private. - * - * In both cases there is a temporary shared mapping to a private page, - * which can result in a #VE. But, there is never a private mapping to - * a shared page. - */ - x86_platform.guest.enc_status_change_prepare = tdx_enc_status_change_prepare; - x86_platform.guest.enc_status_change_finish = tdx_enc_status_change_finish; - + x86_platform.guest.enc_status_change_finish = tdx_enc_status_changed; x86_platform.guest.enc_cache_flush_required = tdx_cache_flush_required; - x86_platform.guest.enc_tlb_flush_required = tdx_tlb_flush_required; /* * TDX intercepts the RDMSR to read the X2APIC ID in the parallel diff --git a/arch/x86/hyperv/ivm.c b/arch/x86/hyperv/ivm.c index 084fab6..fbe2585 100644 --- a/arch/x86/hyperv/ivm.c +++ b/arch/x86/hyperv/ivm.c @@ -550,11 +550,6 @@ static bool hv_vtom_set_host_visibility(unsigned long kbuffer, int pagecount, bo return result; } -static bool hv_vtom_tlb_flush_required(bool private) -{ - return true; -} - static bool hv_vtom_cache_flush_required(void) { return false; @@ -614,7 +609,6 @@ void __init hv_vtom_init(void) x86_platform.hyper.is_private_mmio = hv_is_private_mmio; x86_platform.guest.enc_cache_flush_required = hv_vtom_cache_flush_required; - x86_platform.guest.enc_tlb_flush_required = hv_vtom_tlb_flush_required; x86_platform.guest.enc_status_change_finish = hv_vtom_set_host_visibility; /* Set WB as the default cache mode. */ diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c index a37ebd3..cf5179b 100644 --- a/arch/x86/kernel/x86_init.c +++ b/arch/x86/kernel/x86_init.c @@ -131,9 +131,7 @@ struct x86_cpuinit_ops x86_cpuinit = { static void default_nmi_init(void) { }; -static bool enc_status_change_prepare_noop(unsigned long vaddr, int npages, bool enc) { return true; } static bool enc_status_change_finish_noop(unsigned long vaddr, int npages, bool enc) { return true; } -static bool enc_tlb_flush_required_noop(bool enc) { return false; } static bool enc_cache_flush_required_noop(void) { return false; } static bool is_private_mmio_noop(u64 addr) {return false; } @@ -154,9 +152,7 @@ struct x86_platform_ops x86_platform __ro_after_init = { .hyper.is_private_mmio = is_private_mmio_noop, .guest = { - .enc_status_change_prepare = enc_status_change_prepare_noop, .enc_status_change_finish = enc_status_change_finish_noop, - .enc_tlb_flush_required = enc_tlb_flush_required_noop, .enc_cache_flush_required = enc_cache_flush_required_noop, }, }; diff --git a/arch/x86/mm/mem_encrypt_amd.c b/arch/x86/mm/mem_encrypt_amd.c index 6faea41..06960ba 100644 --- a/arch/x86/mm/mem_encrypt_amd.c +++ b/arch/x86/mm/mem_encrypt_amd.c @@ -278,11 +278,6 @@ static unsigned long pg_level_to_pfn(int level, pte_t *kpte, pgprot_t *ret_prot) return pfn; } -static bool amd_enc_tlb_flush_required(bool enc) -{ - return true; -} - static bool amd_enc_cache_flush_required(void) { return !cpu_feature_enabled(X86_FEATURE_SME_COHERENT); @@ -318,18 +313,6 @@ static void enc_dec_hypercall(unsigned long vaddr, unsigned long size, bool enc) #endif } -static bool amd_enc_status_change_prepare(unsigned long vaddr, int npages, bool enc) -{ - /* - * To maintain the security guarantees of SEV-SNP guests, make sure - * to invalidate the memory before encryption attribute is cleared. - */ - if (cc_platform_has(CC_ATTR_GUEST_SEV_SNP) && !enc) - snp_set_memory_shared(vaddr, npages); - - return true; -} - /* Return true unconditionally: return value doesn't matter for the SEV side */ static bool amd_enc_status_change_finish(unsigned long vaddr, int npages, bool enc) { @@ -337,8 +320,12 @@ static bool amd_enc_status_change_finish(unsigned long vaddr, int npages, bool e * After memory is mapped encrypted in the page table, validate it * so that it is consistent with the page table updates. */ - if (cc_platform_has(CC_ATTR_GUEST_SEV_SNP) && enc) - snp_set_memory_private(vaddr, npages); + if (cc_platform_has(CC_ATTR_GUEST_SEV_SNP)) { + if (enc) + snp_set_memory_private(vaddr, npages); + else + snp_set_memory_shared(vaddr, npages); + } if (!cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT)) enc_dec_hypercall(vaddr, npages << PAGE_SHIFT, enc); @@ -498,9 +485,7 @@ void __init sme_early_init(void) /* Update the protection map with memory encryption mask */ add_encrypt_protection_map(); - x86_platform.guest.enc_status_change_prepare = amd_enc_status_change_prepare; x86_platform.guest.enc_status_change_finish = amd_enc_status_change_finish; - x86_platform.guest.enc_tlb_flush_required = amd_enc_tlb_flush_required; x86_platform.guest.enc_cache_flush_required = amd_enc_cache_flush_required; /* diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c index d7ef8d3..d062e01 100644 --- a/arch/x86/mm/pat/set_memory.c +++ b/arch/x86/mm/pat/set_memory.c @@ -2147,40 +2147,57 @@ static int __set_memory_enc_pgtable(unsigned long addr, int numpages, bool enc) memset(&cpa, 0, sizeof(cpa)); cpa.vaddr = &addr; cpa.numpages = numpages; + + /* + * The caller must ensure that the memory being transitioned between + * encrypted and decrypted is not being accessed. But if + * load_unaligned_zeropad() touches the "next" page, it may generate a + * read access the caller has no control over. To ensure such accesses + * cause a normal page fault for the load_unaligned_zeropad() handler, + * mark the pages not present until the transition is complete. We + * don't want a #VE or #VC fault due to a mismatch in the memory + * encryption status, since paravisor configurations can't cleanly do + * the load_unaligned_zeropad() handling in the paravisor. + * + * There's no requirement to do so, but for efficiency we can clear + * _PAGE_PRESENT and set/clr encryption attr as a single operation. + */ cpa.mask_set = enc ? pgprot_encrypted(empty) : pgprot_decrypted(empty); - cpa.mask_clr = enc ? pgprot_decrypted(empty) : pgprot_encrypted(empty); + cpa.mask_clr = enc ? pgprot_decrypted(__pgprot(_PAGE_PRESENT)) : + pgprot_encrypted(__pgprot(_PAGE_PRESENT)); cpa.pgd = init_mm.pgd; /* Must avoid aliasing mappings in the highmem code */ kmap_flush_unused(); vm_unmap_aliases(); - /* Flush the caches as needed before changing the encryption attribute. */ - if (x86_platform.guest.enc_tlb_flush_required(enc)) - cpa_flush(&cpa, x86_platform.guest.enc_cache_flush_required()); - - /* Notify hypervisor that we are about to set/clr encryption attribute. */ - if (!x86_platform.guest.enc_status_change_prepare(addr, numpages, enc)) - return -EIO; + /* Flush the caches as needed before changing the encryption attr. */ + if (x86_platform.guest.enc_cache_flush_required()) + cpa_flush(&cpa, 1); ret = __change_page_attr_set_clr(&cpa, 1); + if (ret) + return ret; /* - * After changing the encryption attribute, we need to flush TLBs again - * in case any speculative TLB caching occurred (but no need to flush - * caches again). We could just use cpa_flush_all(), but in case TLB - * flushing gets optimized in the cpa_flush() path use the same logic - * as above. + * After clearing _PAGE_PRESENT and changing the encryption attribute, + * we need to flush TLBs to ensure no further accesses to the memory can + * be made with the old encryption attribute (but no need to flush caches + * again). We could just use cpa_flush_all(), but in case TLB flushing + * gets optimized in the cpa_flush() path use the same logic as above. */ cpa_flush(&cpa, 0); - /* Notify hypervisor that we have successfully set/clr encryption attribute. */ - if (!ret) { - if (!x86_platform.guest.enc_status_change_finish(addr, numpages, enc)) - ret = -EIO; - } + /* Notify hypervisor that we have successfully set/clr encryption attr. */ + if (!x86_platform.guest.enc_status_change_finish(addr, numpages, enc)) + return -EIO; - return ret; + /* + * Now that the hypervisor is sync'ed with the page table changes + * made here, add back _PAGE_PRESENT. set_memory_p() does not flush + * the TLB. + */ + return set_memory_p(&addr, numpages); } static int __set_memory_enc_dec(unsigned long addr, int numpages, bool enc)