lkml.org 
[lkml]   [2019]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v4 15/16] module: Move where we mark modules RO,X
    On Fri, Oct 18, 2019 at 09:35:40AM +0200, Peter Zijlstra wrote:
    > Now that set_all_modules_text_*() is gone, nothing depends on the
    > relation between ->state = COMING and the protection state anymore.
    > This enables moving the protection changes later, such that the COMING
    > notifier callbacks can more easily modify the text.
    >
    > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    > Cc: Jessica Yu <jeyu@kernel.org>
    > ---
    > kernel/module.c | 8 ++++----
    > 1 file changed, 4 insertions(+), 4 deletions(-)
    >
    > --- a/kernel/module.c
    > +++ b/kernel/module.c
    > @@ -3683,10 +3683,6 @@ static int complete_formation(struct mod
    > /* This relies on module_mutex for list integrity. */
    > module_bug_finalize(info->hdr, info->sechdrs, mod);
    >
    > - module_enable_ro(mod, false);
    > - module_enable_nx(mod);
    > - module_enable_x(mod);
    > -
    > /* Mark state as coming so strong_try_module_get() ignores us,
    > * but kallsyms etc. can see us. */
    > mod->state = MODULE_STATE_COMING;
    > @@ -3852,6 +3848,10 @@ static int load_module(struct load_info
    > if (err)
    > goto bug_cleanup;
    >
    > + module_enable_ro(mod, false);
    > + module_enable_nx(mod);
    > + module_enable_x(mod);
    > +
    > /* Module is ready to execute: parsing args may do that. */
    > after_dashes = parse_args(mod->name, mod->args, mod->kp, mod->num_kp,
    > -32768, 32767, mod,

    [ Sorry if this was already discussed, I still have a large backlog. ]

    Doesn't livepatch code also need to be modified? We have:

    prepare_coming_module()
    klp_module_coming()
    klp_init_object_loaded()
    module_disable_ro()
    ...
    module_enable_ro()

    which is done right before the above patch does module_enable_ro().

    We could remove the disable-RO from that case, though we'd still need it
    for another case (late module patching).

    --
    Josh

    \
     
     \ /
      Last update: 2019-10-21 15:54    [W:3.796 / U:0.116 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site