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 942B2C78830 for ; Fri, 20 Sep 2024 12:37:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E4DA56B0082; Fri, 20 Sep 2024 08:37:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DFB386B0083; Fri, 20 Sep 2024 08:37:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CC2E66B0085; Fri, 20 Sep 2024 08:37:57 -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 AF3FB6B0082 for ; Fri, 20 Sep 2024 08:37:57 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 126CB140301 for ; Fri, 20 Sep 2024 12:37:57 +0000 (UTC) X-FDA: 82585068594.14.D461BE2 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf17.hostedemail.com (Postfix) with ESMTP id 5E57740002 for ; Fri, 20 Sep 2024 12:37:54 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=IAosnox0; spf=pass (imf17.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726835761; 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=x1dvcPtsLZR8K5qMQ5hQ3hsOFi1LD+/Tp2pAsvVsT7U=; b=he8LHAIS8LoAc5TMzQ6dPDwi31hGBj6sBeR+H1WXt4usxZ2m/7bMZugoJUmo5k83n+8gT2 5Chd3dKJbjUQwEuEeHVsSV9fhrsLkDz9XW2l8jK0R0IcqoYoe8M4GvR8f+rS0OY4fmUOKR +wlgwRlo0EtQA4FEF6W5KEb6xO+YOqI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726835761; a=rsa-sha256; cv=none; b=xxpga8lwBsBnUQrgHZ3rNDnwwS5wn+M9aOmlozYz/zG5oXpiurIDJCT0Kqdg9S27cbNpVW rNwiexDKOdBNCa3loqUmdE3ueOLmcLM4CP0y49i2XVh0MdD9/rOkFZt+ZmYouJ6SVOZR2q iKdfiBHvUoNuG5cwjAaJp/8Cw60Ke9s= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=IAosnox0; spf=pass (imf17.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 461C85C57AC; Fri, 20 Sep 2024 12:37:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4EA7AC4CEC3; Fri, 20 Sep 2024 12:37:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1726835872; bh=+xuRPrmR7i0CxITWrMzA6Rbir0u7SYmmYJphYrBfy3A=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=IAosnox004cPJJHW+Yce205KY2IrNZcl+CtEsZ66I+gYMKSE+fq8pE685GUG2D+EJ m1zHF9oNmFE5rcXk0uhVHyuVttL0SFDxoMmoHxvysv6F2CHInFj21hnvq8/iTgGvaI Q3F9Bzi0P6PuACKEq3bddrqjg6qomtCcOLXBXoXXTNzVyDGGdVqdOkG3hPCklQBNDX L21vx5LuGCCOeJwSeoogKTVj0e12k8ritzzV/uJzPJe1YtsMAZZCdiYNjwRjHJV5zI vWETvKPasLYzMiOdZPf2d7yNQ5bzAxvXcQ/uVvOECT/6dHsW12+8mHdktGo0VDm/eR yNTmeAkf5u+8w== Date: Fri, 20 Sep 2024 14:34:47 +0200 From: Mike Rapoport To: Fares Mehanna Cc: nh-open-source@amazon.com, Marc Zyngier , Oliver Upton , James Morse , Suzuki K Poulose , Zenghui Yu , Catalin Marinas , Will Deacon , Andrew Morton , Kemeng Shi , =?iso-8859-1?Q?Pierre-Cl=E9ment?= Tosi , Ard Biesheuvel , Mark Rutland , Javier Martinez Canillas , Arnd Bergmann , Fuad Tabba , Mark Brown , Joey Gouly , Kristina Martsenko , Randy Dunlap , Bjorn Helgaas , Jean-Philippe Brucker , David Hildenbrand , Roman Kagan , "moderated list:KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)" , "open list:KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)" , open list , "open list:MEMORY MANAGEMENT" Subject: Re: [RFC PATCH 0/7] support for mm-local memory allocations and use it Message-ID: References: <20240911143421.85612-1-faresx@amazon.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240911143421.85612-1-faresx@amazon.de> X-Rspamd-Queue-Id: 5E57740002 X-Stat-Signature: bx9wif1eythj8woan7dxnar661mw7gyq X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1726835874-569993 X-HE-Meta: U2FsdGVkX1/h8Z/SbHllCBhK8UP8mPZvqDp16vqvgkB9n7OPQIYLolBWR75J/8ndKVYr92Ix95MPqaMQAIREBS0dNbIDzXMTNIOx8aFehvuxiRS4JIb+Bby4jhHmQ5f/i7KsgI+mgeZ8ZTizsjj1WPVtUs/Ou/atWOD2YK5iBClJedwU7S9cjleMlMyWbUIWT9mJZ0N7nf83fNAIMxeswA4Ccxe/tlie25YduwRUSCDXtHqukF1Lzh6tq3Mr0lf8cSUv3GJiF82qeck22Kh54GXRo1N4LUYN6tjSgv8UAs9qlsapsvFS1ZEhGctfX83xA2QnlCoSeUeg+AXhlBxwxPyIueEEBniJIYEKHPfNwv7AZHWi4ffuD4w/p7Y5BcFwGtHe/h+1rpPfaRPGwy/04tVlIQFZkPN6dw/BLospvqdzD0z48SmGGhHwhJ+BjNdFk/9Gm7qyLJJ/h3sRriIjJ4Qgxubrx/BxBOGTTffyUuUCNxk8lt4DbstlcHFoZELMgeOBe67Lq9Cb9MJZLfYwNkaVZTZkJWYn+Ktv/qv2/NEO4hF6L3Z1GzKLeNPVJP+N5fB5KBXOKmDF0MK0F7M80cCBrmQ7qDEXgLQBsEXT7SLnD0GiNgC0yc2nnqV6cZeWY3mqtq3f9OjdJqC9i0niNFGNaDoEj2FzAxnyuf596dyDL59AXn70vCojmoDh9N3fR50R4sHVHA4rjducSthY617f6kGU9YrkWSdLpN7wrXv6n2fBVBqCMIQESb9yLRRRMe/94KqOwUQecJwCSi9WEIRzMzo29VIGayb7WZZrewNUDxGcdUWCeXqJ/Pj06PymsAfaZsvxxafVDlEDhSartHWuKxP/m+Hf2cKFNEu5wppq0UU6hNy1fq8a/0FRcTyDkRWo7e6hf9IRKKWPGVcrRj8PT9TmO/NTnQxmVhNutxKfiMmeLlaTQ7B+XFSUuIkbUZH8SgZM5foLza2X6km oISQh+a9 E4/I89fjerlRl+f9Gd+hJzdQzE7JBA1wuNGXVc8heDKnQLcH2bzZbWC1P+Ml93wrWYyU1rWCpSdLfYOXxqJQsnTXxl8DnixU6YxjJy20FERWwS4EG/ROn9Q/0U9OwhInsFwByI2vklLGfcKe7jTMqG46077nDGjT8k3uED9rvN0YhwAXMFhG1QMTjfZqqe8JchVbt8JxAfFbuMXtCQZtjHvpIj2ACQ5qeMPnxwoh5drwXwnyI5JTMlx/0XbhrmKpwfA5d+qOQfT8T8QGl73syx5DUEg== 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: Hi, On Wed, Sep 11, 2024 at 02:33:59PM +0000, Fares Mehanna wrote: > In a series posted a few years ago [1], a proposal was put forward to allow the > kernel to allocate memory local to a mm and thus push it out of reach for > current and future speculation-based cross-process attacks. We still believe > this is a nice thing to have. > > However, in the time passed since that post Linux mm has grown quite a few new > goodies, so we'd like to explore possibilities to implement this functionality > with less effort and churn leveraging the now available facilities. > > An RFC was posted few months back [2] to show the proof of concept and a simple > test driver. > > In this RFC, we're using the same approach of implementing mm-local allocations > piggy-backing on memfd_secret(), using regular user addresses but pinning the > pages and flipping the user/supervisor flag on the respective PTEs to make them > directly accessible from kernel. > In addition to that we are submitting 5 patches to use the secret memory to hide > the vCPU gp-regs and fp-regs on arm64 VHE systems. > > The generic drawbacks of using user virtual addresses mentioned in the previous > RFC [2] still hold, in addition to a more specific one: > > - While the user virtual addresses allocated for kernel secret memory are not > directly accessible by userspace as the PTEs restrict that, copy_from_user() > and copy_to_user() can operate on those ranges, so that e.g. the usermode can > guess the address and pass it as the target buffer for read(), making the > kernel overwrite it with the user-controlled content. Effectively making the > secret memory in the current implementation missing confidentiality and > integrity guarantees. Having a VMA in user mappings for kernel memory seems weird to say the least. Core MM does not expect to have VMAs for kernel memory. What will happen if userspace ftruncates that VMA? Or registers it with userfaultfd? > In the specific case of vCPU registers, this is fine because the owner process > can read and write to them using KVM IOCTLs anyway. But in the general case this > represents a security concern and needs to be addressed. > > A possible way forward for the arch-agnostic implementation is to limit the user > virtual addresses used for kernel to specific range that can be checked against > in copy_from_user() and copy_to_user(). > > For arch specific implementation, using separate PGD is the way to go. > > [1] https://lore.kernel.org/lkml/20190612170834.14855-1-mhillenb@amazon.de/ This approach seems much more reasonable and it's not that it was entirely arch-specific. There is some plumbing at arch level, but the allocator is anyway arch-independent. -- Sincerely yours, Mike.