linux-kernel - [PATCH v1 3/3] module: pre-test setting ro_after

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <84c4caf2fbb71fa1699ee24d5b6df548d7f3bb08.1733427536.git.christophe.leroy@csgroup.eu>
Date: Thu,  5 Dec 2024 20:46:17 +0100
From: Christophe Leroy <christophe.leroy@...roup.eu>
To: Luis Chamberlain <mcgrof@...nel.org>,
	Petr Pavlu <petr.pavlu@...e.com>,
	Sami Tolvanen <samitolvanen@...gle.com>,
	Daniel Gomez <da.gomez@...sung.com>,
	Kees Cook <kees@...nel.org>,
	linux-modules@...r.kernel.org
Cc: Christophe Leroy <christophe.leroy@...roup.eu>,
	linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>
Subject: [PATCH v1 3/3] module: pre-test setting ro_after_init data read-only

To be on the safe side, try to set ro_after_init data section readonly
at the same time as rodata. If it fails it will likely fail again
later so let's cancel module loading while we still can do it.
If it doesn't fail, put it back to read-write, continue module loading
and cross fingers so that it still works after module init.

In practice, if it worked once it will work twice:
- On some architecture like powerpc it works on some memory areas and
works on others. If you apply it several times to the same area, either
it always works or it always fails
- On some architecture like ARM, that may apply splitting big pages
into smaller ones, that is what can fails, but once it successed the
pages will remain split so there's no reason to fail on pass two if it
worked on pass one.

Then it should in principle never fail so add a WARN_ON_ONCE() to get
a big fat warning in case it happens anyway. For systems that sets
panic-on-warn, such systems usely care about security and don't want
vulnerable systems, so an implied panic is worth it in that case.

Signed-off-by: Christophe Leroy <christophe.leroy@...roup.eu>
---
v1: Expanded the commit message based on feedback from RFC series
---
 kernel/module/main.c       | 2 +-
 kernel/module/strict_rwx.c | 5 ++++-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/kernel/module/main.c b/kernel/module/main.c
index 5f922e563fc3..634a4a2aaf8c 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -2674,7 +2674,7 @@ 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)
+	if (WARN_ON_ONCE(ret))
 		pr_warn("%s: module_enable_rodata_ro_after_init() returned %d, "
 			"ro_after_init data might still be writable\n",
 			mod->name, ret);
diff --git a/kernel/module/strict_rwx.c b/kernel/module/strict_rwx.c
index 74834ba15615..1434c48c52ab 100644
--- a/kernel/module/strict_rwx.c
+++ b/kernel/module/strict_rwx.c
@@ -61,7 +61,10 @@ int module_enable_rodata_ro(const struct module *mod)
 	if (ret)
 		return ret;
 
-	return 0;
+	ret = module_set_memory(mod, MOD_RO_AFTER_INIT, set_memory_ro);
+	if (ret)
+		return ret;
+	return module_set_memory(mod, MOD_RO_AFTER_INIT, set_memory_rw);
 }
 
 int module_enable_rodata_ro_after_init(const struct module *mod)
-- 
2.47.0