linux-kernel - Re: kGraft to -next [was: 00/21 kGraft]

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:	Sat, 5 Jul 2014 16:36:06 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Jiri Slaby <jslaby@...e.cz>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-kernel@...r.kernel.org, rostedt@...dmis.org,
	mingo@...hat.com, Andrew Morton <akpm@...ux-foundation.org>,
	andi@...stfloor.org, paulmck@...ux.vnet.ibm.com,
	Pavel Machek <pavel@....cz>, jirislaby@...il.com,
	Vojtech Pavlik <vojtech@...e.cz>, Michael Matz <matz@...e.de>
Subject: Re: kGraft to -next [was: 00/21 kGraft]

Hello,

On Sat, Jul 05, 2014 at 10:04:52PM +0200, Jiri Kosina wrote:
> What we need is to have a defined point in execution where we can draw a 
> line between "old" and "new" universes. For processess that are crossing 
> the userspace/kernelspace boundary, the obvious choice, that covers most 
> of the use-cases, has been made. There are still scenarios where this 
> aproach can't be just-blindly-applied(TM) for various reasons (changing 
> lock order might cause deadlocks, there are cases where state is lingering 

Sure, if something breaks work due to semantic differences, there
isn't anything we can do.

> between two user <-> kernel transitions, etc). So we'll need to provide 
> guidelines for kGraft patch writers anyway.
> 
> The same holds for the kernel threads -- until all (or most of) the 
> kthreads are converted to workqueues, the obivous choice, that should 
> cover most of the use-cases, has been made.

But, this is different.  This is the mechanism itself being flaky and
buggy.  This can make things fail not because the patch itself is
semantically wrong but because the mechanism stopped the kernel at the
wrong place.  The mechanism is simply broken and it might as well
declare that patching whatever kthreads are running isn't supported.

> But manual/human inspection is absolutely unavoidably necessary in any 
> case.

This is extremely tricky to inspect and likely to just work in most,
but not all, cases when it goes wrong just out of sheer luck.

> Please keep in mind that this is designed for fixes that need immediate 
> response (getting bounds checking right, adding an extra check, adding a 
> missing lock, etc -- please see my previous mail on this topic in the old 
> thread). It's absolutely by design not intended for implementing whole new 
> features or exchanging the whole kernel on the fly; there are other 
> solutions for that (such as the criu-based thing). As such, we tend to 
> interfere with the rest of the kernel as little as possible, but it 
> inadverently brings drawbacks in the form of putting burden of more work 
> to the actual kGraft patch writers. I don't see that as a bad thing.

I'm not saying this must be able to do everything but it shouldn't be
voodoo either.  Freezer points *can* coincide with what kgraft
requires but it may not too.  Why claim that freezing points are safe
as stopping points when they aren't?  That doesn't make any sense to
me.  If kthread can't be safely supported now, that's fine but then
make it clear that functions which may be executed by kthreads aren't
supported.

Thanks.

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