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:	Tue, 5 May 2015 08:14:50 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Josh Poimboeuf <jpoimboe@...hat.com>
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 Mon, 4 May 2015, Josh Poimboeuf wrote:

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

Fair enoungh, I agree that in case of the hybrid aproach you're proposing 
the immediate model is not necessary.

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

It depends on bringing some sanity to freezing / parking / signal handling 
for kthreads, which is an independent work in progress in parallel.

> How does the patching state ever reach completion?

kthread context always calls the old code and it doesn't block the 
finalization; that's basically a documented feature for now.

That surely is a limitation and something the patch author has to be aware 
of, but I wouldn't really consider it a show stopper for now, for the 
reason pointed out above; it'll eventually be made to work, it's not a 
substantial issue.

> 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").

Agreed ...  under the condition that it can be made really 100% reliable 
*and* we'd be reasonably sure that we will be able to realistically 
achieve the same goal on other architectures as well. Have you even 
started exploring that space, please?

Thanks,

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