| Message ID | 84c4caf2fbb71fa1699ee24d5b6df548d7f3bb08.1733427536.git.christophe.leroy@csgroup.eu (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | module: Don't fail module loading when setting ro_after_init section RO failed | expand |
| Context | Check | Description |
|---|---|---|
| mcgrof/vmtest-modules-next-PR | success | PR summary |
| mcgrof/vmtest-modules-next-VM_Test-1 | success | Logs for Run CI tests |
| mcgrof/vmtest-modules-next-VM_Test-0 | success | Logs for Run CI tests |
| mcgrof/vmtest-modules-next-VM_Test-4 | success | Logs for setup / Setup kdevops environment |
| mcgrof/vmtest-modules-next-VM_Test-5 | success | Logs for setup / Setup kdevops environment |
| mcgrof/vmtest-modules-next-VM_Test-3 | success | Logs for cleanup / Archive results and cleanup |
| mcgrof/vmtest-modules-next-VM_Test-2 | success | Logs for cleanup / Archive results and cleanup |
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)
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@csgroup.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(-)