linux-kernel - Re: [PATCH v3 2/2] livepatch: add atomic replace

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] [day] [month] [year] [list]

Date:   Fri, 20 Oct 2017 11:03:39 +0200 (CEST)
From:   Miroslav Benes <mbenes@...e.cz>
To:     Jason Baron <jbaron@...mai.com>
cc:     Josh Poimboeuf <jpoimboe@...hat.com>, linux-kernel@...r.kernel.org,
        live-patching@...r.kernel.org, jeyu@...nel.org, jikos@...nel.org,
        pmladek@...e.com
Subject: Re: [PATCH v3 2/2] livepatch: add atomic replace


> > It is even more complicated and it is not connected only to atomic replace 
> > patch (I realized this while reading the first part of your email and 
> > then you confirmed it with this paragraph). The consistency model is 
> > broken with respect to immediate patches.
> 
> Indeed. I came to the same conclusion.
> 
> > 
> > func		a
> > patches		1i
> > 		2i
> > 		3
> > 
> > Now, when you're applying 3, only 2i function is checked. But there might 
> > be a task sleeping in 1i. Such task would be migrated to 3, because we do 
> > not check 1 in klp_check_stack_func() at all.
> > 
> > I see three solutions.
> > 
> > 1. Say it is an user's fault. Since it is not obvious and it is 
> > easy-to-make mistake, I would not go this way.
> > 
> > 2. We can fix klp_check_stack_func() in an exact way you're proposing. 
> > We'd go back in func stack as long as there are immediate patches there. 
> > This adds complexity and I'm not sure if all the problems would be solved 
> > because scenarios how patches are stacked and applied to different 
> > functions may be quite complex.
> >
> 
> I think if its fixed in the current code (before atomic replace is
> introduced), then it would allow the atomic replace to drop all
> references to previous modules, since we would know they are no longer
> in use.

That's correct. Although, I'll submit my force patch soon, we can remove 
immediate afterwards and atomic replace should be simpler with that.

Miroslav