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 16DD1C28B30 for ; Wed, 12 Mar 2025 15:45:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 37BA2280003; Wed, 12 Mar 2025 11:45:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 328E8280001; Wed, 12 Mar 2025 11:45:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1F1FB280003; Wed, 12 Mar 2025 11:45:32 -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 023DD280001 for ; Wed, 12 Mar 2025 11:45:31 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id AEA8056E48 for ; Wed, 12 Mar 2025 15:45:33 +0000 (UTC) X-FDA: 83213323746.25.BC5B005 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf21.hostedemail.com (Postfix) with ESMTP id C331F1C0019 for ; Wed, 12 Mar 2025 15:45:30 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=olXtCEfp; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=dLQuRPBm; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=aVMdF2mR; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=AesxH4bi; dmarc=none; spf=pass (imf21.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741794331; a=rsa-sha256; cv=none; b=IktVbFpoHNwveP5UywX3beZ/9alIzlr7BNqrpUaXCrZmfgMiQn98lMNYxPzuNEtMDV0V3V AY6TxsXHKWnMDeEd3ebbKfBsUZZhjY5vujMoLtewxjrGo7hrfY5h7gWL/ZTbJ8kUzOSp/z i4B/2/xmqQWIkdmqnUyAyHsn0WgPwwc= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=olXtCEfp; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=dLQuRPBm; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=aVMdF2mR; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=AesxH4bi; dmarc=none; spf=pass (imf21.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741794331; 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=N3XwIXcy6Q4Evz4UAeNpQ3991S5L6PKz3XLAG/glkfk=; b=0qcNiOF5zPY0ZxaP/srvWwH0XpGIBMJo0K7gsJU0t/hyPtxYXDuHqv67YEnUqTuM4SHkdf BXwdcVp6xEsjHbdpnGjCwiQ6U0sNmNWN/4BJLrf/q+aS/j9rn0rxU9WKm5yxbRrDk/nNpl XyzkUPFHqOpUzWv6LprdNSaf0lvygDo= Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id E80A51F7F8; Wed, 12 Mar 2025 15:45:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1741794328; h=from:from:reply-to: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; bh=N3XwIXcy6Q4Evz4UAeNpQ3991S5L6PKz3XLAG/glkfk=; b=olXtCEfpeSorEzV45WKrZ2r2Ouq4IxAjOk3zB/seWjY8MIBeysk4Tqq8JbrJ5gfWM9uUKQ +CmhmzY7BFVMb+eIyYoRgj9FAAfhqXDVhX0c4sChXiFPF2oUf9EC91V5V+gxBDOoHBz84X 1WfuaF/xvaFhCUHKQnkTTaGkvPg0f8Q= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1741794328; h=from:from:reply-to: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; bh=N3XwIXcy6Q4Evz4UAeNpQ3991S5L6PKz3XLAG/glkfk=; b=dLQuRPBmpsKyH26izDH0fetWpGa9I7gVDc6LEc5h4vneALykUgxmjddxucFQ9vw3zKZxEt 0DK+1LGQFPxoOwCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1741794324; h=from:from:reply-to: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; bh=N3XwIXcy6Q4Evz4UAeNpQ3991S5L6PKz3XLAG/glkfk=; b=aVMdF2mRQrNVZet/OVwNGpXxby1ZBuUMaynUnBbUhe/aJQXEpqhlFKKHwlqLls2XWbz5Z9 nJlPPBKUXjvtN1eU2JZzI1X4bSazeWe2wi4ykhc7jFADFggXcqoaABw4+eG5zIX3xbK46l xUB8v7JLQ3FEqXUP/pfzG86bctjl+/M= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1741794324; h=from:from:reply-to: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; bh=N3XwIXcy6Q4Evz4UAeNpQ3991S5L6PKz3XLAG/glkfk=; b=AesxH4biFaIDiLv4SIhg0jG3C+ZftOWnl6Aka+Kfgl98OrHaHD0OTvuBp2Ahri/nclt/tf kaAwNxF9M9199DCQ== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id C947F1377F; Wed, 12 Mar 2025 15:45:24 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id P4LHMBSs0WfKEgAAD6G6ig (envelope-from ); Wed, 12 Mar 2025 15:45:24 +0000 Message-ID: Date: Wed, 12 Mar 2025 16:45:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] module: Taint the kernel when write-protecting ro_after_init fails Content-Language: en-US To: Luis Chamberlain , Petr Pavlu Cc: Sami Tolvanen , Daniel Gomez , Kees Cook , Petr Mladek , Jani Nikula , Andrew Morton , John Ogness , Greg Kroah-Hartman , linux-mm , linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org References: <20250306103712.29549-1-petr.pavlu@suse.com> From: Vlastimil Babka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Queue-Id: C331F1C0019 X-Stat-Signature: o3g4s9th8gx69md7esbtgrteohswg6p5 X-Rspamd-Server: rspam06 X-HE-Tag: 1741794330-259031 X-HE-Meta: U2FsdGVkX19gqLiJpJvXeh+vy3g7SiIWeWTdgK3RV5xFW/9oNAtJTOaCmQ3VSvGQ8XwV5r+oM/nBWgDe7xKnBcrXIEclAhTwPKxFbyvwGsj7qI+3PHtnn9hczO/2lRBzrQ1w7VRxOzNu8IoBgLXYsBxgbLOHdF7jov/qEADnvnGnfgadINOnqKhX5lm60dX/uEVCAnd2AwpCfb0eWqcEGDY3ruB1dQuiEaTiWElaSXET3mCnNO+npR0AeZx/2xPyxG0JWihtpKuEocSCBxe/o7/8aWJXIBqqYcOLxRe1ez07hk5KdkDGF2nGovrOU06vauheZfgl/ZeX4fz3yGyMrjJa4v92Y2SBrtBykQkCf7RbYQoBLFSSP+8/pDjL+YkcKfja9EMdKEL7EV5ZDAVEkQc2+7QX6WJ0+Kf+ZO/KPj5y2YI1NhdkaMpDV7vKWm7FLQoRkNqJLblM5m6Zk50+HPN/Wr7Kw+EjCp6v0363f8tryXxzfB+474XnEED169khy3IxImEZ78JYobxpSkYDqxKCzpkNYV3pgOHs3RBponfHQvEZWAS9J+vLE1RrnNTb2Oebr1TdFU51/9j86INxDDijd6BRYD7lZ/ItEcCQRraPAwsfum95+MpAT3FFGlicrwpaNS3dbzRR09QVKYu9r2xa1y/IPr63JzFrBlHYFtP2CZZzmE4LrzRTITn41eXs7f4zypbuPdFSTfy6INfwvKiUoRYXG227yheeNI+yEhJCLYoP235BTr6VazplG9tP1awCsfohbg7kzT5erAcOBGtSE+MyhZRgbgB5Lx5BwrqT301enqPqw+E38ooC3njN0Fl2uleH0ib3auzxpFtHJrwtiEqfX/SOB1O6UAIvVwYe38+hvYBCakm4TD2ZqtdJ9h0SNM6BBfwaLSn1CMaL5M74JWabuHAwrr1MT7by1FGCd/2mDD0rpAhaUDcGHwVow8DMfxvhFR4GLU434C5 Ln9sLw1F EPSzhVe2t0xNXzS3aWuAsqvYrauFAE1jKxMYLaq/FDponbtW5zH4tY7zBoFfp05YsQPKP4WhKRqvept/ti4UBfcqWINpASCq9Cra+U1GdhMosW5lIyggU+u4WaPxyNv245/hubiT4K1ibkNfue6rnK8OFpNw/4HQyD+8lr/TjXnceFpcbwxKN31mq/yZi80A+fkKYohCP0zobVDXES6kMS74DrGnUHZyN8J34tpkU7ddivH7+aG8TkdZI7C+D8fbeDglk4HrD7d/5xOpueyoMU2QyPL/B/O+0aLX4uMGZi4skH/PgJtDMsQybUB0Y5PkPfe8dBcKSXczLJiHFDLIlTg8kFJvRsht6+M/soymNgmF7AMDwJPW1RC5PEOq89copI4nj5c/Pmv8mOMonoM/W7JsB6DdM4VI3Uy2R 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 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? > Luis >