linux-kernel - Re: [PATCH v12 06/12] livepatch: Simplify API by removing registration step

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:   Wed, 24 Oct 2018 13:14:44 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     Miroslav Benes <mbenes@...e.cz>, Jiri Kosina <jikos@...nel.org>,
        Jason Baron <jbaron@...mai.com>,
        Joe Lawrence <joe.lawrence@...hat.com>,
        Jessica Yu <jeyu@...nel.org>,
        Evgenii Shatokhin <eshatokhin@...tuozzo.com>,
        live-patching@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v12 06/12] livepatch: Simplify API by removing
 registration step

On Tue 2018-10-23 11:39:43, Josh Poimboeuf wrote:
> On Mon, Oct 22, 2018 at 03:25:10PM +0200, Petr Mladek wrote:
> > On Fri 2018-10-19 09:36:04, Josh Poimboeuf wrote:
> > > On Fri, Oct 19, 2018 at 02:16:19PM +0200, Miroslav Benes wrote:
> > > > On Thu, 18 Oct 2018, Josh Poimboeuf wrote:
> > > > > As long as we're talking about radical changes... how about we just
> > > > > don't allow disabling patches at all?  Instead a patch can be replaced
> > > > > with a 'revert' patch, or an empty 'nop' patch.  That would make our
> > > > > code simpler and also ensure there's an audit trail.
> > > > > 
> > The revert operation allows to remove a livepatch stuck in the
> > transition without forcing.
> 
> True, though I question the real world value of that.

We ended in this situation few times with kGraft when a kthread
was not annotated and migrated. We have not seen this with upstream
livepatch code yet but we shipped first product with it only few
months ago.

I would say that it is nice to have but it is not must to have.


> > One big problem would be how to keep the system consistent. You
> > would need to solve races between loading modules and livepatches
> > anyway.
> > 
> > For example, you could not load fixed/patched modules when the system
> > is not fully patched yet. You would need to load the module and
> > the related livepatch at the same time and follow the consistency
> > model as we do now.
> 
> Yeah, I think that's pretty much the crazy idea Miroslav mentioned.  The
> patch would consist of several modules.  The parent module would
> register the patch and patch vmlinux.  Each child module would be
> associated with a to-be-patched module.  The child modules could be
> loaded on demand, either by special klp code or by modprobe.

Yup, something like this.

> As you described, there would be some races to think about.  However, it
> would also have some benefits.
> 
> I *hope* it would mean we could get rid of a lot of our ugly hacks, like
> 
> - klp symbols, klp relas

The access to external static symbols would still need so klp-specific
relocations.

> - preserving ELF data, PLT's, other horrible arch-specific things
> - klp.arch..altinstructions, klp.arch..parainstructions
> - manually calling apply_relocate_add()

Yup, these might be candidates to go.


> However... we might still need some of those things for another reason:
> to bypass exported symbol protections.  It needs some more
> investigation.
> 
> Given this discussion, I'm thinking there wouldn't be much to discuss at
> LPC for this topic unless we had a prototype to look at (which I won't
> have time to do).  So I may drop my talk in favor of giving more time
> for other more tangible discussions.

Sounds reasonable. At least I would not be able to say much more about
it without seeing a more detailed proposal and ideally a prototype
code. That said, I definitely do not want to discourage you from
playing with the idea.

Best Regards,
Petr