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 5BB8AC28B28 for ; Wed, 12 Mar 2025 17:38:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C5D9C280003; Wed, 12 Mar 2025 13:38:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C0DC6280001; Wed, 12 Mar 2025 13:38:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AD531280003; Wed, 12 Mar 2025 13:38:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 8DEDC280001 for ; Wed, 12 Mar 2025 13:38:47 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 1630D1A14D8 for ; Wed, 12 Mar 2025 17:38:48 +0000 (UTC) X-FDA: 83213609136.03.51A7C68 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf27.hostedemail.com (Postfix) with ESMTP id 6C18040019 for ; Wed, 12 Mar 2025 17:38:46 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="QYT/nnLm"; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf27.hostedemail.com: domain of mcgrof@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=mcgrof@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741801126; a=rsa-sha256; cv=none; b=rURQNHXe9in/vdC+4gWgW38K42BQfM2KEc5ZvPAf7c7ZW7uC6UgsF1KYDXWs4TUO5O0iT/ gdio29X4DcRYZEaovPfXxjVLsFalYTjMCEz8Y3Hva8tZI9ZHDdrnID5GKJta3grics/CRB z41n/Kex7wQC0WBkPBFQ64NgdQS7nPo= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="QYT/nnLm"; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf27.hostedemail.com: domain of mcgrof@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=mcgrof@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741801126; 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=lRLFuChwG9xU9brnHY6fvXnSWhNrAganPwSl+8o9DZA=; b=Ga4wTOqFROAr0m139ptVh9Oyf266wQ4XMWqI52WO/mt3A7SYV///hn2fSiZLAmRV0ltnNr xnkXV72gWzh4PeRZcfW7XRCFOIXsnoSGgehA75UT7J4hzUtKVbz7HIiqVCfXR+ksxOFj1l WZ3P89YM1ulwUx73nwpgee6YHuF0qyY= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id B87AC5C135D; Wed, 12 Mar 2025 17:36:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DC032C4CEDD; Wed, 12 Mar 2025 17:38:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1741801125; bh=3IQCekR2kO8T0WEg1CoEHBcqTm/HWqSnX3xaIwcLORo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=QYT/nnLm8ww6q2w69OobpziCjXlERE6IOERYBSScUWRxMSFVASe0mELVJ4JcytYGb S6fg2Byp1oA5+rgyZV49iB0a1DUtPvO2RMPMT5+eRml3IhEJzfzgky850WtS+j3GLU zLFKEMTVlkuJCDUm/T+fM/spAETiMyhqdovZ1VOw92jklTu0uOQMjhLebcFb1fWFZ7 pZpjGTjkuCxdlemUI67CwDME31GpLkxFbXzcp7RE2dUc7CG665aMGlZkpA/lE9AiF3 rjxcbTpyUz8UCIOwMJFUP+6Oo6rcG/WyAvQGBpIYETHdS2jKBhUM7tXElKHEwCGEW0 NWH6iBwWv7sWw== Date: Wed, 12 Mar 2025 10:38:43 -0700 From: Luis Chamberlain To: Kees Cook Cc: Vlastimil Babka , Petr Pavlu , Sami Tolvanen , Daniel Gomez , Petr Mladek , Jani Nikula , Andrew Morton , John Ogness , Greg Kroah-Hartman , linux-mm , linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] module: Taint the kernel when write-protecting ro_after_init fails Message-ID: References: <20250306103712.29549-1-petr.pavlu@suse.com> <202503120923.199D458CB@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202503120923.199D458CB@keescook> X-Stat-Signature: k163u9ggseuba1wx84tg5fnrcqp1oen8 X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 6C18040019 X-Rspam-User: X-HE-Tag: 1741801126-277946 X-HE-Meta: U2FsdGVkX18N/+d09MBiRcUSkdJVuOoq/p+u/TOUhqYtH6B/r9fHJ9KjqnFLsQe+FJracfn72ktrFrdJ2yQwkCCEoVlkhQxMmJX1iDC9Z0ZugqgpT42rbvtIbqb00iXMzGr+Nk73yLm15BkswAmWCCI2NC4xwrZrsTPf/zsR0qsghfuphVztDNs630QmDT8Nrt+Tf5WB+KS1GmgvSeLCOZHirVDfw+K364CqOSNx+3aFXU5KnkV3cD1t9OtXu/cOORjM+3n0z9PukLdR6f3PGIFi7y3JpvRMUVkzVygCL+y9T/1Ry2d+3lCG/DW4zWz+7CklhzhrTC2ciFPYGVLXJEZub0tBJYHvK8SSPCK/0FGsg+JwFkPMO+ZnV42RFUryuxSMsKZTUjCNO5zfBX0Zji4h5wzy81BPnmaLxbLdIlXXYFAo+BTH5zWo1zQw289P6bQhZJoP0168KJdXy2jpEa0PNc4J+ZOoR9BhQmxYR4P7pZlvUv3e5o5YywXdv8f/azrKO9LVjUnFoNnHKfPbfSBCnlAXnbDuEa2h62KR7MdkBqqNKuXE5G3CUQTYICnJBox1m7gQabdvSuvkPVkgb2sc0pDfuy9RwCpAnTBkdcjDYTPZZ5D1fBkqs8brAF+vVihPgDRU6xkQrPiGNJR2zuBHVDJabIJh04Zm6w45K8x4s/laRarw9F0GNUwBe9DJsPDSG5uZiVgB3CHAoQlhTzWuKwbldStu0Z3uvWWlGnwBzG78QkHGqy0/ZsGITYFZkNjYNtQLn1ozN6I+W76FD7F5IXMl7gybIQpxZS01ofAIY5OzWopiCieKYCoTxHQFJYuXcsMMzKL39QBNX9PY2uKA0Sq79DtpcTPzCXowiyN6IV2KcZ9DL3d2J5MOfDTIt6Wk1fK4rh/Hj17kmny4dp9Td6JAg0cl8TVqbPj+0nbNkvpSwUjyOKxTfEGZCB+9GSaiAl+QN36+x92A0Kd j06zRK+r jw8x9F1/nXoO/gLp+kv8Fz98DZ4g+k9ifumF7/VnE9gwX95iXXo/SEL9UnnqOg4SKDFv75u978UwvlUqllvEf2beOKZSwdgfr2e0b5q/38Y+WUaA19u/PXkjb6a1BcOzdmuOXpODGjOxwwQZgjfF9Ti1IcWtFOq8s/Q5q1EeYtZEauUrgUj7yaQgiEyeiV5FU8b6SWvK3Tqn/6/XtybulPiCJ7xm9BLhc8zNzsUir+lytKIgIPWiGqBsZo4vGSRNEGp6UtDw3fYs3+B2lGvspfj75yzl3VGxu/f+WNGv7jukjduGUcDQEBQHflbc2UN8BU/hsCneG/VA13kpYbjlYPw0RFAhtEnb9U/XZ7Tobj3e4R6TLcZcY82XNHg== 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 Wed, Mar 12, 2025 at 09:30:28AM -0700, Kees Cook wrote: > On Wed, Mar 12, 2025 at 04:45:24PM +0100, Vlastimil Babka wrote: > > On 3/6/25 17:57, Luis Chamberlain wrote: > > > + linux-mm since we're adding TAINT_BAD_PAGE > > > > > > On Thu, Mar 06, 2025 at 11:36:55AM +0100, Petr Pavlu wrote: > > >> In the unlikely case that setting ro_after_init data to read-only fails, it > > >> is too late to cancel loading of the module. The loader then issues only > > >> a warning about the situation. Given that this reduces the kernel's > > >> protection, it was suggested to make the failure more visible by tainting > > >> the kernel. > > >> > > >> Allow TAINT_BAD_PAGE to be set per-module and use it in this case. The flag > > >> is set in similar situations and has the following description in > > >> Documentation/admin-guide/tainted-kernels.rst: "bad page referenced or some > > >> unexpected page flags". > > >> > > >> Adjust the warning that reports the failure to avoid references to internal > > >> functions and to add information about the kernel being tainted, both to > > >> match the style of other messages in the file. Additionally, merge the > > >> message on a single line because checkpatch.pl recommends that for the > > >> ability to grep for the string. > > >> > > >> Suggested-by: Kees Cook > > >> Signed-off-by: Petr Pavlu > > >> --- > > >> I opted to use TAINT_BAD_PAGE for now because it seemed unnecessary to me > > >> to introduce a new flag only for this specific case. However, if we end up > > >> similarly checking set_memory_*() in the boot context, a separate flag > > >> would be probably better. > > >> --- > > >> kernel/module/main.c | 7 ++++--- > > >> kernel/panic.c | 2 +- > > >> 2 files changed, 5 insertions(+), 4 deletions(-) > > >> > > >> diff --git a/kernel/module/main.c b/kernel/module/main.c > > >> index 1fb9ad289a6f..8f424a107b92 100644 > > >> --- a/kernel/module/main.c > > >> +++ b/kernel/module/main.c > > >> @@ -3030,10 +3030,11 @@ static noinline int do_init_module(struct module *mod) > > >> rcu_assign_pointer(mod->kallsyms, &mod->core_kallsyms); > > >> #endif > > >> ret = module_enable_rodata_ro_after_init(mod); > > >> - if (ret) > > >> - pr_warn("%s: module_enable_rodata_ro_after_init() returned %d, " > > >> - "ro_after_init data might still be writable\n", > > >> + if (ret) { > > >> + pr_warn("%s: write-protecting ro_after_init data failed with %d, the data might still be writable - tainting kernel\n", > > >> mod->name, ret); > > >> + add_taint_module(mod, TAINT_BAD_PAGE, LOCKDEP_STILL_OK); > > >> + } > > >> > > >> mod_tree_remove_init(mod); > > >> module_arch_freeing_init(mod); > > >> diff --git a/kernel/panic.c b/kernel/panic.c > > >> index d8635d5cecb2..794c443bfb5c 100644 > > >> --- a/kernel/panic.c > > >> +++ b/kernel/panic.c > > >> @@ -497,7 +497,7 @@ const struct taint_flag taint_flags[TAINT_FLAGS_COUNT] = { > > >> TAINT_FLAG(CPU_OUT_OF_SPEC, 'S', ' ', false), > > >> TAINT_FLAG(FORCED_RMMOD, 'R', ' ', false), > > >> TAINT_FLAG(MACHINE_CHECK, 'M', ' ', false), > > >> - TAINT_FLAG(BAD_PAGE, 'B', ' ', false), > > >> + TAINT_FLAG(BAD_PAGE, 'B', ' ', true), > > >> TAINT_FLAG(USER, 'U', ' ', false), > > >> TAINT_FLAG(DIE, 'D', ' ', false), > > >> TAINT_FLAG(OVERRIDDEN_ACPI_TABLE, 'A', ' ', false), > > > > > > Reviewed-by: Luis Chamberlain > > > > > > For our needs this makes sense, however I am curious if TAINT_BAD_PAGE > > > is too broadly generic, and also if we're going to add it, if there are > > > other mm uses for such a thing. > > > > I'm not sure BAD_PAGE is a good fit. If there was a new flag that meant "a > > hardening measure failed", would that have other possible uses? The > > semantics would be that the kernel self-protection was weakened wrt > > expectations, even if not yet a corruption due to attack would be detected. > > Some admins could opt-in to panic in such case anyway, etc. Any other > > hardening features where such "failure to harden" is possible and could use > > this too? Kees? > > Yeah, it could certainly be used. The direction the hardening stuff has > taken is to use WARN() (as Linus requires no direct BUG() usage), and to > recommend that end users tune their warn_limit sysctl as needed. > > Being able to TAINT might be useful, but I don't have any places that > immediately come to mind that seem appropriate for it (besides this > case). Hm, well, maybe in the case of a W^X test failure? (I note that > this is also a "safe memory permission" failure...) > > How about TAINT_WEAKENED_PROTECTION ? Or something that carries that > idea? It's different, but hw poison [0] already has policies for running into poisoned pages through MCA recovery, there are a few sysctl knobs to tune this, for example vm.memory_failure_recovery set to 0 will panic on a hw poison page. A hw poison event without a panic seems like a possible use case for such a taint TAINT_WEAKENED_PROTECTION? [0] https://github.com/torvalds/linux/blob/master/Documentation/mm/hwpoison.rst Luis