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 33725CF043C for ; Wed, 9 Oct 2024 03:51:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A5EEE6B009B; Tue, 8 Oct 2024 23:51:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A0FA26B00CD; Tue, 8 Oct 2024 23:51:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7C6866B00CF; Tue, 8 Oct 2024 23:51:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 5E49B6B009B for ; Tue, 8 Oct 2024 23:51:25 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id B1716C0F47 for ; Wed, 9 Oct 2024 03:51:22 +0000 (UTC) X-FDA: 82652688888.20.1D6B618 Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.25]) by imf02.hostedemail.com (Postfix) with ESMTP id A5D1A80013 for ; Wed, 9 Oct 2024 03:51:22 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=amazon.com header.s=amazon201209 header.b=Kcw6IMDh; spf=pass (imf02.hostedemail.com: domain of "prvs=005bdb7fb=derekmn@amazon.com" designates 72.21.196.25 as permitted sender) smtp.mailfrom="prvs=005bdb7fb=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=1728445746; 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=Fz6m3s5wR0Xe7bKylBUoyAUXiZbhWI4E69+DbXptgGU=; b=PUAgM8/n67Y5jmABddtRtm0Dif7CqDEsSHvSl4q412Dc1JzArwL7eGAtJPJE+j1fPGSNl2 j4eswG+s+51/dY0KBvmXlY9CHV3rAa9annf+J1ZkPnTXXEWT5GeRokWaVSQUJ6JmJhpI49 A3oplZTb7yo1yJnDkatbwhJxQw0nXnM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728445746; a=rsa-sha256; cv=none; b=vQu22QLqW4qvOj2oTUMC38nsv+e40aXh+tDxeaS/4xcvX+e4MrviSwfZuMDtUmka9lhMf1 cpn2Ktbfd7AgPm8ayzlSdabHAYJBtbvktB9/L5RpyNTZuO7eBgbhIcfAwOtWY6MaZjp2Pd HNXXXcb6DqFuNytMIulxtyZ3xEdk8MU= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=amazon.com header.s=amazon201209 header.b=Kcw6IMDh; spf=pass (imf02.hostedemail.com: domain of "prvs=005bdb7fb=derekmn@amazon.com" designates 72.21.196.25 as permitted sender) smtp.mailfrom="prvs=005bdb7fb=derekmn@amazon.com"; dmarc=pass (policy=quarantine) header.from=amazon.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1728445883; x=1759981883; h=message-id:date:mime-version:to:cc:references:subject: from:in-reply-to:content-transfer-encoding; bh=Fz6m3s5wR0Xe7bKylBUoyAUXiZbhWI4E69+DbXptgGU=; b=Kcw6IMDh+CAWZNPpmwpzpu0AgleuTw6KPrzkTeBh+BcC4ICy6nq0JXQl 1EzaMHcxVYrGdCQSVVTwxbEvwkPn5hSWTh1SSkwcsTXLuH5dcJ8Jsh0dB 3+sg+PovgioDKfHosHKNOzOPeycMbmpMoASjEuctTVjbXYUOywnSD2oZ1 A=; X-IronPort-AV: E=Sophos;i="6.11,188,1725321600"; d="scan'208";a="433642865" Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO smtpout.prod.us-west-2.prod.farcaster.email.amazon.dev) ([10.43.8.6]) by smtp-border-fw-2101.iad2.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Oct 2024 03:51:19 +0000 Received: from EX19MTAUWA001.ant.amazon.com [10.0.21.151:59909] by smtpin.naws.us-west-2.prod.farcaster.email.amazon.dev [10.0.53.199:2525] with esmtp (Farcaster) id acf9dcc9-ae36-4c0e-a2a8-553270007ea0; Wed, 9 Oct 2024 03:51:18 +0000 (UTC) X-Farcaster-Flow-ID: acf9dcc9-ae36-4c0e-a2a8-553270007ea0 Received: from EX19D003UWC002.ant.amazon.com (10.13.138.169) by EX19MTAUWA001.ant.amazon.com (10.250.64.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1258.34; Wed, 9 Oct 2024 03:51:18 +0000 Received: from [192.168.205.151] (10.106.100.42) 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; Wed, 9 Oct 2024 03:51:14 +0000 Message-ID: Date: Tue, 8 Oct 2024 20:51:13 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: , , CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , References: 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: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.106.100.42] X-ClientProxiedBy: EX19D045UWA004.ant.amazon.com (10.13.139.91) To EX19D003UWC002.ant.amazon.com (10.13.138.169) X-Stat-Signature: q76gpnu3ojzxwgib3kppa8ikdbxmnzrx X-Rspamd-Queue-Id: A5D1A80013 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1728445882-975201 X-HE-Meta: U2FsdGVkX1/X/QcsQ4k8YQpun5A0W6Y1xpORqFhwLLDvvbSicU1VlaOl+ybo44A5YORT33WEItgZmZMx7l4tcC8bWrkXc6+XLXcCmFQEebLR/t6mc20mLQbBy9PJANyzDgcfjEwYsmuo7gceT5SamdZ5R1Ve9RHuBMJo9dyWsFnbaWjZxF38PpKfOdPhQLWEBIRXXjJ+04SN+q4D5mOk4SIkdD5Cx/zeT4qQ37ICY0qqDZu6RTGibP+HtTD9elMYlXNcJberNZzHJ55PtnFMv6DM/tljFhR0s8BDGISx34wlmc5mREC8KDBHdhwFrcCURLuOYJBo0vYL/hUWfr4ruUDKd06FwL8lgYldEMxhpgJ2BA5/PDmJmJLktF7BZjrGUVqY4KRg38zMd46q8r3yzdQ2KuY7UNx3wI0AdNLzha+GC097jqstrNOLW6HOngrNSFNxwJvKk6X1EGimQBA3jdlVtbamG9oUYsVbJv9Wn5RZuLtM3ZnZc9jospZIAXXB0cwkzAUTFVhq1jrsdA350EZNPVi0MDhiyIIjnGQcoF1pDh4UaMuWDWk03mpHgmFO6igOB5plg/BppPILZZU9oukzDDsLsMK5T58FT0AWfvc0pDOkdusvKF60mcjTXF0cDFg3yKK7wsenc0HtQvVXnJRqPHWfquxncB7KsgdklWIjh3wD4TFZgUK0lIgXAVqK8IGmoS2HWFs6xuAy00SvXu6zlzClANOSM1K+RLVL0u2S1xbe5fMoDorB+nJmVhGNG2KxjpDvpaQ/iuCanZJeoW3pPlsQsnGlaz+Sko+DlZYqeotSyxWh4HJCpikYuOgw/FQsHTlvOVw/hIn6VPq+HZCF9wrcgaVuVn7h9pSxPyByJ/UX3GoWeXlljDA7zW4OAxcPjzgROtoUvJ91Xo7PyMehMzU7qzTfuUdKdBIRVrkGlAwAVOS/jzAUO8QuTN9yWiQkg9Nf5w8k6nOYEpz QVdpUVWY JnaBvQT4KbgDQDoXapAZHJxEB2uKnKg9VQq1WACEkFrynuhsJlUTugAxkvH40GCGykOm/NAuTABP5fK2hFm43WSahzEiOKjMAb/tPAE6MAhzTtL3DosfCPptiDoU3JxdA32rcgOd6P8o0nuVtI6Se2/WTCwALyl0L8DBIWVH0TAN73g8/IBcZuclwsmS/u1zjaRXnnMPgoSPvhxekODIUGTJrG04lNZJyrDOOleW0BENbxueCVHUpb3mGRdcFQQqHszG+AShFp9naPL49hJlweNSisBGpOmCDM7AgK7tsKsOPdy8d2x+7Ed27pYKYzPl31we/79vs1fpvFmLJ2ISpb7eBdbIe4eGyHiVrHVi05xA08WLbtaUgtHUo2hhYOpoYYwWnhZVD2p/fuD3ciqRX8iEfg2UNMVU5uitzfPLSjiFSF1QR9L+0vDIMCFvUvFLSyRoQ2PBtRqIUz0aREh/T/0YImzA//aDnt6gGXgBPu4oFnxb+pfojjWoT23+tP7tGfyv1 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-08 at 19:56+0000 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. Yeah this might be worth it if it simplifies significantly. Jenkins et al. showed MPK worked for stopping in-process Spectre V1 [1]. While future hardware bugs are always possible, the host kernel would still offer better protection overall since discovery of additional Spectre approaches and gadgets in the kernel is more likely (I think it's a bigger surface area than hardware-specific MPK transient execution issues). Patrick, we talked about this a couple weeks ago and ended up focusing on within-userspace protection, but I see keys can also be used to stop kernel access like Andrew's project he mentioned during Dave's MPK session at LPC [2]. Andrew, could you share that here? It's not clear to me how reliably the kernel prevents its own access to such pages. I see a few papers that warrant more investigation: "we found multiple interfaces that Linux, by design, provides for accessing process memory that ignore PKU domains on a page." [3] "Though Connor et al. demonstrate that existing MPK protections can be bypassed by using the kernel as a confused deputy, compelling recent work indicates that MPK operations can be made secure." [4] Dave and others, if you're aware of resources clarifying how strong the boundaries are, that would be helpful. Derek [1] https://www.cs.dartmouth.edu/~sws/pubs/jas2020.pdf [2] https://www.youtube.com/watch?v=gEUeMfrNH94&t=1028s [3] https://www.usenix.org/system/files/sec20-connor.pdf [4] https://ics.uci.edu/~dabrowsa/kirth-eurosys22-pkru.pdf