Message ID | 20231017202505.340906-2-rick.p.edgecombe@intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp4381081vqb; Tue, 17 Oct 2023 13:26:31 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGm24CRXvVCdQm+JFZ0D1IogIb8+n6DZO+vux7zY0nQsi0LMU4a0GpVBmGFG8CG+zyQJuHE X-Received: by 2002:a05:6a00:428e:b0:692:b3d4:e6c3 with SMTP id bx14-20020a056a00428e00b00692b3d4e6c3mr3462903pfb.0.1697574391508; Tue, 17 Oct 2023 13:26:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697574391; cv=none; d=google.com; s=arc-20160816; b=vULw5q64dWzd8gakOBI8XxlKXs3xFxktxgMwEEYcMZk0jcyEeTJtyi12+VsmQ9N2OP wmG58I8lL3v1LxKTOmsrO80dgRQizmuIu2+8Ft4B/Mw+OiTOd2k94Tf5Is8krWKw6s4T 2K729tqQPFS/6UGBnUBaEZzto9TbOUSLasIhqdMkTCiwz1z+EK47sKkc4QY28BW1O+em EJqyHiMjwC0+GUVWmZxghW4tXLKpYv6bW52oT26+TBenzBEZoVMu2Ofh3mEchfI3vT1u NJHl4x50eS3/rPgqHabzC3MjblF08R+uHSGzblKFIyVZZLVxuLVlNjiivo6ktceyQ/5d SqBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=bHJdVxLWL7tmOR6rkkqndFqpRDxEeh3UF9/QOQa3Rd0=; fh=VcY0H07N31qXwTiA/WYKk4sD4rXfVVpVq9f5fZi5Co8=; b=WpXAffhyAwuY0fdVzaFB+ks6jpjR8E++zp7a5E98VnVslLp8Rczwy9CUcZH3grLDsR uTyR8W1BTk3myma2PH2GjU7I7Jacfy7UdefHwShQXQSeyHtE7GDJPAi17Gmrj/nWZ5JP IX21dKoLNbEEzA2esaApMafhVd3ka23FmyrHo/0t45O9xkYUCnpeBjt6L87qP/hMML5T eh6lJ1QmEOFMzV2hvHP8F7GFjfFd+t9+Cy3nKOwfbPpQd8PvWCSDk99LNBHZo0/jhth3 krr64CCHzgVk0b0iVL1PKadD1p/FiyKKLo5ozisIXskmGnbBMDbWiLGbTNb1HAfkNa/B NlHA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=YOaXpWmq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from lipwig.vger.email (lipwig.vger.email. [23.128.96.33]) by mx.google.com with ESMTPS id z6-20020aa78886000000b00690ba709d02si2465247pfe.381.2023.10.17.13.26.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 13:26:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=YOaXpWmq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id DCB19807D98A; Tue, 17 Oct 2023 13:25:43 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344259AbjJQUZd (ORCPT <rfc822;dexuan.linux@gmail.com> + 21 others); Tue, 17 Oct 2023 16:25:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40920 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234726AbjJQUZb (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 17 Oct 2023 16:25:31 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.7]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A59989F; Tue, 17 Oct 2023 13:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697574330; x=1729110330; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=+c/mkJRcRl/HTZD+PEVBiG6EmvprrHB2jpk4jFyydb0=; b=YOaXpWmqlBQ/fBIZtCORTY+HA8/+90LrE3kyDLgvDrwexUZho+rd1h2P wiDFd/Idu9HUrcVy8Wg2/YZJj9vDqzJ9eRxpzonDM7emQKFbWhadXIMjJ ct8tPeDXtb6AiSlLpxK6aWwKxLeavr6Sc2fpLfKmCFoENW1SpBMg4fHJI eYNWooVl9cXbWr6XlxCEXNL/ihUF0DToa0+qHUjaklJ+cuHv2drrouFL6 P9G1HH7gHvoKTv9fjBtMVc4OAJ6snuj2m//1pmhqjaWtNh+o8BsNXKjik 7aV8L3B0Ncx0PT62eW8Wrb3IMwx5kOWgU9e7pL4e1MdF0o87IjIWs6LTS w==; X-IronPort-AV: E=McAfee;i="6600,9927,10866"; a="7429487" X-IronPort-AV: E=Sophos;i="6.03,233,1694761200"; d="scan'208";a="7429487" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmvoesa101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 13:25:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10866"; a="900040434" X-IronPort-AV: E=Sophos;i="6.03,233,1694761200"; d="scan'208";a="900040434" Received: from rtdinh-mobl1.amr.corp.intel.com (HELO rpedgeco-desk4.intel.com) ([10.212.150.155]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 13:23:25 -0700 From: Rick Edgecombe <rick.p.edgecombe@intel.com> To: x86@kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, luto@kernel.org, peterz@infradead.org, kirill.shutemov@linux.intel.com, elena.reshetova@intel.com, isaku.yamahata@intel.com, seanjc@google.com, Michael Kelley <mikelley@microsoft.com>, thomas.lendacky@amd.com, decui@microsoft.com, sathyanarayanan.kuppuswamy@linux.intel.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org Cc: rick.p.edgecombe@intel.com, Heiko Carstens <hca@linux.ibm.com>, Vasily Gorbik <gor@linux.ibm.com>, Alexander Gordeev <agordeev@linux.ibm.com>, Christian Borntraeger <borntraeger@linux.ibm.com>, Sven Schnelle <svens@linux.ibm.com>, Dave Hansen <dave.hansen@intel.com> Subject: [PATCH 01/10] mm: Add helper for freeing decrypted memory Date: Tue, 17 Oct 2023 13:24:56 -0700 Message-Id: <20231017202505.340906-2-rick.p.edgecombe@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20231017202505.340906-1-rick.p.edgecombe@intel.com> References: <20231017202505.340906-1-rick.p.edgecombe@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Tue, 17 Oct 2023 13:25:43 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1780035765399103552 X-GMAIL-MSGID: 1780035765399103552 |
Series |
Handle set_memory_XXcrypted() errors
|
|
Commit Message
Edgecombe, Rick P
Oct. 17, 2023, 8:24 p.m. UTC
When freeing decrypted memory to the page allocator the memory needs to be
manually re-encrypted beforehand. If this step is skipped, then the next
user of those pages will have the contents inadvertently exposed to
the guest, or cause the guest to crash if the page is used in way
disallowed by HW (i.e. for executable code or as a page table).
Unfortunately, there are many instance of patterns like:
set_memory_encrypted(pages);
free_pages(pages);
...or...
if (set_memory_decrypted(addr, 1))
free_pages(pages);
This is a problem because set_memory_encrypted() and
set_memory_decrypted() can be failed by the untrusted host in such a way
that an error is returned and the resulting memory is shared.
To aid in a tree-wide cleanup of these callers, add a
free_decrypted_pages() function that will first try to encrypt the pages
before returning them. If it is not successful, have it leak the pages and
warn about this. This is preferable to returning shared pages to allocator
or panicking.
In some cases the code path's for freeing decrypted memory handle both
encrypted and decrypted pages. In this case, rely on set_memory() to
handle being asked to convert memory to the state it is already in.
Going forward, rely on cross-arch callers to find and use
free_decrypted_pages() instead of resorting to more heavy handed solutions
like terminating the guest when nasty VMM behavior is observed.
To make s390's arch set_memory_XXcrypted() definitions available in
linux/set_memory.h, add include for s390's asm version of set_memory.h.
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Christian Borntraeger <borntraeger@linux.ibm.com>
Cc: Sven Schnelle <svens@linux.ibm.com>
Cc: linux-s390@vger.kernel.org
Suggested-by: Dave Hansen <dave.hansen@intel.com>
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
---
arch/s390/include/asm/set_memory.h | 1 +
include/linux/set_memory.h | 13 +++++++++++++
2 files changed, 14 insertions(+)
diff --git a/arch/s390/include/asm/set_memory.h b/arch/s390/include/asm/set_memory.h index 06fbabe2f66c..09d36ebd64b5 100644 --- a/arch/s390/include/asm/set_memory.h +++ b/arch/s390/include/asm/set_memory.h @@ -3,6 +3,7 @@ #define _ASMS390_SET_MEMORY_H #include <linux/mutex.h> +#include <linux/mem_encrypt.h> extern struct mutex cpa_mutex; diff --git a/include/linux/set_memory.h b/include/linux/set_memory.h index 95ac8398ee72..a898b14b6b1f 100644 --- a/include/linux/set_memory.h +++ b/include/linux/set_memory.h @@ -5,6 +5,8 @@ #ifndef _LINUX_SET_MEMORY_H_ #define _LINUX_SET_MEMORY_H_ +#include <linux/gfp.h> + #ifdef CONFIG_ARCH_HAS_SET_MEMORY #include <asm/set_memory.h> #else @@ -78,4 +80,15 @@ static inline int set_memory_decrypted(unsigned long addr, int numpages) } #endif /* CONFIG_ARCH_HAS_MEM_ENCRYPT */ +static inline void free_decrypted_pages(unsigned long addr, int order) +{ + int ret = set_memory_encrypted(addr, 1 << order); + + if (ret) { + WARN_ONCE(1, "Failed to re-encrypt memory before freeing, leaking pages!\n"); + return; + } + free_pages(addr, order); +} + #endif /* _LINUX_SET_MEMORY_H_ */