From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=helo; client-ip=104.47.41.84; helo=nam03-dm3-obe.outbound.protection.outlook.com; envelope-from=brijesh.singh@amd.com; receiver=edk2-devel@lists.01.org Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0084.outbound.protection.outlook.com [104.47.41.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id A466E209574F7 for ; Tue, 27 Feb 2018 04:11:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amdcloud.onmicrosoft.com; s=selector1-amd-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fBhE9/wX7Gj+vdJwvJUjNt20zC/btNphwhN+ZhyTViQ=; b=FD6mPQjXLI7GQrvxLjfWvvCeY+4+MWcYjQpkSMKjb1DwIAu5uXg1UtmiWGkv6TNiHJ05XcPRLv1S7Wd/cDmhvvRyRWcEMKE59ccYN48OXhswJcZ9iuq+H8KiqF734rRUW8Lr6dlzb+9mhqsK4Qv9IJxTNf9TbOOsenfCpKUB1ng= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=brijesh.singh@amd.com; Received: from Brijeshs-MacBook-Pro.local (70.112.153.56) by SN1PR12MB0159.namprd12.prod.outlook.com (2a01:111:e400:5144::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.15; Tue, 27 Feb 2018 12:17:56 +0000 Cc: brijesh.singh@amd.com, Tom Lendacky , Jordan Justen , Ard Biesheuvel , Paolo Bonzini , Michael Kinney To: Laszlo Ersek , edk2-devel@lists.01.org References: <20180221165212.6643-1-brijesh.singh@amd.com> <20180221165212.6643-2-brijesh.singh@amd.com> <294c83a2-bda9-392a-aceb-19f170946d57@redhat.com> From: Brijesh Singh Message-ID: <1b8d7624-7578-c6ab-71d6-f291758f872f@amd.com> Date: Tue, 27 Feb 2018 06:17:52 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <294c83a2-bda9-392a-aceb-19f170946d57@redhat.com> X-Originating-IP: [70.112.153.56] X-ClientProxiedBy: BN6PR11CA0042.namprd11.prod.outlook.com (2603:10b6:404:4b::28) To SN1PR12MB0159.namprd12.prod.outlook.com (2a01:111:e400:5144::18) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 92ebd673-0b5b-408b-7724-08d57ddc2302 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307)(7153060)(7193020); SRVR:SN1PR12MB0159; X-Microsoft-Exchange-Diagnostics: 1; SN1PR12MB0159; 3:QMVXIokhj85RCAbtG5pcwCd5/tf7pjWDTmmhoMWFXXWcuDYqNtyFtI+0S9axB2fU6uO/VijrZOLQWEaTaVzdZiWRCUqTFB/rYJg2akK1H4FZLzHuBTp3ZrO1UTBhdhnm2n/JCPLpsw4inKHlHmCZ1Ihx033hi6CRmxicu0bvnoBwEPMnM8HR6rHqnO1RP0aqOHdd2U0uF/mtdnUeYEt8sISFJs6eBrbOwV67ZjPJa4dHDXDI8M2365Txxk6fVGMB; 25:3rWPKnIwmBPo4ZtRIyh9bEJsLYVVipX8fINXHEXpfQB9Sfs8wjRf5IlPwTSeWnljhtscM7/aLgx8yddP1e7mDxqoDWNn3xwpp6OR1ZCJAU97xL/wSiIcbHeDJcy+AjftfBlYQyRL401At4G0GMfX/Zh/5c43a2ZmXkBG4TrC8sLikw1gEAbPBIQZw9QMdbfcTedqCk7x3sWSEPjFh2SHlDy2eW645IlsJGEpyJl817/ktutHnWBukK0tFazAV1px7ndq95DpA28D74h19u+SZuQlN5KxuLRzDZx2osQxeYboYbj8Fp6fBplHpvqWmb4fLkKr8P1gYsEmceQ2N4lbkEZGv5eSCc3xcmMsQXpwLsk=; 31:WanGXIgEvg798sGunZj333JZrGlkuaWAxx9nz1hdhNI/jviyqxWnS4BfH26XS6GwEe9Hkdh1EN6dUxdsieYekX3AqnN7ofNa5viro0LU3QQu2a6JqcmmroWieZ8VndK/QSksCjtvdci+dSefc/jg4mXjROXgERJnbL1Va5QlOOK+Abn6YwyBJ2Z0+c2mmlQMqPP1cZ5ff3eif+S2VJwqtN69WRnDmXjF0GVMp+qI3RE= X-MS-TrafficTypeDiagnostic: SN1PR12MB0159: X-Microsoft-Exchange-Diagnostics: 1; SN1PR12MB0159; 20:tUYJvuVKRrXABYnQkE388Qo0Y5dHgE5QVRxfmlb8VP3rctqxglKn2TP/5yPUOd2yHe1e5EEFHnHiLVlr9VS95a55JlpcJHeoSB85PPac+bKAwaNxigVDG5V+yOLTKdBJUk0FaJ4IL+JjVVjTDUx8FrhH1TsvKD2adweK0x49FUtXCQHvuVhImmZWNWSLgrRKb49g1/yfhop0bXOSdRV3cb4n/ySTnH5vBekyhH8VGH8gh6SjgP/cyPLU2HEgDGfJyb7yh0CjnaDtibSUs/ph1jz/OH8n2TkjC2WXixin6bsqVBin/u7CflkmOmZu+lZ5E0nn6KxHqhHYrXxE1lg5vt0GcAeJP1oJ+YX4KebVud+UwnwGTY6TI7/xpXS6z6sw7zuQSZ6zvFb7Aqn0C5rT+wVd79MqvCvTCyHkmtlDEeCYRiRDYo2oXcld+uCt5HesLTh3JhncAE1MjjtCm+F22hETtnR58j8RGjWpV6QiWm838ATGS/bNie9/ETj1OQLq; 4:dd7vp7FPvhYDPs62sI6MEWHV01IwwGksCpO8UlWro52jH5V+ybUivrNPZjj+/4/VobScnR7IRwJ3wcMGKH1y5vxy1ucBqkgTxeOx0fnMQLbp47B5fa+PPreS3VxWo+mt84xOFJqxYH0NLb0/IfMDBiFu+AAQ4ucrw5OR3XWgYkJmKLJNkQOKLymsnLdv6Yt/eru41psiiV5jzx/TU5Yp8KbgX1E9+Wn9T5t4b735kr8WBGexCQ/XZD+IOIjgGs65qlxVZ9Dd5gXGEbqdSPMnkkGHCVkPyA1fneKJkB6akY1qnO+fq4EbN4ReDjQl2vMiciThLWhwWygKkzF2Ec7mRa5wW4dM6gAdM3CYzomf8W0= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(767451399110)(228905959029699); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(3231220)(944501161)(52105095)(6055026)(6041288)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:SN1PR12MB0159; BCL:0; PCL:0; RULEID:; SRVR:SN1PR12MB0159; X-Forefront-PRVS: 05961EBAFC X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(346002)(376002)(366004)(39380400002)(199004)(189003)(54094003)(8936002)(186003)(16526019)(106356001)(5660300001)(6116002)(3846002)(26005)(105586002)(6246003)(31696002)(4326008)(305945005)(58126008)(54906003)(7736002)(31686004)(86362001)(68736007)(478600001)(50466002)(64126003)(65956001)(25786009)(66066001)(2906002)(47776003)(6486002)(52116002)(316002)(65806001)(81166006)(229853002)(36756003)(8676002)(6506007)(76176011)(53546011)(386003)(52146003)(53936002)(97736004)(81156014)(2870700001)(65826007)(2486003)(23676004)(6512007)(6666003)(2950100002)(59450400001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR12MB0159; H:Brijeshs-MacBook-Pro.local; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: amd.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjFQUjEyTUIwMTU5OzIzOkdsZmljemFBaWRaR2g4N3NualY4UHJDamsy?= =?utf-8?B?R0xDTHZFTkl0ZlFrelVQQkVRdExoY0YwbWgxeXdBOGV2ZHIyYSt1MnAwNk9a?= =?utf-8?B?SVdralRubEJYUlpwK0czZE5VWk9XL3I3UXkvRzVEZmdLTGRQYUpLU0NZM0Vw?= =?utf-8?B?K2pwaGtGNUUraEg2R01wY09tZEdIRkRiQjlrWEsvL1htL1E1OEhlM0JoUXVQ?= =?utf-8?B?YUZGd0liNU5Gc1BzTEZFaWVnWnBTUnpYdGtkSjdzSWVhUnVMb3RDMWZ5QTNz?= =?utf-8?B?WkFvdVVvTE1ldVFRMlExditOT2w4QzQzMGptYlh6ODkzN0NmSis4WFBSQkVB?= =?utf-8?B?Vm9KSWk5Zk5kQytta0Z1RlZRQWY3Z0o0OWM0U1hiQllFazNZVVBlcVQ3TzZk?= =?utf-8?B?YnMwMlk4QTAxazYwS1dLT3ZENVZseVd6UXM1dzVyQWdFY1VGb3p2MDJqWjBk?= =?utf-8?B?OTFadFZHQlg3MzNSUExaa1BIYlhMbHI3VkFlMytwbiswdTVqbHNRZ2hUQW5V?= =?utf-8?B?aDZHSzArdkErbFpPMXp0c0t0dkxDbnhWZWRyRkUwZXc2aE53MUkxRE9HTHdJ?= =?utf-8?B?ZWN5VkJXcitpYnU2MXliMjJjZTA0VEpqM2Z6R1Q1ZU1kZWVsamRTTHkzN1pj?= =?utf-8?B?K0UrVmU0SEp5Q3NYdkcxY1JQaFV3QWkwdTVQd2xONi9aTXVtYzF0d3FKUld5?= =?utf-8?B?RlBWSE5UNVRMVEZNS3ArVmFOZ2NBZ0VNczE4dURwZWpMSUwyNER3KzNHS01n?= =?utf-8?B?SFVSL0RFUFFhZ3I0TE4vNFBveVlEeEtvYURta1B0akVjMDl1OVJWblNMbzBU?= =?utf-8?B?Z1IvRExZOFhNcDB4U1B0MUZlTXM4c0QvSkQrZmNsWlV0eWdzSGZGakVDQmdm?= =?utf-8?B?ckp5bEtWVEZyRTRoaC9OZm96L2VXNDJhUWkxY0dMUGVRY1I4Vlh6bndYYmsv?= =?utf-8?B?QTVPMUtML1B1ZVJUYXhBN3BrUUJiL0FBTk1xajgrc3A4TTh4ME9LZ0hoRitU?= =?utf-8?B?YXEwK2JqczBVcHplMmJGRXF2ZUFqenJGaXFxOXVqTmowN2ZzSUdWTlBQaC96?= =?utf-8?B?Mzh4VlhsRFdtUHFUR3gvTzdxTzRnNzlzM2dSZWttS1VZMFJOdTd6T01YaWNq?= =?utf-8?B?VTR2VVUzOGdKa2h1M1V0V0REN2dJbkxyNThGaUcvUTVEZTdzNWJNQ3lsTVRH?= =?utf-8?B?MGwrRjBzYmc5dWNYMDVEVEhuWHNBMGhHM1N6RC9rb25SS3MzVnhDNDQvbGRu?= =?utf-8?B?bXpNYXYvT2pqUHZYUTV0SHJFNG5vajZrQlpHbVlUVG5aNUlvZHgyd0N2aEtS?= =?utf-8?B?S285UDhiM2FlYVpMS0NCayt4ZmxaRU5MUWRQM1N0WUs5TURvWHhQTnlrdlpw?= =?utf-8?B?NmUrRlN3TlR5ckd3Y094bmhPZE9KQm5zVDRwVGN1ZStFTFhBQW53RTdvaXZr?= =?utf-8?B?Z3JBSU5qUFhmbzlwOXZJTlphZjZyZGNub2tqVGk0MG5IZWZKQzdMa0tQNWRm?= =?utf-8?B?ZHA4aGc3Q1JNWUlXRHBVZStiek1KMXRwQ3hMbm5EWEliZkRETTh5R0lod2Rt?= =?utf-8?B?WnE5SCtXa3dYVEhmZkloNnh4WjJxZ29uRE5aeWUrUmZONVg4YjZ3c1NxUTNJ?= =?utf-8?B?alNrYlEwaXhIRVVTZU9Pd2dsNW0yT3hsZUN2bVBCWTdCVms4Z1ZKcmJrdU01?= =?utf-8?B?OU4ycG5UNVNPVkVFMllTQ09zYTlkV2Y2WDFJV3lJdGxaMFZGNUFuQXFwdUox?= =?utf-8?B?bkxkV0lkb2UyRzd5WUR2bFlwZnJ5ZXg0TnZpVmw1YXdRRmtWTFhYUk1CaUtQ?= =?utf-8?B?T2N4ajNwS1hzaENkTmM2cC9VR0NURHRxQmg1ZEp0NmwxbHhXcmtROXdUT2xP?= =?utf-8?Q?UuwlnG1eSms=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR12MB0159; 6:yWWdyjdjS4EO6c+zZRf38KUnkwaCJnr5Uq8/K/CLS/nLxz0yhJOSlZHf6eEtlWr16iz4mquSUb/E4Ur6W/xPhAMPkrCJXYY008Zq0J1N7Su69bdeQgNwRGqxqzJsfQO5snBHGqik6WqoAgpPrwmKxjQ5ijUgJ2kDQBKv9PoO5Caf5JhIo2EkmWPknPu9NwnhRTdfpavxYtBjLyz7q6gnXTO4kCJqB4MqKhWOLXzS1Nd7koKf/k8Q+p1qkScU+ZDy9jhYemEl4QFuG2yHTEJIYWLmDJZSfwR43EsZ2ha8neEWIS3SPHvSOtNewuG0sBu1CyN57j3PNX6bPz610MgkrG8jZCjLRhCXbro+jH+R2n0=; 5:7RHOiaxDuiO1QR9aQgvTdyy/IlrxlSopyQflLI8dBMmP5q+8ep4SjQNg+gIVi3MGZn0jRAdKA+kh7NWlJ4Xw87exfubN1hroCzeZKVDs5CpArpOJLZPMSoRWLe77ddcRhdxVy9kYX7UoYsyCMy9pJZeVPYt4EDrGIlNc5Yn7g6A=; 24:wvbS+ov/0XXXgM3UZhpYG6DszLpawKhbqc3CQaLbxkRxO8Jsl2SKleIZpDfUH2h0IuI6/27kmN/K99iWzZq80yBCdr6khv1kj/m+hn6YXFQ=; 7:kXxssbfwixW9MyT/1sz/EJeXi1sLvcIAQPtXVpM35efa3u6BcR3lzkVqb3Lrdz52kZTtsSYDN+3pQkUSuPW+cQk/N3IQfhTi9ENc3BRRmR9nfAfPEmtSSnV+ShfqAYd3FCv3kStP0MsqYutX6Zjt78vcA9YCKXRzF7sLHBn/4rUtXJWUMirMW2OHfrN9BcaZ/1pZfSAS8sJYhJaiTB6MpHtOa8+1grZ0ucJrU3RKppBH1H1ixJ2tGx45ZFZZGF5+ SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN1PR12MB0159; 20:kQAeGZgfNdXBMRlyna7ajtQxpHZ2Dt3CGKZJo/V71gv9DkwoixhMRxkS+omNMiGF69wqkE3EOJktjrSrv4zqfhJD4f/uYkHQQiFLICx95q1fJsi1iXIgoHOkXle7g8wMV9Ax0NPVHHAjsRRSzMVWmw+VCCCV9CUjNgC+pJT7hN2rZoB8HVpQmAC7iHB9BKadNICEW4ErKYDbJz9Z8iRgergVCIo89J6PPw78kvyDN2/12AienOXE3WFGetvrrkDn X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Feb 2018 12:17:56.7059 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 92ebd673-0b5b-408b-7724-08d57ddc2302 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR12MB0159 Subject: Re: [PATCH 1/2] OvmfPkg/AmdSevDxe: Clear the C-bit from SMM Saved State X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 12:11:57 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Hi Laszlo, Apologies for late response. I needed to do some investigation on SMM before responding to you. On 2/22/18 5:20 AM, Laszlo Ersek wrote: > Hi Brijesh! > > (adding Paolo and Mike; more comments below) > > On 02/21/18 17:52, Brijesh Singh wrote: >> When OVMF is built with SMM, SMMSaved State area (SMM_DEFAULT_SMBASE + >> SMRAM_SAVE_STATE_MAP_OFFSET) contains data which need to be accessed by >> both guest and hypervisor. Since the data need to be accessed by both >> hence we must map the SMMSaved State area as unencrypted (i.e C-bit >> cleared). >> >> Cc: Jordan Justen >> Cc: Laszlo Ersek >> Cc: Ard Biesheuvel >> Contributed-under: TianoCore Contribution Agreement 1.1 >> Signed-off-by: Brijesh Singh >> --- >> OvmfPkg/AmdSevDxe/AmdSevDxe.inf | 4 ++++ >> OvmfPkg/AmdSevDxe/AmdSevDxe.c | 19 +++++++++++++++++++ >> 2 files changed, 23 insertions(+) >> >> diff --git a/OvmfPkg/AmdSevDxe/AmdSevDxe.inf b/OvmfPkg/AmdSevDxe/AmdSevDxe.inf >> index 41635a57a454..162ed98a2fbe 100644 >> --- a/OvmfPkg/AmdSevDxe/AmdSevDxe.inf >> +++ b/OvmfPkg/AmdSevDxe/AmdSevDxe.inf >> @@ -29,6 +29,7 @@ [Packages] >> MdePkg/MdePkg.dec >> MdeModulePkg/MdeModulePkg.dec >> OvmfPkg/OvmfPkg.dec >> + UefiCpuPkg/UefiCpuPkg.dec >> >> [LibraryClasses] >> BaseLib >> @@ -41,3 +42,6 @@ [LibraryClasses] >> >> [Depex] >> TRUE >> + >> +[FeaturePcd] >> + gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire >> diff --git a/OvmfPkg/AmdSevDxe/AmdSevDxe.c b/OvmfPkg/AmdSevDxe/AmdSevDxe.c >> index e472096320ea..5ec727456526 100644 >> --- a/OvmfPkg/AmdSevDxe/AmdSevDxe.c >> +++ b/OvmfPkg/AmdSevDxe/AmdSevDxe.c >> @@ -25,6 +25,8 @@ >> #include >> #include >> #include >> +#include >> +#include >> >> EFI_STATUS >> EFIAPI >> @@ -71,5 +73,22 @@ AmdSevDxeEntryPoint ( >> FreePool (AllDescMap); >> } >> >> + // >> + // When SMM is enabled, clear the C-bit from SMM Saved State Area >> + // >> + if (FeaturePcdGet (PcdSmmSmramRequire)) { >> + EFI_PHYSICAL_ADDRESS SmmSavedStateAreaAddress; >> + >> + SmmSavedStateAreaAddress = SMM_DEFAULT_SMBASE + SMRAM_SAVE_STATE_MAP_OFFSET; >> + >> + Status = MemEncryptSevClearPageEncMask ( >> + 0, >> + SmmSavedStateAreaAddress, >> + EFI_SIZE_TO_PAGES (sizeof(QEMU_SMRAM_SAVE_STATE_MAP)), >> + FALSE >> + ); >> + ASSERT_EFI_ERROR (Status); >> + } >> + >> return EFI_SUCCESS; >> } >> > First, this SMBASE address is only correct before SMBASE relocation. > > - What guarantees that AmdSevDxe is dispatched, and the new code is > executed, before PiSmmCpuDxeSmm performs the SMBASE relocation? > > - Where/when do we clear encryption for the state map that is used after > SMBASE relocation? If we don't do that at all, then why do things > work? (I see a whole lot of "mAddressEncMask" in PiSmmCpuDxeSmm; some > help would be appreciated.) mAddressEncMask in PiSmmCpuDxeSmm basically ensure that newly created pagetables have the C-bit set for all the pages -- its very similar to what we do when creating non SMM page table. By default we consider all the pages encrypted, if we do not apply the mAddressEncMask to newly created page then we will fail to execute the code because SEV hw needs code to be encrypted. Currently we do not clear the C-bit of relocated SMBASE saved state area. After you asked this question, I did a bit investigation to see how I am booting the SMM enabled SEV guest without clearing the C-bit of relocated SMBASE saved area. The SMBASE is mapped with C=1 in guest, before entering in SMM mode HV saves some values in SMMSaved area -- this is done using HV key, guest BIOS never reads or writes to SMMSaved area hence we are getting lucky. If guest BIOS ever writes or read the value from relocated SMMSaved area then it will get garbage. We should consider clearing the relocated SMMSavedArea but there are two questions: 1) Where/When we should clear the C-bit of relocated SMMSavedArea ? I was looking at multiple function provided by SmmFeatureLib but could not find a right place for it. Most of time the SMMfeatureLib functions are called in non-SMM context and we do not have access to SMM pagetable to clear the C-bit of SMMSavedArea. How about if we introduce a new function in SmmfeatureLib which gets called just after core creates a new SMM page table ? 2) The C-bit works on page-aligned boundary but SmmSaveArea offset does not start with page-aligned boundary. We could still go ahead and clear the full page -- we may leak some information to HV in that case. But the real issue is looking carefully I see that some portion of page may contain code and hence clearing the full page will cause a runtime issues whenever that code gets executed. (I hacked EDKII to do this and could see that if full page is cleared then sometime later we get crash because someone was trying to execute a code which was mapped with C=0). One option which I was thinking is: since access to relocated SMMSavedState is controlled via SmmFeatureLib hence we could simply map the page with C=0 as we enter in the function  and restore the C-bit on exit. This will ensure that any access happening to SmmSavedArea is done with C=0. I have also tried this and it seems to work fine.  I was not able to find any code in EDKII which trigger a code path which requires access to SmmSavedArea hence I hacked something to test the flow. I think this is clean approach and does not require any changes in EDKII core and should work just fine. > Second, after SMBASE relocation, when/where do we restore the C bit on > the original (default) SMBASE? I think we should do that, otherwise > we'll have an info leak there. Good point, I will see where we can restore the C-bit of original SMBASE. > > Third, why is it OK to pass Flush=FALSE? The documentation says, "mostly > TRUE except MMIO addresses". The default SMBASE points into memory, not > MMIO; there could be normal data there. PiSmmCpuDxeSmm backs up the area > before SMBASE relocation, and restores it after. See SmmRelocateBases() > in "UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c": Very good point,  the flush should be TRUE. I think its my copy/paste. > // > // Backup original contents at address 0x38000 > // > CopyMem (BakBuf, U8Ptr, sizeof (BakBuf)); > CopyMem (&BakBuf2, CpuStatePtr, sizeof (BakBuf2)); > > I wonder if we should introduce new SmmCpuFeaturesLib APIs, for managing > memory encryption settings around SMBASE relocation. See my above response, If you think its acceptable approach then I don't see us needing any changes in SmmFeatureLib. > - PiSmmCpuDxeSemm could call these APIs in "strategic places". > - The SmmCpuFeaturesLib instances in UefiCpuPkg and QuarkSocPkg would do > nothing. > - The instace under OvmfPkg would handle the C-bit, dependent on SEV > presence. > > The lib class already has a function called > SmmCpuFeaturesSmmRelocationComplete(); we might be able to use that (too). > > Thanks, > Laszlo