From mboxrd@z Thu Jan 1 00:00:00 1970 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 C15B2C52CDA for ; Fri, 26 Jul 2024 16:45:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 05CDE6B0089; Fri, 26 Jul 2024 12:45:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 00BC76B0093; Fri, 26 Jul 2024 12:45:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E3D406B0095; Fri, 26 Jul 2024 12:45:20 -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 C5EE06B0092 for ; Fri, 26 Jul 2024 12:45:20 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 72301A3D0F for ; Fri, 26 Jul 2024 16:45:20 +0000 (UTC) X-FDA: 82382479200.27.9E6EF2D Received: from mail-ej1-f41.google.com (mail-ej1-f41.google.com [209.85.218.41]) by imf03.hostedemail.com (Postfix) with ESMTP id 98EB42002A for ; Fri, 26 Jul 2024 16:45:18 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=kUBtrTPv; spf=pass (imf03.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.41 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722012279; 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:in-reply-to:references:references:dkim-signature; bh=XJLgZuR3KviFafgvQJVTyFT3i3vA9AL6Ik6JXASwW1o=; b=BmlaZnv089aPliuyX9KWFulGACiAVnqLWr95xHhDNJpICWloS1/qxsZcmlChfTN82IbAud HDTSjJFuOzuq2Z3/gZ7Cj7+MhMEUU2hqIU7+zFnPmYfVR0z+KI9rowjF1eYnJyyJdK1b35 YeaXAFU4dnNiAWU0aZqGtGiPPH3rG5I= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=kUBtrTPv; spf=pass (imf03.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.41 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722012279; a=rsa-sha256; cv=none; b=UFvL0zdNVLLLO92Lo4P9ZFYPRO88TN7mzyuwBefD+Ic+WYA8HxlJ3DDjx4ARh63HahO+q/ BRga5YpxULXvqg628jOntWWXlt7ulOyR+T7KRqnnfFO9XufwvvIpxiDHe12FfTgmlhL0tA xOjPsY5svzIqmraAFaCEts0teZsA9z0= Received: by mail-ej1-f41.google.com with SMTP id a640c23a62f3a-a7aada2358fso323913966b.0 for ; Fri, 26 Jul 2024 09:45:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1722012317; x=1722617117; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=XJLgZuR3KviFafgvQJVTyFT3i3vA9AL6Ik6JXASwW1o=; b=kUBtrTPv2h2DglhPhQW0lqlsczBq6/Nsj90MKl+Yd0dt99myqtvTG/knaZnRZS9Z8f CI3aI0jZ4+7+Qjml8ygaY/+hhYrzDzoNKoBABHWyrvU5Qo8NusImazlDYWhNWEwbTxut HYomdnDUpV9KFio+Nzy6q858lTFhRrVa6tlL85Hbs6oMGuxkN9qct5xglh9kUcoQN3xZ TORr1Bv6B0sjOPBUdeiu6gZmiB4pcqaC5KTsvWKEybIKrgQsuTcE9J6WMxTrSaEPVlv/ uvBL4r1pB3WVzEYUt3+E/BQaZggRfLiUR/BeswEtTTwRbJed2Fz6LPVI/4dKeWLXt1r6 3WOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722012317; x=1722617117; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=XJLgZuR3KviFafgvQJVTyFT3i3vA9AL6Ik6JXASwW1o=; b=gcbr50pv13E7OBSZWyfMbdusDSEQknY+jNHiK5xkx3aTGSaRLqEbQ/0o71qiS/ZJbr eMVYJIz1atEHYjqRb8iLL9l8Igxow+b7sFj7kNYRZl3VD8fjBfnatEEC+nPgXdbiop6W k2ctFjRaDAIr311VBbFuzFqHkxEeZ4Kqvn84BzEMIEIOkkxInEvnVEWwCF2i8WIyQMiC xeJPETyh42zxcodlDPId47mtuhsxqpaf2Sf2hZl+RYWS9i9Kf6zRRJStvdJdc6OuSZ1R r7lEFGY2nNU/zPoYdY0JCy7H4geXqxwVzBqsmoLWvZ7VlxxywG10O4FrQyh/2KKajdio qEAg== X-Forwarded-Encrypted: i=1; AJvYcCXO9DQnzuy0+7fJ9mCItTnBPOJG3mc3s9OojJaEXvB5rl8VcQAVA/58vEOQ8R8XMnr8dY90Tpp6G1nAjNHaJQfAfAE= X-Gm-Message-State: AOJu0YyGIswadcpjyPN32+qYrUTlmq4648Gh3G9xeT9rTLFNQcxDo9x0 Lw2NdJFN1kCee2DHgMDqjy/hO4UJT0fcSab0ZJZXYzb3Fp4pSppILdSzI8juISsc6AK4SN8Rhyr qP6s/pPrapuaxABy4Z44PqJ6gc4/3q0I5PaP9 X-Google-Smtp-Source: AGHT+IEs6xxkecDHpoDt8aXv2saqRhNdcaqmQyIQMaHfq1aVGzWAr+xECNfHIFDYKnmrMq7rARexHpPAvEgy9LjO4gE= X-Received: by 2002:a17:907:9705:b0:a6f:6337:1ad5 with SMTP id a640c23a62f3a-a7d3fa3f679mr11658966b.27.1722012316474; Fri, 26 Jul 2024 09:45:16 -0700 (PDT) MIME-Version: 1.0 References: <20240709132041.3625501-1-roypat@amazon.co.uk> In-Reply-To: <20240709132041.3625501-1-roypat@amazon.co.uk> From: Yosry Ahmed Date: Fri, 26 Jul 2024 09:44:40 -0700 Message-ID: Subject: Re: [RFC PATCH 0/8] Unmapping guest_memfd from Direct Map To: Patrick Roy Cc: seanjc@google.com, pbonzini@redhat.com, akpm@linux-foundation.org, dwmw@amazon.co.uk, rppt@kernel.org, david@redhat.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, willy@infradead.org, graf@amazon.com, derekmn@amazon.com, kalyazin@amazon.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, dmatlack@google.com, tabba@google.com, chao.p.peng@linux.intel.com, xmarcalx@amazon.co.uk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 9n8jw8b1mjshxw4w3na3hf4m14wqs6tu X-Rspam-User: X-Rspamd-Queue-Id: 98EB42002A X-Rspamd-Server: rspam02 X-HE-Tag: 1722012318-396424 X-HE-Meta: U2FsdGVkX1+i0BKP/sytc3L9bZcMEehPt6GBE3qJc3FRZN2sVLujmsOF7V1P9tjRN+k1yC+n2VDwRqC0T6kQcGiyPeKh44zWOCXLAaqOfoXs2JWhwgzkvbe1ublVzQADL5/uifVLfXXnfFqcgnlCPwxrIn5i+vX+Rn1683pIu1Kmu7NvpJT9GCHElvIYUNUxFXG7R1Gr9h9wzWutRmUt+NGgYIxOPZ0Tih0w8nqMKkbWEB7uIzxDOs6++V8o13JeMrVxLmM22ZwkVxtUCf8ak4mrWoVD1/x+DjYKd5sXvIBEpiNAo/F3oruWmi1uKh3faUIYnMQF0ECRi0uxCHKCi+niZ8WaXn0PCr4aLt35FiKx7lGYPxZJ1QSaqqvYyj54k76i+WRx1X6eAFmjUiPdtWyOx2/rcX+mdIK6+FUDXq/XqYfoFNCIsokbRKcczpv4uQbeJiKnwG6zPAKyIFFzigZXlzQ+RykjLWYW26LE6+FJDEuEuUkqxsgu24nWkm4TZKsDoKIg3R0q34QOl4Ic3Wz8a4HQhJGYcT4yPsOD4phHtiSbvF0jtJHcIkzJwPnl+hchgg2Aw/ddGkmu6ywIhfSurWOsVnXzg05QJEWpNpKwB4SjQDAC81F7NmU4gbT103TV1fgJYG/lkpGbMbVZXuH0BdXycrDs1H/tcB1qyjuSFuJK6jQveNaDUGhCzkLNjmxXtqdsA4WrSOJOe6CrYXjTmHyCSZ0XswNnQxrgAv89GDD8wbAT6TZ2uFdDRZE+N5siLlENFD9ya9Wa+WysKD3kt4TPiHZG6RUGPGnfz5rOjHnRqXqytznH1hXPnMAunRShJoAoRmNXOjRzo/sdZC0E7f41pMDem4onU7qUY91RoGjqkdcSPO5PHF5dOervODifFHNkexiWKIcG/mJqjj4GdZKiK48+T/6/rbCdT4gvxtM1hk7+Z3JequVt9in2YjQDdIBAgY8dcUU95x8 gOTj+IVs oqFDQ3A2sAWmi4Eo/rAWx63m/5G5zTWs7khMTnEAL8XAvU2/pKJnSAZqqR10YQkTZaH7FwApq1qngO84yPJABw8KJipDD/uyWwEp9pHPLwIdvt04Wf5mtlBpUX6LOAZpXC+CkElNhrU1RWGhCZE63GS3mdBQx4C5GS4eegFH1ift/hlDZCwA0BOgTw00qrHfxvPhSsy2mjtQnJqCRSkRtipx5qB9k2pA943BE/oLspjFl+7VVrtlGDt6B6LrKJbRO3ua3RxfBg9PTNNaTUsXetl3P0eg7O7Uvdlolf2y739qUOJVH5/FHPkzNLTo6V5MdWOE/ 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: List-Subscribe: List-Unsubscribe: On Tue, Jul 9, 2024 at 6:21=E2=80=AFAM Patrick Roy wr= ote: > > Hey all, > > This RFC series is a rough draft adding support for running > non-confidential compute VMs in guest_memfd, based on prior discussions > with Sean [1]. Our specific usecase for this is the ability to unmap > guest memory from the host kernel's direct map, as a mitigation against > a large class of speculative execution issues. Not to sound like a salesman, but did you happen to come across the RFC for= ASI? https://lore.kernel.org/lkml/20240712-asi-rfc-24-v1-0-144b319a40d8@google.c= om/ The current implementation considers userspace allocations as sensitive, so when a VM is running with ASI, the memory of other VMs is unmapped from the direct map (i.e. in the restricted address space). It also incorporates a mechanism to map this memory on-demand when needed (i.e. switch to the unrestricted address space), and running mitigations at this point to make sure it isn't exploited. In theory, it should be a more generic approach because it should apply to VMs that do not use guest_memfd as well, and it should be extensible to protect other parts of memory (e.g. sensitive kernel allocations). I understand that unmapping guest_memfd memory from the direct map in general could still be favorable, and for other reasons beyond mitigating speculative execution attacks. Just thought you may be interested in looking at ASI.