Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <4d27540e-691e-bd86-0f70-1faff39f7187@amd.com>
Date:   Wed, 16 Nov 2022 14:35:35 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.2
Subject: Re: [Patch v3 05/14] x86/mm: Handle decryption/re-encryption of
 bss_decrypted consistently
Content-Language: en-US
To:     Michael Kelley <mikelley@microsoft.com>, hpa@zytor.com,
        kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
        decui@microsoft.com, luto@kernel.org, peterz@infradead.org,
        davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
        pabeni@redhat.com, lpieralisi@kernel.org, robh@kernel.org,
        kw@linux.com, bhelgaas@google.com, arnd@arndb.de,
        hch@infradead.org, m.szyprowski@samsung.com, robin.murphy@arm.com,
        brijesh.singh@amd.com, tglx@linutronix.de, mingo@redhat.com,
        bp@alien8.de, dave.hansen@linux.intel.com,
        Tianyu.Lan@microsoft.com, kirill.shutemov@linux.intel.com,
        sathyanarayanan.kuppuswamy@linux.intel.com, ak@linux.intel.com,
        isaku.yamahata@intel.com, dan.j.williams@intel.com,
        jane.chu@oracle.com, seanjc@google.com, tony.luck@intel.com,
        x86@kernel.org, linux-kernel@vger.kernel.org,
        linux-hyperv@vger.kernel.org, netdev@vger.kernel.org,
        linux-pci@vger.kernel.org, linux-arch@vger.kernel.org,
        iommu@lists.linux.dev
References: <1668624097-14884-1-git-send-email-mikelley@microsoft.com>
 <1668624097-14884-6-git-send-email-mikelley@microsoft.com>
From:   Tom Lendacky <thomas.lendacky@amd.com>
In-Reply-To: <1668624097-14884-6-git-send-email-mikelley@microsoft.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dmtFenEwbkJoYzl5dzZpeXFocEVtTU15a1VHbWJ6QmpCZWVoVW8xcmRyL0Ni?=
 =?utf-8?B?TzFLeHJkdlNwK3NqYjg3eGJRbXBMQXZOZ01tWllpTTVUdmRLRS9DdkEvM2I2?=
 =?utf-8?B?cjF2dGRuZ29TNXZUSlRINksxWXZSOTJZU0JBN1Q0R2dwcWZyV0VIdy9lWFJ5?=
 =?utf-8?B?NGhjVEJ1YzhIaUlwd0tqZ2NORTJ4UWNKMWJTeEU0MDJXdG9TREQxT29EbldZ?=
 =?utf-8?B?aVRWVjhUVHRvK3J4Z1l2QTdxbkJXUXlLZUMrK013N3lFdWs4TlVucVhMcGF5?=
 =?utf-8?B?SXFRaUhFSnRIb215NUJ6bnl6WEVnZjFreXdQN0VNQ2FBcW1nSzFPSHpONDh0?=
 =?utf-8?B?eFgwV2JBNkQ0dlRGVEcrNlRhMGxkd0UwNnQ4dkZudmdWTFhOQm9ZRy9jQUcz?=
 =?utf-8?B?UnpoT0dzaDJpUmJLMUllRTN2OG5sRGQzMUFkbitzSkF3UlNHYlVYRm1uVGNQ?=
 =?utf-8?B?TWs0Z0VVU0lkcy9vb0U1MlloMUxzTGZCVlNVdUhKWkJ0T1RoOFpna01ocFFI?=
 =?utf-8?B?Y2JlWDBURjA1OUU4eVFzaDJCY1g2Y0RONXBiOHV5Ly9ETGprcldndGNtbkNa?=
 =?utf-8?B?V2FjZVFBMkVrVlV4SFdDSUNMZUVOQkRQVXM0VE9rRkNoNTdLNk9xV3o3R3Vu?=
 =?utf-8?B?MXp1NGkvNzFENXdURnYwMExHSzhQaXdnSjBSSkN2K01QUEZXejFXZzF4RExS?=
 =?utf-8?B?Vnh2ZjdQNDV2TFhveTk5L1NsaDBWRm9qTWREOHdqSWliVll4U05mVmNlWS82?=
 =?utf-8?B?WndQVVZJeElkM216NzN6TTBTT0xQK3QrNGI1NUlOUXQ4VDl6cmZVN1lIN0lI?=
 =?utf-8?B?c25nQnBlQlUyL3hlSWYzbUZZZXpzN21ocHlOYjVYRytLclRaZEFxR21rNnhx?=
 =?utf-8?B?MnYvNjVaaWt0UkluUXZxOEFiMGJsUzVUcERBbDlneEQ4bGh4Rk1kVmhaTWw0?=
 =?utf-8?B?b2Y1d2FEZUJPY1FkU1RLY2FRV3FFVXlwekNEWml4bHR5S1dDbk02Z2o1bkN3?=
 =?utf-8?B?SUZsalI3Q0RHSlo1T1QxYmNoYWErWmQxSmFidVM3cE5pUjRheVJqeUF5aVJC?=
 =?utf-8?B?dnBHNTFCemRqejFQR0E1UGR4Qno5b3I3R3pSdkNnTk1McVRMYTY4Um94NjY1?=
 =?utf-8?B?SU5lSmluL2ZrT1o1cytYQ3pSM1pPVEJHVE94RnhFSmN4d0NBcmIrMXZIcEpq?=
 =?utf-8?B?bHdtY2Q2eGFjcUJvY09DbndJa2ZMNjRLa2c2djVMczlRdUVPZGwyQ0NrWjA5?=
 =?utf-8?B?SFhsdS9UZjZuQktKYWlFeWJFVXNxTW9BMDRIa3B0cks3dTVmWS9jb2NMTDB0?=
 =?utf-8?B?clZxci82bExObHZ1SmlHYkNsTVdEQVQ3dS9UdWdTQVA3a1VvR3kvdVBsZ0x4?=
 =?utf-8?B?OHBySk05WCtXM0QwdjgrWGZNSTFWRlZtSmpkS0Zoek1jZ0JxeXRFT0lXQXRo?=
 =?utf-8?B?WWZnS2gyVEE3eUMwR2kyM002ZDFNbXNsanRKTTdEZnJiTlFDczdtVE5XUWxS?=
 =?utf-8?B?bTJ4dWJPTmZVbVpBY3hGbm9UcGRJZm9WbWJuUlBpbHZTTlVwS2sxNzBSYU95?=
 =?utf-8?B?b0ZqcHlvKzhxbSs4K1lacEw4Nk5nS1VIcVRrK3hGNm41TEQ2d3NMc3pidjlv?=
 =?utf-8?B?K1NIS3ZGK0crUSs5Qi92eTV3MTliR29YRW0veWZDOWROejRPR25pU0M0YnpU?=
 =?utf-8?B?Z3hERWI1dkpyVEtXWVhSblRIMllqVEVTWk1WcWQxK2pmN0ZoOHNpNFVvc0E2?=
 =?utf-8?B?SEROYkhMcW5aaVBKbk8vQ2dYNTBKN1VjMlZVY1FyK2p3M3J1Y1c0WEhkMjhS?=
 =?utf-8?B?NW1iVWxVVXovL0tEMjQwWkFkNnhENHh4R1J0V1NzdjFDWnRBa05UUllKTHVm?=
 =?utf-8?B?ZlRPNFNqWlQwN2VsSEJJd1k4MkV6NFpMMk8rOHd3ZXVrUHQ4YUxIQXpoTlE5?=
 =?utf-8?B?STdod3BnRUdmOGsySjRta0JVcWhEYzdPRkJLT0htQUdGK0xhL0x6aFl6R0dD?=
 =?utf-8?B?ejdmTHc5Vm1JTnBXVXJxYWUxbDRicmR5V3pmeEdmZ1F5RGpaTFJDNEMya3JR?=
 =?utf-8?B?MjU4NVNCcUlBUXlxb0ZDVlFXQkt1Y0c3QmZmaFNya1d1SkMzd0JUNG5FNllZ?=
 =?utf-8?Q?z04A+glIuNV7FfP4ZCckbIM3Z?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7231f684-2441-445a-625e-08dac8121f58
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB5229.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Nov 2022 20:35:38.8917
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 6CxDAPkhQ5vfXkLzRoNvUwZaAwGShvbFFAkZwjdnX+x67C7glpVBmlpSNWEnf5LpgIhmvNy7PpxnjCgjWqXeQQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB4511
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS 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

On 11/16/22 12:41, Michael Kelley wrote:
> Current code in sme_postprocess_startup() decrypts the bss_decrypted
> section when sme_me_mask is non-zero.  But code in
> mem_encrypt_free_decrytped_mem() re-encrypts the unused portion based
> on CC_ATTR_MEM_ENCRYPT.  In a Hyper-V guest VM using vTOM, these
> conditions are not equivalent as sme_me_mask is always zero when
> using vTOM.  Consequently, mem_encrypt_free_decrypted_mem() attempts
> to re-encrypt memory that was never decrypted.
> 
> Fix this in mem_encrypt_free_decrypted_mem() by conditioning the
> re-encryption on the same test for non-zero sme_me_mask.  Hyper-V
> guests using vTOM don't need the bss_decrypted section to be
> decrypted, so skipping the decryption/re-encryption doesn't cause
> a problem.
> 
> Signed-off-by: Michael Kelley <mikelley@microsoft.com>
> ---
>   arch/x86/mm/mem_encrypt_amd.c | 10 +++++++---
>   1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/mm/mem_encrypt_amd.c b/arch/x86/mm/mem_encrypt_amd.c
> index 9c4d8db..5a51343 100644
> --- a/arch/x86/mm/mem_encrypt_amd.c
> +++ b/arch/x86/mm/mem_encrypt_amd.c
> @@ -513,10 +513,14 @@ void __init mem_encrypt_free_decrypted_mem(void)
>   	npages = (vaddr_end - vaddr) >> PAGE_SHIFT;
>   
>   	/*
> -	 * The unused memory range was mapped decrypted, change the encryption
> -	 * attribute from decrypted to encrypted before freeing it.
> +	 * If the unused memory range was mapped decrypted, change the encryption
> +	 * attribute from decrypted to encrypted before freeing it. Base the
> +	 * re-encryption on the same condition used for the decryption in
> +	 * sme_postprocess_startup(). Higher level abstractions, such as
> +	 * CC_ATTR_MEM_ENCRYPT, aren't necessarily equivalent in a Hyper-V VM
> +	 * using vTOM, where sme_me_mask is always zero.
>   	 */
> -	if (cc_platform_has(CC_ATTR_MEM_ENCRYPT)) {
> +	if (sme_get_me_mask()) {

To be consistent within this file, you should use sme_me_mask directly.

Thanks,
Tom

>   		r = set_memory_encrypted(vaddr, npages);
>   		if (r) {
>   			pr_warn("failed to free unused decrypted pages\n");