From patchwork Tue Oct 17 20:24:55 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Rick Edgecombe X-Patchwork-Id: 13426020 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7772CCDB484 for ; Tue, 17 Oct 2023 20:25:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ACE178D006B; Tue, 17 Oct 2023 16:25:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A7E678D0064; Tue, 17 Oct 2023 16:25:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 945B18D006B; Tue, 17 Oct 2023 16:25:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 8072E8D0064 for ; Tue, 17 Oct 2023 16:25:32 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 555A8A0EA2 for ; Tue, 17 Oct 2023 20:25:32 +0000 (UTC) X-FDA: 81356083704.22.5ED920D Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.7]) by imf21.hostedemail.com (Postfix) with ESMTP id C92011C0018 for ; Tue, 17 Oct 2023 20:25:29 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=SG17PdzW; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf21.hostedemail.com: domain of rick.p.edgecombe@intel.com designates 192.198.163.7 as permitted sender) smtp.mailfrom=rick.p.edgecombe@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1697574330; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=Hb6xSa6mNhhw9qg1g+HsKvIKQijGGjtZ/OEIaLWSZ+s=; b=Y0e3t5CJQ1RoYvuWK0+kJj4LjFJ2wH2eFJpEYJO1d7WQHULfcRoxVuwrZl4aG+RNsuI2Di nxKcuPqFUQwtUraf1ExV9h+d6wUrSlIqb6BBW8A+4wy5FZmsSoHKgqICuUAtQ6mUg0fztV qBar89OMenQ2xc5j/qvjanGGQz2pCq0= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=SG17PdzW; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf21.hostedemail.com: domain of rick.p.edgecombe@intel.com designates 192.198.163.7 as permitted sender) smtp.mailfrom=rick.p.edgecombe@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697574330; a=rsa-sha256; cv=none; b=ViLeC4q9CMnXXVbEhB+VROk9gQC83HTCeL5+eSq06feVc8/zAzLR4swaSdzF8etReDstTR WR7fE5O0sn9Ux9MPFyDBHHm5JgKTJpMCb8prd4669B8qUlaHHTVbacx3SrHWUazt3jb7WK c44qEOwPvRJ89Mz9QLrZTQs6jlbpGCk= 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:mime-version: content-transfer-encoding; bh=GidCfHFt8RPhycoP1wfXlb89hDpzBE5Ubdb1ihTFzYc=; b=SG17PdzWdqLaXibCixMFH0JML2ff08ZSVC0OiFBX9GGfN0cpZubqcZUp iCZJM4qISORIgVvn4uWxaNTi1dAa/bCPcNtmkIiMA0JQ1h3163uNUqW1/ qpUGTcg0sJUW/KkJLV74Zm/y4lnjn9VAN0CF+GtOGSS/phGopycZaEL6K snq/4fdTyR9dNZfNguAtUnrRnTcgnarTGFgYs2qHVB8dIkwxYMX/uMSp7 ZlB01CDC7702pGxEOpyGEOz0k028Or9/CFvWpA4kOP/1Ne6lHxd+KznNN xLlhjtyOjcIu0Wjl0xQZo/FZIN0vPidxUFreokS4qdyAmvqB/qhUTvpMc A==; X-IronPort-AV: E=McAfee;i="6600,9927,10866"; a="7429473" X-IronPort-AV: E=Sophos;i="6.03,233,1694761200"; d="scan'208";a="7429473" 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:28 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10866"; a="900040430" X-IronPort-AV: E=Sophos;i="6.03,233,1694761200"; d="scan'208";a="900040430" 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:24 -0700 From: Rick Edgecombe 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 , 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 Subject: [PATCH 00/10] Handle set_memory_XXcrypted() errors Date: Tue, 17 Oct 2023 13:24:55 -0700 Message-Id: <20231017202505.340906-1-rick.p.edgecombe@intel.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: C92011C0018 X-Stat-Signature: m3csr5hzk386ew596emefue8tg7usxbo X-HE-Tag: 1697574329-666189 X-HE-Meta: U2FsdGVkX18VxiR3e1whE0hWs/PwVgRF8KI2jA5gST4euzOYeYCT2iW6wztol6bvFLJdqxdVpnC4+tEiNRv7rmq9JQPbpYyeVUddSb1yY5/Sjy9rHOw/Hfeg15DBmoQ+dlfELdc73+Y7he0G32sBz57SU6l23Dz3NnCiHVi2cnud9cvN/SJRqmu85i77JVJk/d4kRgMY5QQ94hgBlJsALP1Nd1GrGhRoGDICZJxGYw56T7Vy+Gb/UR4KXSNVRYjm4Hx+4OxRuERLNg2QmywxRbnm5ylnSTyocr+Pmzs7teyJaLYuqA/s9BKp9F+R4LCT12ybJ2oqq1ynI78N315PKWRnDw+JMm/N+lV2ZEq638dE0GdNRsDGEK8Xfob24xArabld/Bfa4hJDDUZP/wZJIyxpSWXlRMYdk9gFH82HLz+7g3/FZ+PZA2j9U3ZkD2CDHb1UXzSUGa7YhmJSHEJ9GoVSaaq7x+QAHtxGDAmqLhe/AM1TGgwklCwbyF0V0qmEwM5p17zpz+VvkKPF4JA5U/tMUuL0+tRAa+Sp2dN8O7x1z/YdC8dOgPXobHQs/2i6oSS3N1g3A53gsDM/UePKnFiS1NeWX5ZA4l5+IG/ZlrKrwK+wGd0XNc6LchCa2S3+m0ayTT9QYV+j91u7pkuRmwMvTS4RM+q16GyYBFPpjmgD2IFmKvNAW3TZFLW2CF0otT8xp308yXDnled576OvW+nNSKNw5mhWSLcPatJVvlVpSHofrOH0oN0ZOsbREc2TEoislesGg3kbhCp52mGhAtJ6KuOtKi3b9x6vMj0mmOSYXm+8/0ILwxleM7XVUCwg3YslIzAoGSPh7G5yJtv1nExvWD4ObwuRNhajnpIWi7Vc+Rw7OBCAvOndCX1SvPTAXPUf+wsw4CrVYvfjF1MIXxQtITJqa8Vm4AY+gqyndUx/tAOwcYYguaGV328n7B7Vo5186mce7hK7Pfgts4g Laf/ZLVf Xo9jMfey5GYrX8VUlgkmvWcgw+9FmBTimiO6ej5x8KMRsB0sEjycuglmBueYCkFfspp2yqG2sZiDbLrtAoLCrK6qwTT+7fgqfKTW7A6k7OlRJjUkxGhrynYwp8l0OtiaWQzFG3JfsFd4ZTubnAgVP1s32T6Zhmy9duHUNCi7LecRhAZlz+Sh2dajX0dGBU6RFnTSI X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Shared pages should never return to the page allocator, or future usage of the pages may allow for the contents to be exposed to the host. They may also 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). Normally set_memory() call failures are rare. But on TDX set_memory_XXcrypted() involves calls to the untrusted VMM, and an attacker could fail these calls such that: 1. set_memory_encrypted() returns an error and leaves the pages fully shared. 2. set_memory_decrypted() returns an error, but the pages are actually full converted to shared. This means that patterns like the below can cause problems: void *addr = alloc(); int fail = set_memory_decrypted(addr, 1); if (fail) free_pages(addr, 0); And: void *addr = alloc(); int fail = set_memory_decrypted(addr, 1); if (fail) { set_memory_encrypted(addr, 1); free_pages(addr, 0); } Unfortunately these patterns are all over the place. And what the set_memory() callers should do in this situation is not clear either. They shouldn’t use them as shared because something clearly went wrong, but they also need to fully reset the pages to private to free them. But, the kernel needs the VMMs help to do this and the VMM is already being uncooperative around the needed operations. So this isn't guaranteed to succeed and the caller is kind of stuck with unusable pages. Looking at QEMU/KVM as an example, these VMM converstion failures either indicates an attempt to attack the guest, or resource constraints on the host. Preventing a DOS attack is out of scope for the coco threat model. So this leaves the host resource constraint cause. When similar resource constraints are encountered in the host, KVM punts the problem to userspace and QEMU terminates the guest. When similar problems are detected inside set_memory(), SEV issues a command to terminate the guest. This all makes it appealing to simply panic (via tdx_panic() call which informs the host what is happening) when observing troublesome VMM behavior around the memory conversion. It is: - Consistent with similar behavior on SEV side. - Generally more consistent with how host resource constraints are handled (at least in QEMU/KVM) - Would be a more foolproof defense against the attack scenario. Never-the-less, doing so would be an instance of the “crash the kernel for security reasons” pattern. This is a big reason, and crashing is not fully needed because the unusable pages could just be leaked (as they already are in some cases). So instead, this series does a tree-wide search and fixes the callers to handle the error by leaking the pages. Going forward callers will need to handle the set_memory() errors correctly in order to not reintroduce the issue. I think there are some points for both sides, and we had some internal discussion on the right way to handle it. So I've tried to characterize both arguments. I'm interested to hear opinions on which is the best. I’ve marked the hyperv guest parts in this as RFC, both because I can’t test them and I believe Linux TDs can’t run on hyperv yet due to some missing support. I would appreciate a correction on this if it’s wrong. Rick Edgecombe (10): mm: Add helper for freeing decrypted memory x86/mm/cpa: Reject incorrect encryption change requests kvmclock: Use free_decrypted_pages() swiotlb: Use free_decrypted_pages() ptp: Use free_decrypted_pages() dma: Use free_decrypted_pages() hv: Use free_decrypted_pages() hv: Track decrypted status in vmbus_gpadl hv_nstvsc: Don't free decrypted memory uio_hv_generic: Don't free decrypted memory arch/s390/include/asm/set_memory.h | 1 + arch/x86/kernel/kvmclock.c | 2 +- arch/x86/mm/pat/set_memory.c | 41 +++++++++++++++++++++++++++++- drivers/hv/channel.c | 18 ++++++++----- drivers/hv/connection.c | 13 +++++++--- drivers/net/hyperv/netvsc.c | 7 +++-- drivers/ptp/ptp_kvm_x86.c | 2 +- drivers/uio/uio_hv_generic.c | 12 ++++++--- include/linux/dma-map-ops.h | 3 ++- include/linux/hyperv.h | 1 + include/linux/set_memory.h | 13 ++++++++++ kernel/dma/contiguous.c | 2 +- kernel/dma/swiotlb.c | 11 +++++--- 13 files changed, 101 insertions(+), 25 deletions(-)