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 225F0C02194 for ; Thu, 6 Feb 2025 22:41:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 986F8280002; Thu, 6 Feb 2025 17:41:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 936BE280001; Thu, 6 Feb 2025 17:41:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7FE8B280002; Thu, 6 Feb 2025 17:41:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 63942280001 for ; Thu, 6 Feb 2025 17:41:34 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 15234B279B for ; Thu, 6 Feb 2025 22:41:34 +0000 (UTC) X-FDA: 83090992908.20.FFC8132 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf02.hostedemail.com (Postfix) with ESMTP id 682CB8000C for ; Thu, 6 Feb 2025 22:41:32 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=CPLy65US; spf=pass (imf02.hostedemail.com: domain of kees@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kees@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=1738881692; 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=h/rUZaXRYLxrgBgshCQbA6+1bE3H/k/sIM+X94Cx5yk=; b=4DrarVGfu+6CUbusiFGZMBwyHRsN+D15s4H3HvS1dY+Z6pl1UATkijOiC6Mp9tRQVzRDmv 3kxszzAOly7OH9hDmtieoVIOePg2XL1j2ZqtaIM6f2fLoxtYkPFuk/BmsCOOcVqwUockrf kywx2AWCUvD0LXUWQFuIcECfUA5rHfg= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=CPLy65US; spf=pass (imf02.hostedemail.com: domain of kees@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738881692; a=rsa-sha256; cv=none; b=sfTZMhaPsu8cgMDOF8Wh0O8EkVJkVhG/hnmmGy1ed7KH5wp60s0BxAyQNzbGKb/0qe8tIZ a8cOzOUpJzMI90UCdbF9Wd4zum/aONEp2z6yOwqyqHdSZY5f4WnwX8qkSWJnHHUCulgoNV EF66x1FDYN7L5ylMS/ckxI8CQW5MqBc= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 8F51D5C483A; Thu, 6 Feb 2025 22:40:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F18F8C4CEDD; Thu, 6 Feb 2025 22:41:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1738881691; bh=qSJN84svPdMWH8aktcRiZHTS6zg+RmikFW+FS9uQhxA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=CPLy65USrvJKh1O4UBNVOzteiSFzuXeFerLTb+QfV5TWiJR91p4EYvI8e1wIozhmq mBHh+a4brX8oUQGHiI9fEl4mptmMRtN+ilHcPNMjdWcnh8pzA3ZVtef0ryiT5h6UKT BBXtAuGf/+iaqZhdwI2ZYA8nNBC4yvJnKpc6XYZ6ilSh+HdDw4v/97jDG7htOuIX34 rrEBhpt4wYRzTL4eRzOjqqEaGJOcs2FMvVPIFak//CM7yxbIyO5/vY+J7JG5RkPHga HOga/YPGjWP1Gh4gKO4w3i6miIzZlq7prT8DIUgCu+DdC6//nGDqwcsUtZEuNvWGuc cZa70cGISwVkw== Date: Thu, 6 Feb 2025 14:41:30 -0800 From: Kees Cook To: Kevin Brodsky Cc: linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton , Mark Brown , Catalin Marinas , Dave Hansen , Jann Horn , Jeff Xu , Joey Gouly , Linus Walleij , Andy Lutomirski , Marc Zyngier , Peter Zijlstra , Pierre Langlois , Quentin Perret , "Mike Rapoport (IBM)" , Ryan Roberts , Thomas Gleixner , Will Deacon , Matthew Wilcox , Qi Zheng , linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, x86@kernel.org Subject: Re: [RFC PATCH v3 00/15] pkeys-based page table hardening Message-ID: <202502061422.517A57F8@keescook> References: <20250203101839.1223008-1-kevin.brodsky@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250203101839.1223008-1-kevin.brodsky@arm.com> X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 682CB8000C X-Stat-Signature: zneqij4xanse1hhdk5huh4hn1ss3q68d X-Rspam-User: X-HE-Tag: 1738881692-933935 X-HE-Meta: U2FsdGVkX1/bHS/e6AHoMspNC8ZK2OWarAPTfO5Ymf0JBQBohcEkgfbI6LvCtJC1eA9pHZRGPxHzRVBZY08u8SIkAQ72JaeH7S/koVgyWbW+xL8tKWz0VtVVnBTBi85FQY7/cwFCBJ6QHcC/KBhz8ngjR1xuaNhfFg0JRLhJRRrafSDEa/asN4ZqzKjWF2n+Z+SwqvSYpXqskCnH+xcN4r9vDjWk/PXlZB6R0uG3+I3c10VuQJdBjCjrN9V3fxowCuBo0mukvVyNL28abO8fxSeSZLLCvkUwTIYHh6+zjlIs55iqJG3OfKAEhSARskEWXvp6ktkWomZAdVKw1qgSvg6MUOH2bmHHUXG5ytCLVF/vWBp67iU39EcuTcNfIq/ufphAFcLi4QTGXMB0XArsprmGZnVUJoEB610RCaeEB+YIxV2QqwM4kKU5hwAFhQVsQUL1y1QRNWclWyHKHm2TGUZV2pxxz6sjuYi3o3YaQcq/i43v9GwYm3Uf2tFWe8bPMJyQkeYabDO/FV93bighaWSldkQWK6VOeVyttDozJHXYcN9XPl7qnQ85gUyxNC7wLItDKUSQflhxuVWmTKDAagbiS9IcLuXsfXwddZhFF/FE90tTBrLFt1xUqtdHk7CWSj6aX+PlS1BnZXyiwlm/65ZMVBwhuWvqeAfIxxynTfYR/XD6vtv9FSt8Yqkitc3jrCIr62FdloBrIo4CeHEePgDGFh6g5vMeVVG0a2F5B3J1t6LWm4WapTkyQoltdjtnSUq9xWunISZ/jR8dQv7wZ0B8I6PAJXxSmREhg0sKYcxgMRhS+Vn2JzQkTTRsMC0k5d78xoyRadPCOYudR9QSze96aQY6B5S4KOwdIncf9K7ykUjS53o2Q9XAGyx08JNe5sVT1WESz5jicm1gMcKEDK+LT+tnMP7ypDbz7KgQfBgD5vWgGgYfhygYUtkhQCAIadiz/oKtmV3JxOJCXjN YhcgElD2 INvd9Swe0j+smZDWMVTq+GsGSxe/DFqUsawqiMjItZSRsA9kQAJ9RRS3OmXS8Hy2fR9MPWHHAhqb2mqw7/6bzeCDObzfCadEqqI4Dh1zRnM4EZKTWCddp0lhzxvsR9yRo3H7HCsxv7bXEwF+N9Ee0igm8oaYATJmRImSno9Acd+HyJ1OrJsnSc8Nb/JXbuI/XN2cIAtTBxjy3V4hy1zc1bGgsfrQqOmOQByIYZTk1p5FquiNeAGaOIBo0v6xx9NhAoJ+HwBAkICVVU5MR4u8yZg0vmOv/pfVpCneO9PGC+Up4710= 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 Mon, Feb 03, 2025 at 10:18:24AM +0000, Kevin Brodsky wrote: > This is a proposal to leverage protection keys (pkeys) to harden > critical kernel data, by making it mostly read-only. The series includes > a simple framework called "kpkeys" to manipulate pkeys for in-kernel use, > as well as a page table hardening feature based on that framework > (kpkeys_hardened_pgtables). Both are implemented on arm64 as a proof of > concept, but they are designed to be compatible with any architecture > implementing pkeys. Does QEMU support POE? The only mention I could find is here: https://mail.gnu.org/archive/html/qemu-arm/2024-03/msg00486.html where the answer is, "no and it looks difficult". :P > # Threat model > > The proposed scheme aims at mitigating data-only attacks (e.g. > use-after-free/cross-cache attacks). In other words, it is assumed that > control flow is not corrupted, and that the attacker does not achieve > arbitrary code execution. Nothing prevents the pkey register from being > set to its most permissive state - the assumption is that the register > is only modified on legitimate code paths. Do you have any tests that could be added to drivers/misc/lkdtm that explicitly exercise the protection? That is where many hardware security features get tested. (i.e. a successful test will generally trigger a BUG_ON or similar.) > The arm64 implementation should be considered a proof of concept only. > The enablement of POE for in-kernel use is incomplete; in particular > POR_EL1 (pkey register) should be reset on exception entry and restored > on exception return. As in, make sure the loaded pkey isn't leaked into an exception handler? > # Open questions > > A few aspects in this RFC that are debatable and/or worth discussing: > > - There is currently no restriction on how kpkeys levels map to pkeys > permissions. A typical approach is to allocate one pkey per level and > make it writable at that level only. As the number of levels > increases, we may however run out of pkeys, especially on arm64 (just > 8 pkeys with POE). Depending on the use-cases, it may be acceptable to > use the same pkey for the data associated to multiple levels. > > Another potential concern is that a given piece of code may require > write access to multiple privileged pkeys. This could be addressed by > introducing a notion of hierarchy in trust levels, where Tn is able to > write to memory owned by Tm if n >= m, for instance. > > - kpkeys_set_level() and kpkeys_restore_pkey_reg() are not symmetric: > the former takes a kpkeys level and returns a pkey register value, to > be consumed by the latter. It would be more intuitive to manipulate > kpkeys levels only. However this assumes that there is a 1:1 mapping > between kpkeys levels and pkey register values, while in principle > the mapping is 1:n (certain pkeys may be used outside the kpkeys > framework). Is the "levels" nature of this related to how POE behaves? It sounds like there can only be 1 pkey active at a time (a role), rather than each pkey representing access to a specific set of pages (a key in a keyring), where many pkeys could be active at the same time. Am I understanding that correctly? > Any comment or feedback will be highly appreciated, be it on the > high-level approach or implementation choices! As hinted earlier with my QEMU question... what's the best way I can I test this myself? :) Thanks for working on this! Data-only attacks have been on the rise for a while now, and I'm excited to see some viable mitigations appearing. Yay! -Kees -- Kees Cook