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: Thu, 5 May 2016 12:21:59 +0200 From: Petr Mladek <pmladek@...e.com> To: Josh Poimboeuf <jpoimboe@...hat.com> Cc: Jessica Yu <jeyu@...hat.com>, Jiri Kosina <jikos@...nel.org>, Miroslav Benes <mbenes@...e.cz>, Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>, Michael Ellerman <mpe@...erman.id.au>, Heiko Carstens <heiko.carstens@...ibm.com>, live-patching@...r.kernel.org, linux-kernel@...r.kernel.org, x86@...nel.org, linuxppc-dev@...ts.ozlabs.org, linux-s390@...r.kernel.org, Vojtech Pavlik <vojtech@...e.com>, Jiri Slaby <jslaby@...e.cz>, Chris J Arges <chris.j.arges@...onical.com>, Andy Lutomirski <luto@...nel.org> Subject: Re: barriers: was: [RFC PATCH v2 17/18] livepatch: change to a per-task consistency model On Wed 2016-05-04 12:02:36, Josh Poimboeuf wrote: > On Wed, May 04, 2016 at 02:39:40PM +0200, Petr Mladek wrote: > > On Thu 2016-04-28 15:44:48, Josh Poimboeuf wrote: > > > Change livepatch to use a basic per-task consistency model. This is the > > > foundation which will eventually enable us to patch those ~10% of > > > security patches which change function or data semantics. This is the > > > biggest remaining piece needed to make livepatch more generally useful. > > > > I spent a lot of time with checking the memory barriers. It seems that > > they are basically correct. Let me use my own words to show how > > I understand it. I hope that it will help others with review. > > [...snip a ton of useful comments...] > > Thanks, this will help a lot! I'll try to incorporate your barrier > comments into the code. Thanks a lot. > I also agree that kpatch_patch_task() is poorly named. I was trying to > make it clear to external callers that "hey, the task is getting patched > now!", but it's internally inconsistent with livepatch code because we > make a distinction between patching and unpatching. > > Maybe I'll do: > > klp_update_task_patch_state() I like it. It is long but it well describes the purpose. Livepatch is using many state variables: + global: klp_transition_patch, klp_target_state + per task specific: TIF_PENDING_PATCH, patch_state + per each new function: transition, patched + per old function: func_stack + per object: patched, loaded + per patch: enabled The dependency between them and the workflow is important to create a mental picture about the Livepatching. Good names help with it. Best Regards, Petr
Powered by blists - more mailing lists