Bug 1883269 - kpatch: compressed modules support
Summary: kpatch: compressed modules support
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: kpatch
Version: 8.4
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: 8.0
Assignee: kpatch maintainers
QA Contact: kpatch QE
Depends On:
TreeView+ depends on / blocked
Reported: 2020-09-28 15:46 UTC by Yulia Kopkova
Modified: 2021-07-20 20:33 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
Type: Bug
Target Upstream Version:

Attachments (Terms of Use)

Description Yulia Kopkova 2020-09-28 15:46:50 UTC
Description of problem:
It's a feature request for kpatch to support compressed modules

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. kpatch install /lib/modules/4.18.0-235.el8.x86_64/internal/lib/livepatch/test_klp_livepatch.ko.xz

Actual results:
kpatch: /lib/modules/4.18.0-235.el8.x86_64/internal/lib/livepatch/test_klp_livepatch.ko.xz isn't a .ko file

Expected results:
Kpatch handles .ko.xz modules

Additional info:
# modinfo /lib/modules/4.18.0-235.el8.x86_64/internal/lib/livepatch/test_klp_livepatch.ko.xz
filename:       /lib/modules/4.18.0-235.el8.x86_64/internal/lib/livepatch/test_klp_livepatch.ko.xz
description:    Livepatch test: livepatch module
author:         Seth Jennings <sjenning@redhat.com>
livepatch:      Y
license:        GPL
rhelversion:    8.3
srcversion:     9A8D93E50589B6153082E3C
intree:         Y
name:           test_klp_livepatch
vermagic:       4.18.0-235.el8.x86_64 SMP mod_unload modversions 
sig_id:         PKCS#7
signer:         Red Hat Enterprise Linux kernel signing key
sig_key:        34:2F:7C:58:A5:8F:21:63:C1:3E:E5:C5:4A:DE:96:D8:C3:EE:82:5A
sig_hashalgo:   sha256
signature:      79:E0:28:50:89:D2:93:A7:34:52:CA:A9:5F:CB:D1:0C:33:49:F3:86:

Comment 1 Joe Lawrence 2020-09-28 16:43:15 UTC
Hi Yulia,

A quick question about the visibility and importance of this issue.

- RHEL-8 compresses kernel-* RPM provided module .ko files manually in the kernel specfile, and not via kernel CONFIG_MODULE_COMPRESS
- Without CONFIG_MODULE_COMPRESS, all Red Hat provided kpatch-patch RPMs only provide uncompressed kpatch.ko files

So I think this is not an issue any Red Hat kpatch-patch user would encounter, at least by installing official kpatch-patch RPMs that we release.

That said, the use case in Comment #0 looks like it enables new testing.  I don't think the fix will be too difficult upstream, but I'm wondering how critical it would be to backport and then to which releases?

Comment 3 Joe Lawrence 2020-09-30 19:35:25 UTC
I experimented some more with CONFIG_MODULE_COMPRESS_XZ=y:

  - Module .ko files are only compressed when running the kernel's
    "modules_install" target

     - kpatch-build doesn't run "modules_install", it copies the original
      .ko from the out of tree module dir (~/.kpatch/tmp/patch) to the
      current working dir

  - Even if one were to run "make -C /lib/modules/`uname -r`/build
    M=~/.kpatch/tmp/patch modules_install", a compressed .ko would be
    installed to /lib/modules/$(uname -r)/extra/

     - This is not kpatch utility's $INSTALLDIR, /var/lib/kpatch/$(uname
       -r)/, so the utility won't find this compressed module for use in
       any of its sub-commands

  - If we were to add module compression support to kpatch-build, it
    would look more like the RHEL kernel specfile, where it's
    post-processed outside of kbuild.

      - We would need to update kpatch utility in a few ways:

        - handle .ko{.gz,.xz} filename extensions
        - decompress before issuing any binutils or elfutils commands,
          like readelf
        - verify that debuginfo properly handles compression

I don't think any of this is impossible, but would require some time to
build and test through the whole pipeline (github, kpatch utility,
kpatch-patch generation, etc).

Thinking some more on this, the module you're trying to load is a
pure livepatch module and not a kpatch-module.  I wonder if makes more
sense to use a separate utility to handle them.

Somewhere I have a prototype that extracts interesting functions from
the kernel's tools/testing/selftests/livepatch/functions.sh file.  This
would allow a user to say "klp load <name>" and like kpatch-utility, it
will block until the module has fully loaded and its transition

I guess the next step(s) depend on the full use case.  Are you looking
to verify kpatch utility behavior with test_klp_livepatch.ko.xz, kernel
behavior, or something else?

Comment 4 Yulia Kopkova 2020-10-01 12:03:30 UTC
Hi, Joe. 

As you pointed out this is not a customer use case. 
I was under wrong impression that something is already implemented upstream.
Thank you for detailed explanation and please disregard this request.

Need to take a different approach for a test case I'm thinking of. 
Looking to add a lightweight test for kpatch utility that is run on nightly composes.
Will need a module to install, enable and load. 
Do not want to build kpatch modules as it requires a lot of dependencies to be installed and takes significant time. 

Unfortunately, we do not build kpatch-patch modules for each candidate kernel in ystream that could be utilized.

Please let me know your thoughts.

Comment 5 Joe Lawrence 2020-10-01 14:46:03 UTC
Hmm, using an uncompressed test_klp_livepatch.ko with kpatch utility may be the fastest way to implement this new test.  AFAIK there is nothing stopping kpatch-utility from install/enable/load-ing a pure livepatch, only that doing so isn't part of any integration test that we regularly run.  YMMV, but I bet it works :)

To do this with frequently created kpatch-livepatches will require some new automation.  The team has kicked around similar ideas in the past (for empty kpatches I think), so maybe this use case could be included as part of a larger goal.  I think this would make a good dev-team agenda item, though the next one isn't until Oct 28.  If you want to brainstorm sooner, we can start a thread on kpatch-team.

Comment 6 Yulia Kopkova 2020-10-01 15:31:25 UTC
Thank you, Joe. 
Oct 28 is ok with me. I do not need it earlier. 
Can draft a test with test_klp_livepatch or previously built kpatch-patches

Please feel free to close this bz.

Note You need to log in before you can comment on or make changes to this bug.