FS#72275 - [linux] [linux-lts] [linux-zen] [linux-hardened] Consider removing mutable modules.*

Attached to Project: Arch Linux
Opened by Emil (xexaxo) - Tuesday, 28 September 2021, 22:03 GMT
Last edited by Toolybird (Toolybird) - Tuesday, 02 May 2023, 21:56 GMT
Task Type Bug Report
Category Kernel
Status Closed
Assigned To Andreas Radke (AndyRTR)
Jan Alexander Steffens (heftig)
Levente Polyak (anthraxx)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:

Currently the linux packages, ship the immutable and _mutable_ modules.* files alongside them.
As such running pacman's package check complains about modification time mismatch.

AFAICT this happens since the depmod hook is executed as the package is installed.
Running the hook in itself is the right thing to do IMHO, yet I don't see any value in shipping the mutable files.

The attached trivial patch fixes the problem for me. It is against the linux package - the kernel I use 99% of the time.
Happy to provide more patches if needed.


Additional info:
* package version(s)

linux 5.14.8-arch1-1
linux-lts 5.10.69-1
linux-zen 5.14.8.zen1-1
linux-hardened 5.14.8.hardened1-1


Steps to reproduce:
- install any of the four kernel packages - for example linux
- verity the package integrity - pacman -Qkk linux
- observe nearly a dozen warnings

warning: linux: /usr/lib/modules/5.14.8-arch1-1/modules.alias (Modification time mismatch)
warning: linux: /usr/lib/modules/5.14.8-arch1-1/modules.alias.bin (Modification time mismatch)
warning: linux: /usr/lib/modules/5.14.8-arch1-1/modules.builtin.alias.bin (Modification time mismatch)
warning: linux: /usr/lib/modules/5.14.8-arch1-1/modules.builtin.bin (Modification time mismatch)
warning: linux: /usr/lib/modules/5.14.8-arch1-1/modules.dep (Modification time mismatch)
warning: linux: /usr/lib/modules/5.14.8-arch1-1/modules.dep.bin (Modification time mismatch)
warning: linux: /usr/lib/modules/5.14.8-arch1-1/modules.devname (Modification time mismatch)
warning: linux: /usr/lib/modules/5.14.8-arch1-1/modules.softdep (Modification time mismatch)
warning: linux: /usr/lib/modules/5.14.8-arch1-1/modules.symbols (Modification time mismatch)
warning: linux: /usr/lib/modules/5.14.8-arch1-1/modules.symbols.bin (Modification time mismatch)

This task depends upon

Closed by  Toolybird (Toolybird)
Tuesday, 02 May 2023, 21:56 GMT
Reason for closing:  Fixed
Additional comments about closing:  "The mutable files are no longer in our linux packages."
Comment by Emil (xexaxo) - Tuesday, 28 September 2021, 22:06 GMT
Hmm just noticed the dkms hooks have this match:
`Target = usr/lib/modules/*/modules.alias`

Perhaps that one should be updated to:
`Target = usr/lib/modules/*/modules.builtin`
Comment by Levente Polyak (anthraxx) - Wednesday, 29 September 2021, 07:53 GMT
having modified time mismatch is fine. if we do not package those files and uninstall one of the kernels we will leave files back cluttering the root file system with untracked files.
Comment by Jan Alexander Steffens (heftig) - Wednesday, 29 September 2021, 10:30 GMT
I guess we could package them empty to save some package size?
Comment by Emil (xexaxo) - Wednesday, 29 September 2021, 14:56 GMT
Good point about the untracked files. My initial inclination is that the depmod hook should be garbage collecting those, since it's the one creating them.
Will polish my pacman hook knowledge and propose a concrete patch in the coming days.

Don't think it's worth leaving them empty, since a) they're really small ~5MiB and b) this will flag a "File is modified" warnings by pacman which are more important.
Comment by Levente Polyak (anthraxx) - Wednesday, 29 September 2021, 15:02 GMT
I don't think those are really important. You can't rely on pacman notified changes to classify them as "bugs" or problems. We are also using tmpfiles with sysusers massively that changes files reported by the pacman.
Comment by Emil (xexaxo) - Wednesday, 29 September 2021, 18:41 GMT
So basically you're saying that I should not be looking at `pacman -Qkk`? Keep in mind I recently added support to validate the checksum of installed files.

AFAICT I'm not the only developer (kernel or otherwise) to regularly hack my Arch install, and since the package manager is smart I heed it's advice to pick the pieces.

I get your point that this is minor, but don't shrug it off. Especially not since pacman had to disable the ownership warnings few years ago.

[1] https://gitlab.archlinux.org/pacman/pacman/-/commit/ba869597fb64f1101012df4b0d834ed5eced0b7c
Comment by Levente Polyak (anthraxx) - Thursday, 30 September 2021, 08:24 GMT
The ownership warnings are still in place and report changes:

https://gitlab.archlinux.org/pacman/pacman/-/blob/HEAD/src/pacman/check.c#L78-104

I'm not shrugging it off and I'm not saying you shouldn't run that command :) What I tried to say is that you cannot blindly rely on the output. There are packages with UID/GID, Permissions or potentially other warnings that will break if they are blindly "fixed/reverted". What i tried to say is that the context of the file and the type of a warning is important.
Comment by Emil (xexaxo) - Sunday, 30 January 2022, 19:55 GMT
After reading up on the topic, the following patches seem to work:

The kmod.patch, drop "Operation = Remove" from the existing hook (+ minor cleanup) and adds depmod-remove.hook, doing the cleanup.
Thus as follow-up the linux packages - linux, linux-lts, etc - can apply a patch like linux.patch so they no longer own the mutable modules.foo files.
Comment by Emil (xexaxo) - Sunday, 30 January 2022, 20:03 GMT
Here is the patch for the linux package.

Both patches are based on `asp checkout` and the core packages. Happy to respin them in other shapes or forms.

Thanks o/
Comment by Emil (xexaxo) - Thursday, 31 March 2022, 15:53 GMT
I've been using the above patches for a couple of months now without an issue.

How can I help with anything to get them (or variation thereof) merged?
Comment by Jan Alexander Steffens (heftig) - Thursday, 31 March 2022, 15:57 GMT
Do the files still get removed properly when you upgrade kernels?
Comment by Jan Alexander Steffens (heftig) - Thursday, 31 March 2022, 16:02 GMT
Never mind, missed the kmod patch.

I'll take a look when I can find the time.
Comment by Jan Alexander Steffens (heftig) - Friday, 01 April 2022, 17:49 GMT
Splitting the hooks makes things unnecessarily complex, IMO. I would much prefer a simpler change to kmod, see https://paste.xinu.at/esljm/
Comment by Emil (xexaxo) - Saturday, 02 April 2022, 18:12 GMT
What is making it complex - the inlining or something else?

IMHO having the script do both generation and removal is fairly ambiguous and a recipe for disaster. There's a reason we don't keep the rubbing alcohol amongst the drinking water bottles :-P

Looking at the proposed change and I'm not sure ... seems like it will do the wrong thing by mistake.

Say if the user has renamed the vmlinux file (debugging something) and an out of tree kernel module gets updated. I might be reading it wrong, but to me it seems like all `modules.*` will be removed - generated and the ones from the kernel package.

What makes it worse is the removal is not displayed in the pacman log, the system is borked and depmod cannot regenerate the mutable files since the critical modules.builtin, modules.order etc are gone.

Mind you, I'm not 100% sure with my analysis so feel free to correct me.
Comment by Jan Alexander Steffens (heftig) - Saturday, 02 April 2022, 19:49 GMT
Yeah, and the solution is to not do that. Leave packaged files alone.

But with your code the situation is even worse. Your remove hook will remove all modules.* files when any module package gets removed, no prior screwing around required.

pacman -S vhba-module
(2/2) Updating module dependencies...

pacman -R vhba-module
(1/1) Removing module dependencies...

pacman -S vhba-module
(2/2) Updating module dependencies...
depmod: WARNING: could not open modules.order at /lib/modules/5.17.1-arch1-1: No such file or directory
depmod: WARNING: could not open modules.builtin at /lib/modules/5.17.1-arch1-1: No such file or directory
Comment by Jan Alexander Steffens (heftig) - Saturday, 02 April 2022, 19:57 GMT
Anyway, we can limit the damage of the removal by explicitly naming the generated files.
Comment by Emil (xexaxo) - Monday, 04 April 2022, 17:00 GMT
You're correct - kmod-v2 keeps the separate scripts and explicitly removes only the mutable files.

Edit: the patch is still broken... Might need to rethink the approach.
Comment by Jan Alexander Steffens (heftig) - Monday, 04 April 2022, 18:42 GMT
This is what I intend to apply to kmod: https://paste.xinu.at/1VV/
This is what I intend to apply to linux: https://paste.xinu.at/dZ2Nl8/
Comment by Emil (xexaxo) - Monday, 04 April 2022, 18:51 GMT
Another (hopefully final) iteration:
- original depmod hook is unchanged - it must be called even on Remove operation
- renamed the removal hook (modules-remove) - triggers on ...pkgbase aka linux-foo package removal

Tested permutations of the following:
- pacman -Syu linux linux-lts - depmod triggers, regenerates mutable files
- pacman -S vhba-module - depmod triggers, regenerates mutable files
- pacman -R vhba-module - depmod triggers, regenerates mutable files
- pacman -R linux-lts - modules-remove triggers, removes the mutable files
Comment by Emil (xexaxo) - Monday, 04 April 2022, 19:09 GMT
Having both install and remove in the same script will backfile and should be avoided IMHO.
We can ignore the trivial issues like misleading hook message and rmdir workaround (since it's ran post transaction).

Looking at the kernel patch - as-it it will result a warning and will break dkms (unless s/alias/builtin/ is applied)
Warning: 'make modules_install' requires $DEPMOD. Please install it.
This is probably in the kmod package.
Comment by Jan Alexander Steffens (heftig) - Thursday, 07 April 2022, 08:42 GMT
How will it break DKMS? As far as I can tell, preventing the build from running depmod has the same effect as deleting the files afterwards, but saves some time and doesn't require listing the files.
Comment by Emil (xexaxo) - Friday, 08 April 2022, 17:49 GMT
If I'm reading it correctly, DKMS uses `Target = usr/lib/modules/*/modules.alias`.

When the linux patch (you linked) gets applied, the modules.alias will not be owned by anyone. Since the target is effectively missing, the hook won't be executed.
Comment by Andreas Radke (AndyRTR) - Thursday, 14 April 2022, 08:02 GMT
Changes have been applied also to linux-lts-5.15.34-1.

Loading...