linux-kernel - Re: live patching design (was: Re: [PATCH 1/3] sched: add sched_task

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 22 Feb 2015 20:18:06 +0100 (CET)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Ingo Molnar <mingo@...nel.org>
cc:	Josh Poimboeuf <jpoimboe@...hat.com>,
	Vojtech Pavlik <vojtech@...e.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>,
	live-patching@...r.kernel.org
Subject: Re: live patching design (was: Re: [PATCH 1/3] sched: add
 sched_task_call())


[ live-patching@ ML added to CC here as well ]

On Sun, 22 Feb 2015, Ingo Molnar wrote:

> > BTW how exactly do you envision this will work? Do I understand your 
> > proposal correctly that EINTR will be "handled" somewhere in the "live 
> > patching special signal handler" and then have the interrupted syscall 
> > restarted?
> 
> If you want to think about it in signal handling terms then it's a new 
> automatic in-kernel handler, which does not actually return back to 
> user-mode at all.
> 
> We can do it via the signals machinery (mainly to reuse all the existing 
> signal_pending() code in various syscalls), or via new TIF flags like 
> the user work machinery: the principle is the same: interrupt out of 
> syscall functions into a central place and restart them, and return to 
> user-space later on as if a single call had been performed.
> 
> This necessarily means some changes to syscalls, but not insurmountable 
> ones - and checkpoint/restore support would want to have similar changes 
> in any case so we can hit two birds with the same stone.

Understood. I think this by itself really would be a huge improvement on 
how to force tasks to converge to the new universe without confusing the 
userspace via artificial signals (i.e. even with the lazy migration 
aproaches, without full serialization checkpoint). As I said yesterday, I 
am pretty sure we'll experiment with this in kgraft. Thanks for bringing 
this idea up,

-- 
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/