Load WiFi/BT firmware blob from BIOS

[jas4711]

The problem you're addressing (if any)

I don't want to load non-free blobs from the OS, but I am willing to use a machine with BIOS that has non-free blobs in it -- primarily because there is no other option for modern x86 CPUs.

Describe the solution you'd like

The Dasharo BIOS could embed a copy of the non-free Intel X200/X210/BE200 blobs and load them if the hardware is present.

Where is the value to a user, and who might that user be?

I would be able to run fully free OS's like Trisquel that reject including any non-free blobs, and still have WiFi/BT working.

Describe alternatives you've considered

I'm using the QCNFA222 module now and it is working well on my NV41. However my next laptop -- the novacustom V54/V56 -- does not support it since QCNFA222 only supports S3 and not S0ix but the V54/V56 only supports S0ix and not S3.

Additional context

No response

[wessel-novacustom]

@macpijan Do you think this is technically feasible?

[wessel-novacustom]

@jas4711 I have had discussions with my firmware developers team today.

They say that it probably is technically feasible, but the potential problem is that WiFi updates need to be done through firmware, which are generally slower released than OS updates. In addition, the WiFi options are limited to the WiFi modules we use, which is a limitation for user freedom.

With these points in mind, we cannot proceed with realising the feature request, unless this post gains popularity.

[zirblazer]

Why you instead don't use virtualization to do PCI Passthrough of the WiFi card to a QEMU VM that uses the standard binary blobs then use that working connection to share Internet with the host? I have seen that done before and is both easier to do and maintain that the super niche solution you're seeking.

[jas4711]

Why you instead don't use virtualization to do PCI Passthrough of the WiFi card to a QEMU VM that uses the standard binary blobs then use that working connection to share Internet with the host?

That requires me to load the non-free blob from the OS level, which is what I didn't want to do. I don't see how nesting it in a VM solves anything, I still need to touch the non-free blob from below the kernel booting on the hardware, which is what I want to avoid.

/Simon

[jas4711]

@jas4711 I have had discussions with my firmware developers team today.

They say that it probably is technically feasible

Thanks for bringing this up. Interesting! I feared there may be some fundamental problem preventing this from being possible to implement in any reasonable way. Such as the firmware uploader requiring a lot of functionality from the linux kernel or something similar.

but the potential problem is that WiFi updates need to be done through firmware,

That is okay by me. WiFi firmware blobs doesn't seem to be updated that often. Even CPU microcode is updated more often than WiFi firmware, isn't it? And dasharo includes CPU microcode updates in firmware, doesn't it?

which are generally slower released than OS updates.

Agreed.

Old WiFi firmware still provide functionality, though, same as old CPU microcode versions.

In addition, the WiFi options are limited to the WiFi modules we use, which is a limitation for user freedom.

Can you explain more, what is limiting user freedom here?

I agree that it may be infeasible to include ALL possible WiFi firmware blobs in existance for size constraints, however including popular X200/X210 blob could be done as a first proof of concept. What are the size constraints, btw? And are we near reaching them?

With these points in mind, we cannot proceed with realising the feature request, unless this post gains popularity.

I understand, this is an exotic request and I'm sure there are many more popular features available to prioritize first. Would funding development of this feature be an option?

Thanks,
/Simon

[pietrushnic]

Thanks for bringing this up. Interesting! I feared there may be some fundamental problem preventing this from being possible to implement in any reasonable way. Such as the firmware uploader requiring a lot of functionality from the linux kernel or something similar.

@miczyg1 @krystian-hebel Wouldn't LinuxBoot be a payload to solve that issue? I think isolation below OS is a known thing already and beneficial for security, so maybe instead of constructing a LinuxBoot-based solution, isolation at the firmware level would be something usable. There were definitely some experiments with SMM and UEFI Boot Services.

That is okay by me. WiFi firmware blobs doesn't seem to be updated that often. Even CPU microcode is updated more often than WiFi firmware, isn't it?

I would say it happened very often since meltdown/spectre. We would have to compare to specific WiFi firmware, but I suspect it may be more often.

And dasharo includes CPU microcode updates in firmware, doesn't it?

Yes, when we do release.

I understand, this is an exotic request and I'm sure there are many more popular features available to prioritize first. Would funding development of this feature be an option?

It is always an option, but I don't know if it is economically feasible. One would have to figure out the design first, which is not clear from the discussion above, and then estimate the effort. Then, we would talk about real numbers and the potential for implementation.

[miczyg1]

Wouldn't LinuxBoot be a payload to solve that issue?

LinuxBoot, heads... Anything with Linux inside the payload probably.

[wessel-novacustom]

In addition, the WiFi options are limited to the WiFi modules we use, which is a limitation for user freedom.

Can you explain more, what is limiting user freedom here?

• Compatible WiFi modules would be limited to what we offer support for, other cards would no longer work.

The topic needs to gain popularity in the community to make it profitable to implement this. Having another payload will be quite some effort and has other disadvantages, such as no Windows support (probably?) and the lack of firmware settings (or at least limited options).

The efforts to support another payload are huge. I like the idea, but I think it's financially unfeasible :-(