linux-kernel - Re: [RFC kgr on klp 0/9] kGraft on the top of KLP

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, 4 May 2015 22:43:52 -0500
From:	Josh Poimboeuf <jpoimboe@...hat.com>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	Jiri Slaby <jslaby@...e.cz>, live-patching@...r.kernel.org,
	sjenning@...hat.com, vojtech@...e.cz, mingo@...hat.com,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC kgr on klp 0/9] kGraft on the top of KLP

On Tue, May 05, 2015 at 12:48:22AM +0200, Jiri Kosina wrote:
> On Mon, 4 May 2015, Josh Poimboeuf wrote:
> > Why do we need multiple consistency models?
> 
> Well, I am pretty sure we need always at least two:
> 
> - the "immediate" one, where the code redirection flip is switched 
>   unconditionally and immediately (i.e. exactly what we currently have in 
>   Linus' tree); semantically applicable to many patches, but not all of 
>   them
> 
> - something that fills the "but not all of them" gap above.

What's the benefit of having the "immediate" model in addition to
the more comprehensive model?

> Both of the solutions that have been presnted so far have some drawbacks 
> that need to be discussed further. To me, the "highlights" (in the 
> "drawbacks" space) are:
> 
> - any method that is stack-checking-based basically means that we have to
>   functionally 100% rely on stack unwinding correctness. We have never 
>   done that before, and current stack unwinder is not ready for that 
>   (Josh is working on improving that);

I wouldn't call it a drawback.  More like a deal breaker :-) But yeah,
I'm working on that.

>   plus it can cause the patching to fail under certain circumstances

Assuming you're talking about the kGraft/kpatch hybrid RFC, it actually
doesn't fail.  It falls back to asynchronous lazy migration for any
straggler tasks.

> - the kGraft method is not (yet) able to patch kernel threads, and allows 
>   for multiple instances of the patched functions to be running in 
>   parallel (i.e. patch author needs to be aware of this constaint, and 
>   write the code accordingly)

Not being able to patch kthreads sounds like a huge drawback, if not a
deal breaker.  How does the patching state ever reach completion?

> This is exactly why we are submitting the kGraft-on-klp patchset, so that 
> we have concurrent implementations (sharing the same goal) to compare, and 
> ultimately merge whatever the best possible outcome will be.

Another big downside to kGraft, assuming you want the patching to
complete within a realistic period of time, is that you have to wake up
all the sleeping tasks and send them through their signal handling
paths.  I would say it's orders of magnitude more disruptive and much
riskier compared to walking the stacks (again, assuming we can make
stack walking "safe").

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