Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

kern_path cannot be changed #1

Open
awilfox opened this issue Dec 7, 2022 · 3 comments
Open

kern_path cannot be changed #1

awilfox opened this issue Dec 7, 2022 · 3 comments

Comments

@awilfox
Copy link

awilfox commented Dec 7, 2022

This precludes ckms from being used in environments with multiple roots (i.e. having two OSes on separate partitions or btrfs subvols etc) and managing kernel modules without chroot.

Also, do_depmod uses /lib/modules itself instead of kern_path which may be an oversight. (depmod itself supports this sort of thing with -b.)

@q66
Copy link
Member

q66 commented Dec 7, 2022

yes, i still need to think about handling foreign roots a little more overall

@q66
Copy link
Member

q66 commented Dec 7, 2022

i think the main problem really comes down to that with such system it's not enough to be able to change where /lib/modules is - for example the compiler itself is a concern, one is expected to build the kernel modules with roughly the same compiler as the target system is using, and also the source code for the modules will be present on the target system, so in general chrooting may be a good idea anyway - but i'll think about it some more

@q66
Copy link
Member

q66 commented Dec 7, 2022

i can think of a couple more reasons why managing foreign roots without chroot is likely unfeasible:

  1. unlike dkms, ckms drops privileges for everything other than module installation/uninstallation so that it does not run random code as root - the privileges are dropped to a designated special user, which is determined by the owner of the state directory (by default /var/lib/ckms) - for different roots one would want to have different state dirs (so that you don't mix random systems' kernels together) and those would generally be present in the target roots (which means they may not necessarily map to any user on the host, and if they do, they may map to a user with wildly different access level than intended)
  2. ckms can trigger initramfs refresh for the kernel if it builds any modules that are meant to go into initramfs; the hook for refreshing initramfs is system-specific (as different systems may be using different initramfs generators) and generally should run inside the target system (for obvious reasons)

that said, if you can think of ways to address these issues in a reasonable way, i'm open to implementing this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants