Bug 1883269 - kpatch: compressed modules support
Summary: kpatch: compressed modules support
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: kpatch
Version: 8.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: kpatch maintainers
QA Contact: kpatch QE
URL:
Whiteboard:
Depends On:
Blocks:
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:
Environment:
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):
kpatch-0.9.2-1.el8

How reproducible:
100%

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

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
depends:        
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:
		A4:41:FF:FB:3A:82:37:56:65:0C:3F:87:5A:FD:58:A0:42:73:ED:D3:
		11:1E:F3:C4:7F:30:2E:34:00:CE:DB:AE:1E:4C:8B:2D:62:54:03:41:
		D4:C6:99:23:25:11:17:FB:74:E5:CA:34:4D:F6:B5:89:87:87:B8:0C:
		04:50:F2:05:64:66:3C:AF:59:DF:D2:79:C1:C0:81:51:2A:F3:A4:EA:
		64:BB:9A:12:46:39:8B:0F:BB:41:0E:9E:B2:51:DB:B3:81:E0:57:BC:
		EF:71:B2:47:26:ED:4F:BB:65:08:00:AF:6D:D3:64:B3:FB:30:96:7E:
		C4:0A:C1:1E:F2:02:18:34:E6:FF:C0:EF:52:21:27:25:8A:38:DA:2D:
		FE:9F:83:FE:69:83:57:B3:2C:58:EA:58:A9:C4:BC:FE:7C:99:AB:78:
		C3:F4:28:7E:32:B6:E6:E8:16:C3:D2:59:83:B2:1D:BD:D9:A6:B7:0B:
		07:32:60:88:6C:F8:80:C3:AB:99:0E:CC:D6:CC:4E:2F:01:EA:5C:69:
		C3:19:BF:06:68:84:B1:0C:EB:3D:A4:D5:E0:AC:15:CE:5F:B8:83:4E:
		2A:F2:78:E3:E5:09:78:2C:10:B8:3B:E0:74:F4:42:72:EF:E3:22:BF:
		E0:CA:56:2C:25:F1:4B:FF:78:69:6F:94:4D:20:5D:B4:36:88:2F:9D:
		0D:21:A3:39:5E:6D:BA:7C:58:7C:C8:EF:AC:AC:A8:1F:86:2E:59:19:
		A9:FE:14:1A:46:FE:1E:FF:B8:89:EC:1A:E5:17:5C:6B:5E:56:D0:2C:
		24:EF:01:87:DA:B0:BC:9E:17:E7:4D:D0:CC:6F:FE:56:8F:90:9D:00:
		D0:CF:53:08:4A:0F:26:5C:5F:E8:F5:44:39:F1:C2:23:BF:2A:88:DD:
		F6:74:1E:6A:C1:EC:9D:AD:36:3B:80:A1:D3:5A:7A:1E:A5:72:78:EF:
		60:E0:00:F3

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
complete.

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.