linux-kernel - Re: [RFC PATCH 2/2] livepatch: Clear relocation targets on a module removal

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:   Fri, 6 Sep 2019 14:51:01 +0200 (CEST)
From:   Miroslav Benes <mbenes@...e.cz>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
cc:     Joe Lawrence <joe.lawrence@...hat.com>,
        Petr Mladek <pmladek@...e.com>, jikos@...nel.org,
        linux-kernel@...r.kernel.org, live-patching@...r.kernel.org
Subject: Re: [RFC PATCH 2/2] livepatch: Clear relocation targets on a module
 removal

> > Now, I don't think that replacing .ko on disk is a good idea. We've 
> > already discussed it. It would lead to a maintenance/packaging problem, 
> > because you never know which version of the module is loaded in the 
> > system. The state space grows rather rapidly there.
> 
> What exactly are your concerns?
> 
> Either the old version of the module is loaded, and it's livepatched; or
> the new version of the module is loaded, and it's not livepatched.

Let's have module foo.ko with function a().

Live patch 1 (LP1) fixes it to a'(), which calls new function b() (present 
in LP1). LP1 is used only if foo.ko is loaded. foo.ko is replaced with 
foo'.ko on disk. It contains both a'() (fixed a() to be precise) and new 
b().

Now there is LP2 with new function c() (or c'(), it does not matter) 
calling b(). Either foo.ko or foo'.ko can be loaded and you don't know 
which one. The implementation LP2 would be different in both cases.

You could say that it does not matter. If LP2 is implemented for foo.ko, 
the same could work for foo'.ko (b() would be a part of LP2 and would not 
be called directly from foo'.ko). LP2 would only be necessarily larger. It 
is true in case of functions, but if symbol b is not a function but a 
global variable, it is different then.

Moreover, in this case foo'.ko is "LP superset". Meaning that it contains 
only fixes which are present in LP1. What if it is not. We usually 
preserve kABI, so there could be a module in two or more versions compiled 
from slightly different code (older/newer and so on) and you don't know 
which one is loaded. To be fair we don't allow it (I think) at SUSE except 
for KMPs (kernel module packages) (the issue of course exists even now 
and we haven't solved it yet, because it is rare) and out of tree modules 
which we don't support with LP. It could be solved with srcversion, but it 
complicates things a lot. "blue sky" idea could extend the issue to all 
modules given the above is real.

Does it make sense?

Miroslav