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: Sat, 17 May 2014 09:10:17 +0200 (CEST) From: Jiri Kosina <jkosina@...e.cz> To: Steven Rostedt <rostedt@...dmis.org> cc: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>, Ingo Molnar <mingo@...nel.org>, Frederic Weisbecker <fweisbec@...il.com>, Josh Poimboeuf <jpoimboe@...hat.com>, Seth Jennings <sjenning@...hat.com>, Ingo Molnar <mingo@...hat.com>, Jiri Slaby <jslaby@...e.cz>, linux-kernel@...r.kernel.org, Peter Zijlstra <a.p.zijlstra@...llo.nl>, Andrew Morton <akpm@...ux-foundation.org>, Linus Torvalds <torvalds@...ux-foundation.org>, Thomas Gleixner <tglx@...utronix.de> Subject: Re: [RFC PATCH 0/2] kpatch: dynamic kernel patching On Fri, 16 May 2014, Steven Rostedt wrote: > Why I still favor the stop_machine approach, is because the method of > patching is a bit simpler that way. A "lazy" approach will be more > complex and more likely to be buggy. The thing I'm arguing here is not > the end result being a problem, but the implementation of the patching > itself causing bugs. Well, what can I say to this. 21 files changed, 594 insertions(+), 10 deletions(-) that's a complete implementation, including comments and some documentation. Yes, it still has TODOs (such as patching modules as they are modprobed, we're working on multi-arch support, etc), but it's more or less complete working x86 skeleton. > I rather have a "lazy" approach, I'm glad to hear that, thanks :) > but like ftrace and its breakpoint method, the stop_machine approach is > the simpler way to make sure the patching works before we try to > optimize it. I am still not convinced that it's more complex. It's actually lazy both in the way it performs patching and in implementation -- we basically set a flag, flip the switch, and let the universe converge to a new state by itself. It's basically hard to argue about level of bugginess when no actual bugs are being pointed out :) (well, yes, the kthreads stuff needs to be taken care of, but both kgraft and kpatch have similar issues there). Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists