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

Allowing modprobe modules to load firmware if needed #3217

Open
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
5 participants
@rvs
Contributor

rvs commented Nov 1, 2018

- What I did

Allowed for modprobe modules to load firmware files.

- How I did it

Made /lib/firmware available in the modprobe container and also added capabilities all. This last bit I'm really not sure of, but try as hard as I may the CAP_SYS capabilities don't seem to allow for kernel to load firmware files from the filesystem. I think it should be fine for this pkg, but would appreciate any guidance on how to make it more granular.

- How to verify it

Modprobe any WiFi driver that requires a firmware

- Description for the changelog

Allowed for modprobe modules to load firmware files.

- A picture of a cute animal (not mandatory but encouraged)

=!=!=
-
/

Allowing modprobe modules to load firmware if needed
Signed-off-by: Roman Shaposhnik <rvs@zededa.com>
@justincormack

This comment has been minimized.

Collaborator

justincormack commented Nov 1, 2018

all literally just adds the full list of CAP_SYS caps, so some subset of them must also work... I would suspect you might need CAP_SYS_ADMIN as well?

@ijc

This comment has been minimized.

Collaborator

ijc commented Nov 2, 2018

I think I must misunderstand how firmware loading works, perhaps some one can enlighten me.

My understanding was that firmware loading was an asynchronous process (triggered by drivers while they are probing) which ends up triggering a userspace event which udev (or perhaps mdev) then satisfies by loading the firmware (by dumping it to some file under /sys).

I don't think that modprobe ever does any modprobing (I don't see anything like that in modprobe applet in the busybox source, that all seems to be in the mdev applet).

It's also my understanding that the userspace events are processed in the host/root namespace, not within any particular container, even if the device probe/driver bind that triggered the userspace firmware loading event was caused by modprobe loading some new module from inside a container.

The pkg/init/usermode-helper.c helper executes both modprobe and mdev directly in the root namespace, it is not forwarding to a container AFAICT.

What am I missing? How/where does firmware get loaded within any modprobe container?

edit: ideally the mechanics of what are going here which justifies this as a correct change would be in the commit message, since it is non-obvious.

@rvs

This comment has been minimized.

Contributor

rvs commented Nov 2, 2018

@justincormack I was hoping somebody on this thread could pinpoint precisely the CAP I need for this. So far I tried a union of CAP_SYS_ADMIN | CAP_SYS_MODULE | CAP_SYS_RAWIO and it still doesn't allow me to load the firmware from within modprobe container. The all, of course, does. Let me poke some more -- but I'd really appreciate if anyone suggest what is really needed here.

@justincormack

This comment has been minimized.

Collaborator

justincormack commented Nov 2, 2018

You could try just putting the full list in and removing them one by one. It seems weird though, I would try CAP_MKNOD and maybe CAP_DAC_OVERRIDE as plausible ones...

@rvs

This comment has been minimized.

Contributor

rvs commented Nov 2, 2018

@ijc here's a few things you're missing:

  • while it is true that by default modprobe container doesn't do modprobe it actually has the binary to do so and a capability CAP_SYS_MODULE to allow it. Hence the typical usage is to specify something like command: ["modprobe", "-a", "XXX" ] in your linuxkit.yml file. The problem, of course, is how that interacts with the case when the firmware is required for the driver being modrpobed. Which brings us to...
  • ...how firmware gets loaded (note this changed at around 2016 https://lwn.net/Articles/676101/): modern linux kernels actually default to read firmware from the filesystem (instead of going through udev and userspace). The question then becomes what namespace does it look under. This gets determined by whether the firmware loading event got triggered from within a container (or even chroot for that matter or not).

You're right that in linuxkit all of this a bit manual since we're not using anything like mdev (although as @rn pointed out we do have this issue pending #2836). However, I'd argue that for as long as we use modprobe package for manually orchestrating something that mdev would've done -- we might as well empower it to do its job.

Of course, to @justincormack point -- nobody's suggesting that we add capabilities all -- that's still need to get clarified. The rest, however, I would argue stands.

Does it make it clear(er)?

@rn

This comment has been minimized.

Member

rn commented Nov 3, 2018

You're right that in linuxkit all of this a bit manual since we're not using anything like mdev

We are actually using mdev in the root namespace but it sometimes fails to load modules. This seems particularly the case for USB attached devices. On the RPi3, for example, the smsc95xx modules needs to be loaded manually.

@ijc

This comment has been minimized.

Collaborator

ijc commented Nov 5, 2018

here's a few things you're missing:

Thanks. Please can you arrange for the core bits of your second bullet to make it into the commit message...

I'm afraid I don't know which caps are needed, I second @justincormack 's suggestion to put in the full list and then systematically removing things.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment