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
| ||
|
Date: Fri, 27 Mar 2020 13:04:44 +0100 (CET) From: Miroslav Benes <mbenes@...e.cz> To: Jessica Yu <jeyu@...nel.org> cc: Peter Zijlstra <peterz@...radead.org>, x86@...nel.org, linux-kernel@...r.kernel.org, rostedt@...dmis.org, mhiramat@...nel.org, bristot@...hat.com, jbaron@...mai.com, torvalds@...ux-foundation.org, tglx@...utronix.de, mingo@...nel.org, namit@...are.com, hpa@...or.com, luto@...nel.org, ard.biesheuvel@...aro.org, jpoimboe@...hat.com Subject: Re: [RESEND][PATCH v3 03/17] module: Properly propagate MODULE_STATE_COMING failure On Wed, 25 Mar 2020, Jessica Yu wrote: > +++ Peter Zijlstra [24/03/20 14:56 +0100]: > >Now that notifiers got unbroken; use the proper interface to handle > >notifier errors and propagate them. > > > >There were already MODULE_STATE_COMING notifiers that failed; notably: > > > > - jump_label_module_notifier() > > - tracepoint_module_notify() > > - bpf_event_notify() > > > >By propagating this error, we fix those users. > > > >Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org> > >Cc: jeyu@...nel.org > >--- > > kernel/module.c | 10 +++++++--- > > 1 file changed, 7 insertions(+), 3 deletions(-) > > > >--- a/kernel/module.c > >+++ b/kernel/module.c > >@@ -3751,9 +3751,13 @@ static int prepare_coming_module(struct > > if (err) > > return err; > > > >- blocking_notifier_call_chain(&module_notify_list, > >- MODULE_STATE_COMING, mod); > >- return 0; > >+ err = blocking_notifier_call_chain_robust(&module_notify_list, > >+ MODULE_STATE_COMING, MODULE_STATE_GOING, mod); > >+ err = notifier_to_errno(err); > >+ if (err) > >+ klp_module_going(mod); > >+ > >+ return err; > > } > > > > static int unknown_module_param_cb(char *param, char *val, const char > > *modname, > > > > This looks fine to me - klp_module_going() is only called after > successful klp_module_coming(), and klp_module_going() is fine with > mod->state still being MODULE_STATE_COMING here. Would be good to have > livepatch folks double check. Yes, it is ok. > Which reminds me - Miroslav had pointed > out in the past that if there is an error when calling the COMING > notifiers, the GOING notifiers will be called while the mod->state is > still MODULE_STATE_COMING. I've briefly looked through all the module > notifiers and it looks like nobody is looking at mod->state directly > at least. Thanks for double-checking. I triple-checked and yes, it should be fine. All module notifiers check the value from the function parameter and not mod->state directly. Reviewed-by: Miroslav Benes <mbenes@...e.cz> M
Powered by blists - more mailing lists