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 1D2BBCFC5FF for ; Thu, 10 Oct 2024 19:27:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1726F6B007B; Thu, 10 Oct 2024 15:27:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0FBDC6B0083; Thu, 10 Oct 2024 15:27:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EDE616B0085; Thu, 10 Oct 2024 15:27:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id CD17E6B007B for ; Thu, 10 Oct 2024 15:27:18 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id C663A1A039B for ; Thu, 10 Oct 2024 19:27:11 +0000 (UTC) X-FDA: 82658676156.18.81D5119 Received: from smtp-fw-80008.amazon.com (smtp-fw-80008.amazon.com [99.78.197.219]) by imf24.hostedemail.com (Postfix) with ESMTP id A5F8C18001F for ; Thu, 10 Oct 2024 19:27:14 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=amazon.com header.s=amazon201209 header.b=h6iaG2cJ; spf=pass (imf24.hostedemail.com: domain of "prvs=006a316c8=derekmn@amazon.com" designates 99.78.197.219 as permitted sender) smtp.mailfrom="prvs=006a316c8=derekmn@amazon.com"; dmarc=pass (policy=quarantine) header.from=amazon.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728588391; 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=OEH00vqI9ntRyA4QhbqwFD2+B7TmPgXstqQdwdzNaqg=; b=Er+rxD+HbXN1svgi7mr+PezE8txlWSGZxKFe/K5QG8pmd6PeuDH950HMiYq8Qe2Hh9TcCI HfWylpgPsgyJZBjy+d1CisUQ6pHgdz5FO1lzq5w4AXbl1HG0ZKl1H850xmjcqWf7d2Bc0y 3rYkbHMWL85wTXW9YkgQ2X9ANWtuwhk= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=amazon.com header.s=amazon201209 header.b=h6iaG2cJ; spf=pass (imf24.hostedemail.com: domain of "prvs=006a316c8=derekmn@amazon.com" designates 99.78.197.219 as permitted sender) smtp.mailfrom="prvs=006a316c8=derekmn@amazon.com"; dmarc=pass (policy=quarantine) header.from=amazon.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728588391; a=rsa-sha256; cv=none; b=QLl7uG6d6OFl9i1jq9XEFH5saz5ZrRKtAWDrNlZlizrFV1+zL3EucVa1UCHwVf2aZCdf0H vd7rohhUOryT8Qod1YFNaqV0/Dw0X+Jq/n/aQpf2/qZrKJE2q4QLlZCpWL9/xERdqiwev6 Iqk8LB6R0E85dn77LaRc5qUa8vi17+M= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1728588435; x=1760124435; h=message-id:date:mime-version:to:cc:references:subject: from:in-reply-to:content-transfer-encoding; bh=OEH00vqI9ntRyA4QhbqwFD2+B7TmPgXstqQdwdzNaqg=; b=h6iaG2cJFD1hXO02gQdpw4SadnP4caPixboFbp1prQOpZKoj/UPZ/a2q wNkohU8KhKWQA32gz/WlvwlW4MEQBQgAViD7WKUWk456XI/lAAIOMgLWV Tg1Y6paytiZpCWUVnQpt1g95e2ev/IVrCM2DMrCuAdZi72uZNC542rBKl 8=; X-IronPort-AV: E=Sophos;i="6.11,193,1725321600"; d="scan'208";a="137549306" Received: from pdx4-co-svc-p1-lb2-vlan3.amazon.com (HELO smtpout.prod.us-west-2.prod.farcaster.email.amazon.dev) ([10.25.36.214]) by smtp-border-fw-80008.pdx80.corp.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Oct 2024 19:27:14 +0000 Received: from EX19MTAUWB002.ant.amazon.com [10.0.7.35:4948] by smtpin.naws.us-west-2.prod.farcaster.email.amazon.dev [10.0.38.26:2525] with esmtp (Farcaster) id f363ef87-207c-439a-bf2e-f001afa02b30; Thu, 10 Oct 2024 19:27:13 +0000 (UTC) X-Farcaster-Flow-ID: f363ef87-207c-439a-bf2e-f001afa02b30 Received: from EX19D003UWC002.ant.amazon.com (10.13.138.169) by EX19MTAUWB002.ant.amazon.com (10.250.64.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1258.34; Thu, 10 Oct 2024 19:27:13 +0000 Received: from [192.168.208.61] (10.106.101.38) by EX19D003UWC002.ant.amazon.com (10.13.138.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1258.35; Thu, 10 Oct 2024 19:27:10 +0000 Message-ID: <7aca068b-5332-41b4-a06d-fd21b4a715f9@amazon.com> Date: Thu, 10 Oct 2024 12:27:09 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , References: <6bca3ad4-3eca-4a75-a775-5f8b0467d7a3@amazon.co.uk> Subject: Re: [RFC PATCH 30/39] KVM: guest_memfd: Handle folio preparation for guest_memfd mmap Content-Language: en-US From: "Manwaring, Derek" In-Reply-To: <6bca3ad4-3eca-4a75-a775-5f8b0467d7a3@amazon.co.uk> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.106.101.38] X-ClientProxiedBy: EX19D037UWC003.ant.amazon.com (10.13.139.231) To EX19D003UWC002.ant.amazon.com (10.13.138.169) X-Rspam-User: X-Stat-Signature: 7pjp4gb9tsytgcicnuo9n4hnucefffxw X-Rspamd-Queue-Id: A5F8C18001F X-Rspamd-Server: rspam11 X-HE-Tag: 1728588434-522715 X-HE-Meta: U2FsdGVkX1+j90DoScfv3SD8dJAbL2dxL3Rn8XCfMzf8MoiSPlz3jch1R0P4/AA0jrsUZDlXUBnwwrndLNSWlVaMaTSpWWmfgkmg1Sk+xviInnyRLnoFM05vXtcxWjkXU/K8W7uBUQmRUwk3RuKerhHuHrWNcsotxaZlwKl/0EbVy2TE2fKNVb+4C1bzziYelii9iDngE5BaV7fouxSJDIpj3wRAhYAA6Zljvr8/Z1cCYIQkxtxXiyozjZBNRMjeuR4e2IB7UIHUC3cOpJWhU/fgcynvTZJCS/JRwabNTWcftTP0WK/dGxyl4K7nxLJp6Ons+j6bbr4T1kCQGO3FCEWGbLLcrl5sz8iTdS9aG2DN4rbuWyfBfvJs4LHefgyQovvROFh0bgsJBycXuvjD/9o7laP/uz/5Dbjrj9Q/Btu69nmBRuvXIjtm4qR/xH+6/fKSxSJMgVBGGGE+FgaW9+pKxHThwsZYH/qtdIMxiPzDKH/VzkVrbGJlAIhleNOvX2dHA+u6FXQVUuwWNGCporrIkhvigNr94C5J3aGdBdJ+QjoHU/k4X+67Ci+9c9zu2F3wgV4CZXMN8QD1VvxrvYkEZCvHLmWWbSJRGAmw41EMnE2KaPmQQ4bBFFbw8MHv3woIxDZFZxbXMrm+4DfMvpCUB6yPlu0Dg0iaFf96hEP3yks+v4mNiKGq027ufC7g2451qeUH0s2ZpnGgVLkvd/2CIw+r+MCqmNTr/r4yvpvCHUIvG+q8NunHEhbxrY39vZ6q7WpMVjK7/xdxh0hb+PdSofgYKJTl9YH7xApQ4jNonbgdVfrRfkGuWus+19Dddfn6SslwXU6gkEZkA7BjZjp1b+l6f/Igp1Nspo9FbmISo7Z73ro6xnt6w04sR4OMEsmzx6wgQ2qauAuZEGT8jV4ZyxybY8FFcLWTdZ+oK/i62GkusW/o9SytwJ3oBY+B3R8famvlNLv60ly/SqL DLPtAr7E QXzhbxnSxghn7sJQ8u6eKRhB0arVJTDLBU55fVVXEzCN6R3gUQAi1v5THt5WnXRnnUiZA0FEsKJy3SIzF8h57lKSMsQXPCqNo8cUXXncwzsp+ERRyaQGOhFO2B9bm2URtGSYzsQmpMbjknUDe+cbURB81VBO3jva7SerqgFNGhUGfDipV54NqZuunOyiYyKzxmNv2v0zZd9O3GvnWHu8VkojYxf4y/glzAVRtRksbwQjmS9c8V4tVgxMlbdvM8JqOUDnr5Pe/jHrF6PCK3cWdW5TpLOq3fLxIZjKY3BIdoQ0cj77/x1vW+YlQ9mDIaUUkRE5WduehbhGzAHDoezt4KrWSXjGfHfwyrkQxZixFAw31vTrD/7Fq/tS4WUuvdnq3zJprT3Iv6sHPB8JzITokW8g3qlHHMXDMAUy3FaAtD3c1vOZRuffuGWG+fj5aMWjBwjpnW+G0r4y10xej592SGOHcQX/+ktbWBUHOA5rOjS6mKJh3v5M8bFWKZ3QIZ75Q+rr6ry8ByTGGwRLnRgSAWGxk6N9wR2DJawkxH2uEeIEJ23LZo3CxbE4dPN4bwV+Y/e2tGdIVPiKxZHU8Uecbqtwl2phgYw1q1zBYCzR/oEK1ij0/UGyKPQLnOOkzTx4KdHp33TJf334/kiSxLymufWYxNwFK4kV+esHk9KSnI8JipZzLOZUUth3e5fAX4jk3jMDNk+FFch5JKJcHTOu7gFXVexkt82RSkH/vSwDUiV+jeRnjMpk4z3Ed0GHngFUJ88Fh19MCfKw+6UfqsQqudRxfzGjpc/+e7IcBpQNEN05evwpvBd63bLrLIC6q4Nt+QLi4zsP1w7Fyl5k9Neg2q1XE7POhznY390gE 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 2024-10-10 at 16:21+0000 Patrick Roy wrote: > On Tue, 2024-10-08 at 20:56 +0100, Sean Christopherson wrote: > > Another (slightly crazy) approach would be use protection keys to provide the > > security properties that you want, while giving KVM (and userspace) a quick-and-easy > > override to access guest memory. > > > >  1. mmap() guest_memfd into userpace with RW protections > >  2. Configure PKRU to make guest_memfd memory inaccessible by default > >  3. Swizzle PKRU on-demand when intentionally accessing guest memory > > > > It's essentially the same idea as SMAP+STAC/CLAC, just applied to guest memory > > instead of to usersepace memory. > > > > The benefit of the PKRU approach is that there are no PTE modifications, and thus > > no TLB flushes, and only the CPU that is access guest memory gains temporary > > access.  The big downside is that it would be limited to modern hardware, but > > that might be acceptable, especially if it simplifies KVM's implementation. > > Mh, but we only have 16 protection keys, so we cannot give each VM a > unique one. And if all guest memory shares the same protection key, then > during the on-demand swizzling the CPU would get access to _all_ guest > memory on the host, which "feels" scary. What do you think, @Derek? Yes I am concerned about this. I don't see a way to use protection keys that would ensure the host kernel cannot be tricked by one guest into speculatively accessing another guest's memory (unless we do a key per vm, which like you say severely limits how many guests you can host). > Does ARM have something equivalent, btw? Yes - Permission Overlay Extension [1]. Although even the most recent parts don't offer it. I don't see it in Neoverse V3 or Cortex-X4. Derek [1] https://lore.kernel.org/all/20240822151113.1479789-1-joey.gouly@arm.com/