uname enhancement

[joe-lawrence]

I think this idea has been floated a few times, most recently by @lulinqing or maybe @mmilgram : should kpatch provide supplemental uname information?

For reference:

• Oracle has an uptrack-uname command to show what "effective kernel a machine is running".
• SUSE's livepatches patch the kernel's SyS_newuname to add a kGraft-@@GITREV@@ tag to the kernel version string.

I think we have a few options:

1. Roll something like SUSE's solution into each kpatch, manually or automatically.
2. Add to kpatch-macro.h a macro that pushes a value into the livepatch's modinfo. The kpatch-utility could then report those values in its list or (new) uname sub-commands.
3. Suggest a new /sys/kernel/livepatch/<patch>/uname interface or similar upstream.
4. Save this information elsewhere in the patch distribution, in the RPM changelog for example.

Some caveats to consider:

• Scripts may rely upon the current uname -r format. I'm reluctant to modify this.
• The kernel and kpatch-utility support loading multiple livepatches... what does it mean if patch 1 sets an effective uname of version A and patch 2 version B?
• An "effective kernel version" may be confusing to a user if it only includes a subset of the patches of said kernel version.

[jpoimboe]

• An "effective kernel version" may be confusing to a user if it only includes a subset of the patches of said kernel version.

This is the part that bothers me the most. It seems like setting an "effective kernel version", when in fact it would be missing most of the patches from the corresponding real kernel, is actively misleading.

[jpoimboe]

Not to say that we shouldn't do it, just that we should be cautious in deciding to do it.

[yhcote]

Assigning myself as Joe proposed. Brainstorming/ideas to follow.

[joe-lawrence]

Not to say that we shouldn't do it, just that we should be cautious in deciding to do it.

I agree and I think that is why we've been reluctant to add it in the past. IMHO, a CVEs-fixed field would be more descriptive, though Red Hat distributed kpatches already contain that information in the RPM changelog.

I wonder if the tagging that SUSE uses, i.e. something like kpatch-kernel-3.10.0-123.12.1.el7 would be enough to differentiate from kernel-3.10.0-123.12.1.el7?

[yhcote]

I wonder if the tagging that SUSE uses, i.e. something like kpatch-kernel-3.10.0-123.12.1.el7 would be enough to differentiate from kernel-3.10.0-123.12.1.el7?

I agree that not cramming too much info in the version string is probably best, as long as there's a simple element clearly showing that a patched kernel is running. I would pick the version field as opposed to the release field so that uname -r which is relied upon like you mentioned earlier continue to work as expected. We have the option of adding a prefix to the version string (uname -v) that immediately follows the release field (returned by in uname -r) with some marker to show that the kernel runs with kpatch.

[yhcote]

maybe something like (square brakets to show uts fields grouping): [Linux] [hostname] [4.18.0-80.7.2.el8_0.x86_64] [+2 Livepatch(es) #1 SMP Fri Jul 26 10:48:21 UTC 2019] [x86_64] [x86_64] [x86_64] [GNU/Linux]

[mrmilgram]

Some customers want to know what kernel level their system has been patched to. That information could be output by uname, or by some other command (such as the kpatch command).

Some security scanners will look for the kernel version as returned by "uname -r". On the other hand, we can dictate where to get that information. Periodically we need to convince customers that fixes from newer upstream kernel versions have been backported to the supported kernel.

[joe-lawrence]

Closing this one until we have real requirements. Given the variety of solutions, it would be most helpful if scanning tools looked for something specific -- with that we would know what to build. Until then, closing this issue.