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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 30 Aug 2017 09:20:25 -0500 From: Josh Poimboeuf <jpoimboe@...hat.com> To: Joe Lawrence <joe.lawrence@...hat.com> Cc: live-patching@...r.kernel.org, linux-kernel@...r.kernel.org, Jessica Yu <jeyu@...nel.org>, Jiri Kosina <jikos@...nel.org>, Miroslav Benes <mbenes@...e.cz>, Petr Mladek <pmladek@...e.com>, Chris J Arges <chris.j.arges@...onical.com> Subject: Re: [PATCH v4 1/3] livepatch: add (un)patch callbacks On Wed, Aug 30, 2017 at 09:27:16AM -0400, Joe Lawrence wrote: > > So instead of 'obj->pre_patch_callback_done', how about > > 'obj->callbacks_enabled'? > > > > It could be set in the following cases: > > > > a) if the object has a pre_patch callback, set obj->callbacks_enabled > > after the pre_patch callback succeeds; > > > > b) else, if the patch does *not* have a pre_patch callback, set > > obj->callbacks_enabled after klp_patch_object() succeeds. > > > > And the variable would need to be cleared after the post_unpatch > > callback was run. > > > > It's a bit complicated, but that seems to be the most logicial behavior > > as far as I can tell. > > > > Thoughts? > > What if we flip it around as "callbacks_disabled"? By default, kzalloc > would init as false. It would only be set to true if the pre-patch > callback is provided and if it returns failure. Would that reduce the > number of conditions when we need to set this var? Yeah, 'callbacks_disabled' sounds better. > Also, as you noted, I think it would need to reset/cleared after the > post-patch callback. (For the livepatch-already-loaded cases.) Since it can only be set when the pre-patch fails, I think it would only need to be cleared after post-unpatch? Or another alternative would be to unconditionally clear and/or set it in klp_pre_patch_callback() so that its previous value doesn't matter. -- Josh
Powered by blists - more mailing lists