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, 21 Feb 2015 19:18:52 +0100 From: Ingo Molnar <mingo@...nel.org> To: Vojtech Pavlik <vojtech@...e.com> Cc: Jiri Kosina <jkosina@...e.cz>, Josh Poimboeuf <jpoimboe@...hat.com>, Peter Zijlstra <peterz@...radead.org>, Andrew Morton <akpm@...ux-foundation.org>, Ingo Molnar <mingo@...hat.com>, Seth Jennings <sjenning@...hat.com>, linux-kernel@...r.kernel.org, Linus Torvalds <torvalds@...ux-foundation.org> Subject: Re: live patching design (was: Re: [PATCH 1/3] sched: add sched_task_call()) * Vojtech Pavlik <vojtech@...e.com> wrote: > On Fri, Feb 20, 2015 at 08:49:01PM +0100, Ingo Molnar wrote: > > > > ... the choice the sysadmins have here is either have > > > the system running in an intermediate state, or have > > > the system completely dead for the *same time*. > > > Because to finish the transition successfully, all > > > the tasks have to be woken up in any case. > > > > That statement is false: an 'intermediate state' system > > where 'new' tasks are still running is still running > > and will interfere with the resolution of 'old' tasks. > > Can you suggest a way how they would interfere? The > transition happens on entering or returning from a > syscall, there is no influence between individual tasks. Well, a 'new' task does not stop executing after returning from the syscall, right? If it's stopped (until all patching is totally complete) then you are right and I concede your point. If it's allowed to continue its workload then my point stands: subsequent execution of 'new' tasks can interfere with, slow down, interact with 'old' tasks trying to get patched. > > I think you misunderstood: the 'simple' method I > > outlined does not just 'synchronize', it actually > > executes the live patching atomically, once all tasks > > are gathered and we know they are _all_ in a safe > > state. > > The 'simple' method has to catch and freeze all tasks one > by one in syscall entry/exit, at the kernel/userspace > boundary, until all are frozen and then patch the system > atomically. Correct. > This means that each and every sleeping task in the > system has to be woken up in some way (sending a signal > ...) to exit from a syscall it is sleeping in. Same for > CPU hogs. All kernel threads need to be parked. Yes - although I'd not use signals for this, signals have side effects - but yes, something functionally equivalent. > This is exactly what you need to do for kGraft to > complete patching. My understanding of kGraft is that by default you allow tasks to continue 'in the new universe' after they are patched. Has this changed or have I misunderstood the concept? Thanks, Ingo -- 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