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 D57A6C25B78 for ; Mon, 13 May 2024 22:02:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CE2208D000E; Mon, 13 May 2024 18:02:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C92198D000D; Mon, 13 May 2024 18:02:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B59A08D000E; Mon, 13 May 2024 18:02:12 -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 96C808D000D for ; Mon, 13 May 2024 18:02:12 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 41005160E00 for ; Mon, 13 May 2024 22:02:12 +0000 (UTC) X-FDA: 82114746504.19.B6E6768 Received: from smtp-fw-9105.amazon.com (smtp-fw-9105.amazon.com [207.171.188.204]) by imf01.hostedemail.com (Postfix) with ESMTP id 0B80640015 for ; Mon, 13 May 2024 22:02:09 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=amazon.com header.s=amazon201209 header.b=jpsY17Xf; spf=pass (imf01.hostedemail.com: domain of "prvs=856bc4aeb=derekmn@amazon.com" designates 207.171.188.204 as permitted sender) smtp.mailfrom="prvs=856bc4aeb=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=1715637730; 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=5+iQQpOEZdEkzvrHSJ41DjlAjDtbE5SACcQXxQVlFBs=; b=bH2Uq/c13BEyv7faeiKIxO4XVCDa1Fi6gAJc2itgWT+8yoFa7aVmWXd1A4A+oNPsvY2JRa B79B7+u9cKUE8Q1pCPllyzC8rf9E1VxougGI9oc6Zy/R7ucyALazfBdWPpz356wL+KbtE2 +aLCXwJkUEHVWNFZvLwfufIR8fHiljM= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=amazon.com header.s=amazon201209 header.b=jpsY17Xf; spf=pass (imf01.hostedemail.com: domain of "prvs=856bc4aeb=derekmn@amazon.com" designates 207.171.188.204 as permitted sender) smtp.mailfrom="prvs=856bc4aeb=derekmn@amazon.com"; dmarc=pass (policy=quarantine) header.from=amazon.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715637730; a=rsa-sha256; cv=none; b=yzNyoDrahHWQCscLmBLazo0VOTT6JkpsY8WVAz8oh1cRFTOJHpdhs+K0GTSgAclFqXdr4h wNYgtlKk5DkkJ+/uy2chsX9ydBTCiTZxCkVq9mQoPd0ZcaayzthRVZyhN2ksW02qeiINnG 2XbKywxWZ07z40fyCRTbuCnAJ8cPCcU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1715637731; x=1747173731; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=5+iQQpOEZdEkzvrHSJ41DjlAjDtbE5SACcQXxQVlFBs=; b=jpsY17XfgJzgCIKc2Pd1PFAVgNycC4ffzyVHWjKh0L+z1XDmIeUtGVVt l9PtzDnEr69bKdUnICEGIJOlLdKQTXExGs+sahU1U9Cb9lxa58/BNitsa at6E96NpMc25z/cD8v+caJcyrVeum6Q3991Z80awjzguxg17k9NazYRYd M=; X-IronPort-AV: E=Sophos;i="6.08,159,1712620800"; d="scan'208";a="726172843" Received: from pdx4-co-svc-p1-lb2-vlan2.amazon.com (HELO smtpout.prod.us-west-2.prod.farcaster.email.amazon.dev) ([10.25.36.210]) by smtp-border-fw-9105.sea19.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 May 2024 22:02:08 +0000 Received: from EX19MTAUWA001.ant.amazon.com [10.0.21.151:19998] by smtpin.naws.us-west-2.prod.farcaster.email.amazon.dev [10.0.44.254:2525] with esmtp (Farcaster) id 166c483a-d211-48eb-b873-34e5ed9da520; Mon, 13 May 2024 22:01:52 +0000 (UTC) X-Farcaster-Flow-ID: 166c483a-d211-48eb-b873-34e5ed9da520 Received: from EX19D003UWC002.ant.amazon.com (10.13.138.169) by EX19MTAUWA001.ant.amazon.com (10.250.64.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Mon, 13 May 2024 22:01:49 +0000 Received: from [192.168.232.44] (10.106.101.48) by EX19D003UWC002.ant.amazon.com (10.13.138.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Mon, 13 May 2024 22:01:48 +0000 Message-ID: <7107a45b-0635-4040-9f4c-288708b13c04@amazon.com> Date: Mon, 13 May 2024 15:01:46 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Unmapping KVM Guest Memory from Host Kernel To: Sean Christopherson , James Gowans CC: "kvm@vger.kernel.org" , "linux-coco@lists.linux.dev" , Nikita Kalyazin , "rppt@kernel.org" , "qemu-devel@nongnu.org" , Patrick Roy , "somlo@cmu.edu" , "vbabka@suse.cz" , "akpm@linux-foundation.org" , "kirill.shutemov@linux.intel.com" , "Liam.Howlett@oracle.com" , David Woodhouse , "pbonzini@redhat.com" , "linux-mm@kvack.org" , Alexander Graf , "chao.p.peng@linux.intel.com" , "lstoakes@gmail.com" , "mst@redhat.com" , Moritz Lipp , Claudio Canella References: <58f39f23-0314-4e34-a8c7-30c3a1ae4777@amazon.co.uk> Content-Language: en-US From: "Manwaring, Derek" In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.106.101.48] X-ClientProxiedBy: EX19D043UWC001.ant.amazon.com (10.13.139.202) To EX19D003UWC002.ant.amazon.com (10.13.138.169) X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 0B80640015 X-Stat-Signature: uy4djg7xs7k8upwwrkjyxd8k3bakdpkz X-HE-Tag: 1715637729-877127 X-HE-Meta: U2FsdGVkX1/WSsiobL/HuNGkwazRHehCOcCk3sf6L8KtE+mih8c+063T+ZIEDVw9QBlkoiaX4GdBeWWjCJftofC+6900xzcg1ZuzfcdAwxNM5w+DNOEluHXd+yXWJif9bwY6JeVBiXdPhWudjP8YInt2tYOBmQkFXdbUL/43A2wz5qBGp1euwkFJL+EpAgWoxykIXd6Mt8P83SnGmN8loZdK4of1tbk4vl+6G0zSL3uuZjBFvDyXuUD4WQq4eO2D314IpvHlnkiXANbNuy8Gb3RuJM642wv1R3uluaKVuI0mBGg9H50aG5S6J6v7RQSkya00pFptTvF42yKklaAmXSa04oOExOqL0gPKMWF6iguJ9W62WbdtI4jHGsX+0g476gZ5dqq3abfw9SXl/EvJi2T7s17HGF+VnoSStbitpzRhv6ckHj8kDfddMZ3GkamfXl88ezjnWcPgOsALW2dxG98OvyjFEXMA+SjPcUaYACqotbBcAteErTBU8lsGjHqpIUtBve1ZX6Pzj9XjWz8tBIb6HT4hwUOXxLKwQwIcE4F1hRS0z1nwvmzK8XKCc/a9k0/hCAPDXdQWI16QeeBmYlITcKVtySFkY4bjDSm+cEdbArbFYzd5H/cCGQWi/WGDlIPAPDgcObFGWvyofy2fouoD7dOAFPtcdLxqh/WEzGwbwWYRkR1sWAGGgqBlDigx0/9mGOId3IR94EZj/eE/tJu81t0qaeGHCfejMwQI5Gqu0i5q8NQ6bogsDmu7HmEq9B+zsEognpsxh4GTV0NOSNyt36X0XLMhnAa8rHwVZYLdwPWMlh7id1wcdd2H1EQ5U03JPalj9SCiAs7WgbQuw6a9uxPY3LFGqSRnR8mR54BvwsJWNCBauStGu5BSmh1H4KStFVwS2x5brpShm3nie/PCJmTDoK5qNIS+KMSsDNLrL9uZEUUUNR2PtRlLpl474YBxEXNRMWex9a+qAob a3sBpPv8 QS3Jqy5z8JgUIepso5mEHYA1Zwvd46pk0nwu2+HHcBm1CWRbuuntaJty1+c0J1EW/ddVroPpdkQuWLo7jwtC7Tj46ekwX8Xnuj+36Yui3BH8z69zpJ1u8DOOZr2U26vQ9jIa6mUo9ozK8IQVzpyCrfDPhItWaFXjZhC2YVEddHG6QoKl1vvV2th8NO4Oz4sul7XwSRp6NCfc18Fk25p4jJVN+05nKKP4+ySEJscUwBgfUlCAkNd9u1gtiMHXx/i2evdU7OdAvsB9I/1Llqzdwb98n1QV/Gyw7EscVwxdVeocoVY9qhZrNMnAEuA8BdzOv2hN/mCycopUHYKl9kbKCzucMdHcxCdn4xLlWEpADeh7R5aEDx3Cfnt85zV4oFbjeSx9MlSABZDr4KIT7m/840xGzWXs6jL07o5zI0ZLaKDDiarXISluj4BYmlSrngLQCD7UEVmelRulYQoqszBtZM71jFIYsfRsoDImJem9uBHo1riULLeIB9fr9Cc3rMNjNyUvMo2BLibKScZ/jCNIfVOWJ0SsNnCQOUAj/q+lCHc26yorrKj7eWWdUyf2sz5J+0+KBypC9w9o2ThYzWweVDs1gSTcMlRX782oVmjncYIdMEQxGKLP2L1s25eFYIXZqOgdtNF9pr7CEBy2G2BoqjDh+7k/DRfBolhTH97nTrX/Z1qiaVWI7Rw3n2VXoz0cKEBFJNXqytrfX/1EyC0QEUvOtVzELNQzwe81KtsuM3n30gAUdycrUm5qU76L+j61Gz6EXMnkUyMQwexw= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000005, 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-05-13 13:36-0700, Sean Christopherson wrote: > Hmm, a slightly crazy idea (ok, maybe wildly crazy) would be to support mapping > all of guest_memfd into kernel address space, but as USER=1 mappings.  I.e. don't > require a carve-out from userspace, but do require CLAC/STAC when access guest > memory from the kernel.  I think/hope that would provide the speculative execution > mitigation properties you're looking for? This is interesting. I'm hesitant to rely on SMAP since it can be enforced too late by the microarchitecture. But Canella, et al. [1] did say in 2019 that the kernel->user access route seemed to be free of any "Meltdown" effects. LASS sounds like it will be even stronger, though it's not clear to me from Intel's programming reference that speculative scenarios are in scope [2]. AMD does list SMAP specifically as a feature that can control speculation [3]. I don't see an equivalent read-access control on ARM. It has PXN for execute. Read access can probably also be controlled?  But I think for the non-CoCo case we should favor solutions that are less dependent on hardware-specific protections. Derek [1] https://www.usenix.org/system/files/sec19-canella.pdf [2] https://cdrdv2.intel.com/v1/dl/getContent/671368 [3] https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/tuning-guides/software-techniques-for-managing-speculation.pdf