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 D017FC54E5D for ; Mon, 18 Mar 2024 14:11:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3A8C86B0082; Mon, 18 Mar 2024 10:11:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 358A06B0083; Mon, 18 Mar 2024 10:11:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2206D6B0085; Mon, 18 Mar 2024 10:11:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 109CC6B0082 for ; Mon, 18 Mar 2024 10:11:42 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id D1671805B9 for ; Mon, 18 Mar 2024 14:11:41 +0000 (UTC) X-FDA: 81910348002.15.9DDFC64 Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) by imf29.hostedemail.com (Postfix) with ESMTP id 9A88F12000F for ; Mon, 18 Mar 2024 14:11:38 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Kg93a7MZ; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf29.hostedemail.com: domain of jackmanb@google.com designates 209.85.160.180 as permitted sender) smtp.mailfrom=jackmanb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710771099; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=rU3zFykgVuweueIsoxzQMtKYDDN5Bjw0bqJ5bY+qA6E=; b=V2hvuVi/QrFmQS5hL5b3ZZpesUORt/mOFNeXgL0lLzNnVXHzosCXdx+O3ur50lxNJdgRWt Wy+ftvNKGMljCIMO8hhF3tU/apH/fJqbzPBofqEgXHNqerVHBPDhdFr4K3qGPzb85Clael OvGmAFAMOLWgSqrMPd/G0XpsBqw6ej8= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Kg93a7MZ; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf29.hostedemail.com: domain of jackmanb@google.com designates 209.85.160.180 as permitted sender) smtp.mailfrom=jackmanb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710771099; a=rsa-sha256; cv=none; b=433xjVYJ4Sm0IRqM3sZ1DQbnUdZXsvh4jvk3GhyphqmY5EFGehiwHRumkmhdamwGi3LHcQ t3hqQHZiVyUK5sPKcjrvCHbklqyrFgmlx00XYDj5LoFNfqLT0ITRLPWDr9TPDRSgF9oRk7 k7yHeJH9RPw2NVo8xsVX1sBsif61clg= Received: by mail-qt1-f180.google.com with SMTP id d75a77b69052e-42ee0c326e8so419581cf.0 for ; Mon, 18 Mar 2024 07:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1710771098; x=1711375898; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=rU3zFykgVuweueIsoxzQMtKYDDN5Bjw0bqJ5bY+qA6E=; b=Kg93a7MZZ8OWP+gDhBonVJzMhwZxfW4p+lIRxdmFAahFJT1e3cAQB34h+xf5uYFSzj DjUScypGElFjMDoSsNgKuQoaHolsmNcveXo+Rd5T+WEj96h05OMcHA5Y4P+S9hrG1XCN xV47mgG8VL1NpCvAhu2DVtAJbjiUfTnwM1QLXosy6fpahEW/5lnTFeXWvC3/mfs2/4aT 679xu1j2OkzZCPrb9Q41aeyPm4uDDkqcJ2V3K4G3/PdzQ8biONAMvdSTbHfMI/A/tG0n DYenJDAob5tOHL/hbzzd+/ptFCjZt1N+N2tKoVtDWWna1gACygUBm63QIenrWXR3dt6z 0AGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710771098; x=1711375898; h=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=rU3zFykgVuweueIsoxzQMtKYDDN5Bjw0bqJ5bY+qA6E=; b=X8UCcCvbxe84Ro1+7NrRWceQNe+LPLxAeda9QRl3oZDUwvwhV7E9UazcyitQDYwPD7 6om8zIHVMWq7GuAIcsSBkQKEzx1wZ1ZGoFZY4PtwQGGENJgpyhixgyjamlKlHyuTFjU6 iTj5qvCxYG+Yu7WAM/Pi65H8HV3L90JFMjCzdN8+mmWc9RIubLlg3pKWO9prvWum6K3e TGMBHEequ0I/Ve3OF4tezt1EL2L2SSZP93vLUEL6Jzt0rZTQQ9F9gCicT2FNPR50s5wh 8cLG4MHrLiz1mlC9Ix67jOWXbEOmPINeVjRT/u6wsCIVSz004nD/qT+mSf943phjdNNC GFWQ== X-Forwarded-Encrypted: i=1; AJvYcCVomkfc7D1jPbuUQcRqzuxZG6KT/w6bFtxe5b5dk3OcHp5m1pd8K512kcHfv9/k2rlzQslLSg+951chQ0wcmxM2bHg= X-Gm-Message-State: AOJu0YygFhnTENAKeFdQ4IQQHZXERXmLGW+eZwHk0eErlntFMH85MpO9 48GBmNiWgKwhLpN/X9T3VzcgsJi/Mwb2h+KD1nDhCsH92mPI8TO63KZuziackQXoiLQn9Kt+W41 ezEEj6NugKd62Y0a/NAL9qgF/aWmKDZh6vwPV X-Google-Smtp-Source: AGHT+IEP1eDBtV9wwG22o9FLtfUkcC57ZS5hhvLcQHaosamz9mFsDACdCEemZgZ1KW9i0+WwUAZxZDxm/IPXpyAyIxs= X-Received: by 2002:ac8:57cd:0:b0:430:9ee1:a8 with SMTP id w13-20020ac857cd000000b004309ee100a8mr330194qta.3.1710771097539; Mon, 18 Mar 2024 07:11:37 -0700 (PDT) MIME-Version: 1.0 References: <8e3c2b45-356d-4ca9-bebc-012505235142@amazon.com> In-Reply-To: <8e3c2b45-356d-4ca9-bebc-012505235142@amazon.com> From: Brendan Jackman Date: Mon, 18 Mar 2024 15:11:25 +0100 Message-ID: Subject: Re: Unmapping KVM Guest Memory from Host Kernel To: "Manwaring, Derek" Cc: David Matlack , "Gowans, James" , "seanjc@google.com" , "akpm@linux-foundation.org" , "Roy, Patrick" , "chao.p.peng@linux.intel.com" , "rppt@kernel.org" , "pbonzini@redhat.com" , "Woodhouse, David" , "Kalyazin, Nikita" , "lstoakes@gmail.com" , "Liam.Howlett@oracle.com" , "linux-mm@kvack.org" , "qemu-devel@nongnu.org" , "kirill.shutemov@linux.intel.com" , "vbabka@suse.cz" , "mst@redhat.com" , "somlo@cmu.edu" , "Graf (AWS), Alexander" , "kvm@vger.kernel.org" , "linux-coco@lists.linux.dev" , kvmarm@lists.linux.dev, tabba@google.com, qperret@google.com, jason.cj.chen@intel.com Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 9A88F12000F X-Stat-Signature: ubnrsgj4txo9twnstfd9teohg7xmhryf X-HE-Tag: 1710771098-898747 X-HE-Meta: U2FsdGVkX19TR+5nKgRHJ3obiuPX2A4kFcnLEvcVZM5MKqLflNqUXKIpVagIhtmEuzmyGozwpTwPaoaByOYNkI0BtlorIDsZeebIs8b+vN656/tOjRZ1whqikngVw0Unz5iy+flHN01+nqN17jjxC6ihs2CPoUNRra/ZFUsrMHe4AUQUt+fTXtCJ5grS84+/8C+STquIDOLYNyEJXlvXWiMZLwqydVQOtZNYj8mZDB6XfAJjLOA0m0pQ4Wua3prrIdpevnUeuLG63TLlLNBNmBOWUOLM5ScXOiL9mnU7VJ0UtsB1AeWae04h71q4QTLAPp899DrOSn18ijQGT1ZH9qeHCuQZdXpCXw+z7jJLsWbIrxZlOHkK9dXygFRIqacNrM8KAgaqMGOcl3cbNRcbjPYq8mYK3y7PmDu/l5rr9hpt72fiTKgANS5LqBdI5oiaLfOIjZBPdsVYjRmqyCqKn2qiTXTYhbkCnFFvblLm484htKLF95CkfUPVArnD9dH7fTnUDWypM5Jii3zdeD8yrri5F6s2F+/qCeLV6OzMv3yT4Lh6KHPdR9fIucuTF/hK0cSv2bvT0J/WfjTOPp4khSfrTA8TMTCAlb7Lfo/sREM0R3bP7hBSv/VV11uRsJ6EtdBcd8ysauTVxsvW69N2tf/KY6668hhEFSI/nV7Ei5KzDCu6kVXU/Xzp3BcVA/gOqJkUs18sW6sG0bxuX2b2WI7tZ0UMZvJl2UJCr+jJvejkaIuVdB9ZTuzLjMcYukEzvTe9Cpw4eMOh9uEehsVTTXwQfIy+CvGeAHM6m6lNAZFq6YgFf1+BD6IgYDfN5qcQ3PQjxjlk3SD+JfwrxKEB8q7SPoeBwkuUTr3/9QUSDw+B00kHTaKj86W9B5xTijOUN3OlnZwtWQVJbQaqw7xUqtpiGZhriymj7hiGJdQ/qmh5DlOymSAXzplj1xgsxfoLsha8eOIU+xQmOm6q8HP fLfropWY mQ6hE5Fyr/IxLHAKTsDenBZyQgOOW8Sg6EEJ1q3RM7Ls41XSdVuCl2dCPvJFDAuRP8xuQ5M+Rw8pdVMWxR9vK4IoBTDsMdR9t8Brg7xLc2ykTuA0ysh2YpQuO/1bn6bN2r7vN/gUiEPVGnSlpZaUECKxe8cA8yktEvhhAONu4DwOZYtxXhtG0dFuF3QEJ7/dMcRxkUpoDpyeWAURMj+jdnVfP4i1knW1y9P5ne+7Su2jyEMhlqFqV+p82Og22zi5Ho8MM9RdotPPaUtN7uzKUSI68I/WZKDz8dEIULRlBfGfD8lWStRyisCdSOZBX7EPGhP8q X-Bogosity: Ham, tests=bogofilter, spamicity=0.000013, 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 Fri, 8 Mar 2024 at 18:36, David Matlack wrote: > I'm not sure if ASI provides a solution to the problem James is trying > to solve. ASI creates a separate "restricted" address spaces where, yes, > guest memory can be not mapped. But any access to guest memory is > still allowed. An access will trigger a page fault, the kernel will > switch to the "full" kernel address space (flushing hardware buffers > along the way to prevent speculation), and then proceed. i.e. ASI > doesn't not prevent accessing guest memory through the > direct map, it just prevents speculation of guest memory through the > direct map. Yes, there's also a sense in which ASI is a "smaller hammer" in that it _only_ protects against hardware-bug exploits. > it just prevents speculation of guest memory through the > direct map. (Although, this is not _all_ it does, because when returning to the restricted address space, i.e. right before VM Enter, we have an opportunity to flush _data buffers_ too. So ASI also mitigates Meltdown-style attacks, e.g. L1TF, where the speculation-related stuff all happens on the attacker side) On Sat, 9 Mar 2024 at 03:46, Manwaring, Derek wrote: > Brendan, > I will look into the general ASI approach, thank you. Did you consider > memfd_secret or a guest_memfd-based approach for Userspace-ASI? I might be misunderstanding you here: I guess you mean using memfd_secret as a way for userspace to communicate about which parts of userspace memory are "secret"? If I didn't misunderstand: we have not looked into this so far because we actually just consider _all_ userspace/guest memory to be "secret" from the perspective of other processes/guests. > Based on > Sean's earlier reply to James it sounds like the vision of guest_memfd > aligns with ASI's goals. But yes, the more general point seems to make sense, I think I need to research this topic some more, thanks!