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:	Mon, 23 Feb 2015 13:43:53 +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())

On Sat, 21 Feb 2015, Ingo Molnar wrote:

> (It does have some other requirements, such as making all 
> syscalls interruptible to a 'special' signalling method 
> that only live patching triggers - even syscalls that are 
> under the normal ABI uninterruptible, such as sys_sync().)

BTW I didn't really understand this -- could you please elaborate what 
exactly do you propose to do here in your "simplified" patching method 
(i.e. serializing everybody at the kernel boundary) for 
TASK_UNINTERRUPTIBLE processess?

That actually seems to be the most crucial problem to me in this respect. 
Other things are rather implementation details; no matter whether we are 
sending normal SIGCONT or SIGPATCHING with special semantics you have 
described above, at the end of the day we end up calling kick_process() 
for the task in question, and that makes both interruptible sleepers and 
CPU hogs go through the "checkpoint". SIGPATCHING would then be "just" an 
improvement of this, making sure that EINTR doesn't spuriously get leaked 
to userspace.

But I didn't understand your claims regarding uninterruptible sleeps in 
your paragraph above. sys_sync() is one thing, that's just waiting 
uninterruptibly for completion. But how about all the mutex waitiers in 
TASK_UNINTERRUPTIBLE, for example?

Thanks a lot,

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