On Fri, Aug 23, 2019 at 10:13:06AM +0200, Petr Mladek wrote:
On Thu 2019-08-22 17:36:49, Josh Poimboeuf wrote:
On Fri, Aug 16, 2019 at 11:46:08AM +0200, Petr Mladek wrote:
On Wed 2019-08-14 10:12:44, Josh Poimboeuf wrote:
On Wed, Aug 14, 2019 at 01:06:09PM +0200, Miroslav Benes wrote:
Really, we should be going in the opposite direction, by creating module
dependencies, like all other kernel modules do, ensuring that a module
is loaded *before* we patch it. That would also eliminate this bug.
We should look at whether it makes sense to destabilize live patching
for everybody, for a small minority of people who care about a small
minority of edge cases.
I do not see it that simple. Forcing livepatched modules to be
loaded would mean loading "random" new modules when updating
I don't want to start a long debate on this, because this idea isn't
even my first choice. But we shouldn't dismiss it outright.
I am glad to hear that this is not your first choice.
+ It means more actions and higher risk to destabilize
the system. Different modules have different quality.
Maybe the distro shouldn't ship modules which would destabilize the
Is this realistic? Even the best QA could not check all scenarios.
My point is that the more actions we do the bigger the risk is.
Sure, it introduces risk. But we have to compare that risk (which only
affects rare edge cases) with the ones introduced by the late module
patching code. I get the feeling that "late module patching" introduces
risk to a broader range of use cases than "occasional loading of unused
The latter risk could be minimized by introducing a disabled state for
modules - load it in memory, but don't expose it to users until
explicitly loaded. Just a brainstormed idea; not sure whether it would
work in practice.
+ It might open more security holes that are not fixed by
Following the same line of thinking, the livepatch infrastructure might
open security holes because of the inherent complexity of late module
Could you be more specific, please?
Has there been any known security hole in the late module
Just off the top of my head, I can think of two recent bugs which can be
blamed on late module patching:
1) There was a RHEL-only bug which caused arch_klp_init_object_loaded()
to not be loaded. This resulted in a panic when certain patched code
2) arch_klp_init_object_loaded() currently doesn't have any jump label
specific code. This has recently caused panics for patched code
which relies on static keys. The workaround is to not use jump
labels in patched code. The real fix is to add support for them in
I can easily foresee more problems like those in the future. Going
forward we have to always keep track of which special sections are
needed for which architectures. Those special sections can change over
time, or can simply be overlooked for a given architecture. It's