+++ Kees Cook [21/07/16 16:03 -0700]:
On Wed, Jun 29, 2016 at 9:56 PM, Rusty Russell <rusty@xxxxxxxxxxxxxxx> wrote:
Jessica Yu <jeyu@xxxxxxxxxx> writes:
+++ Rusty Russell [29/06/16 10:38 +0930]:
Jessica Yu <jeyu@xxxxxxxxxx> writes:
Add ro_after_init support for modules by adding a new page-aligned section
in the module layout (after rodata) for ro_after_init data and enabling RO
protection for that section after module init runs.
Signed-off-by: Jessica Yu <jeyu@xxxxxxxxxx>
I would prefer a "bool after_init" flag to module_enable_ro(). It's
more explicit.
Sure thing, I was just initially worried about the
module_{enable,disable}_ro() asymmetry. :)
Yes, but I think compile-time-analyzable behaviour beats
runtime-analyzable behaviour for clarity.
Exposing the flags via uapi looks like a wart, but it's kind of a
feature, since we don't *unset* it in any section; userspace may want to
know about it.
Hm, I'm still unsure about this. I'm starting to think it might be a
bit overkill to expose SHF_RO_AFTER_INIT through uapi (although that
is where all the other SHF_* flags are defined) SHF_RO_AFTER_INIT
would technically be used only internally in the kernel (i.e. module
loader), and it'd also be considered a non-standard flag, using a bit
from SHF_MASKOS (OS-specific range). What do you think?
Some arch *could* use it by setting the flag in a section in their
module I think; we don't stop them. Since the other flags are there,
I'd leave it.
We don't expose the flags via sysfs, though, so that's the only
exposure.
What's the state of this series? I'd love it if the functionality
could land for v4.8...
Hi Kees,
Sorry for the delay! Have been busier than usual lately. I'll be able
to get v2 out tomorrow.
Thanks!
Jessica
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
