[bug#49649] gnu: Add regulatory.db in %base-firmware.

* gnu/system.scm (%base-firmware): Add 'wireless-regdb'.
---
 gnu/system.scm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Following discussion at <https://issues.guix.gnu.org/49611>, tho there is
still an error about missing signature but now the kernel load the
regulatory.db without the help of userspace:

--8<---------------cut here---------------start------------->8---
# dmesg | grep -E '(cfg80211|regulatory)'
[    6.282015] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[    6.283766] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[    6.285927] platform regulatory.0: Direct firmware load for regulatory.db.p7s failed with error -2
[    6.285931] cfg80211: loaded regulatory.db is malformed or signature is missing/invalid
--8<---------------cut here---------------end--------------->8---

I'm wondering if it's worth removing 'crda' from the default udev rules.

Hi,

Brice Waegeneire <brice@waegenei.re> skribis:

> * gnu/system.scm (%base-firmware): Add 'wireless-regdb'.
> ---
>  gnu/system.scm | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> Following discussion at <https://issues.guix.gnu.org/49611>, tho there is
> still an error about missing signature but now the kernel load the
> regulatory.db without the help of userspace:
>
> # dmesg | grep -E '(cfg80211|regulatory)'
> [    6.282015] cfg80211: Loading compiled-in X.509 certificates for regulatory database
> [    6.283766] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
> [    6.285927] platform regulatory.0: Direct firmware load for regulatory.db.p7s failed with error -2
> [    6.285931] cfg80211: loaded regulatory.db is malformed or signature is missing/invalid
>

Does that means that the loaded ‘regulatory.db’ is discarded right away?
Or does it proceed anyway?

In the former case, looks like we’ll have to do some more work.

Could our ‘wireless-regdb’ build things from source, hopefully getting
the exact same binary as the one provided upstream, in which case it
could install the original signature as-is.  IOW, we’d be building from
source for the explicit purpose of making sure the upstream-provided
‘regulatory.bin’ file can be built reproducibly from this source.

> I'm wondering if it's worth removing 'crda' from the default udev rules.

It was added in 68ac258b5291aee33dd11a6fd0f545f81935b633 long ago, and I
think it made sense back then.  :-)

Do you think it’s now unnecessary because the kernel can load it all by
itself?  Or does that depend on kernel build options?

Thanks,
Ludo’.

Hello Ludo’,

Ludovic Courtès <ludo@gnu.org> writes:

>> # dmesg | grep -E '(cfg80211|regulatory)'
>> [    6.282015] cfg80211: Loading compiled-in X.509 certificates for regulatory database
>> [    6.283766] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
>> [    6.285927] platform regulatory.0: Direct firmware load for regulatory.db.p7s failed with error -2
>> [    6.285931] cfg80211: loaded regulatory.db is malformed or signature is missing/invalid
>>
>
> Does that means that the loaded ‘regulatory.db’ is discarded right away?
> Or does it proceed anyway?

I did more testing and you are right, in that case 'regulatory.db' isn't
loaded because it isn't signed correctly.

> In the former case, looks like we’ll have to do some more work.

We can either, bake the DB into the kernel at build time by replacing
the kernel's limited DB with the one from 'wireless-regdb' via the
option CONFIG_CFG80211_INTERNAL_REGDB¹. Or manage our own key, sign the
build database and add make the kernel load them as firmware file at
boot time, which is the usual way but would require a certain level off
work on or side.

> Could our ‘wireless-regdb’ build things from source, hopefully getting
> the exact same binary as the one provided upstream, in which case it
> could install the original signature as-is.  IOW, we’d be building from
> source for the explicit purpose of making sure the upstream-provided
> ‘regulatory.bin’ file can be built reproducibly from this source.

I didn't thought of that, I could give it a try as it should be lowest
hanging fruit.

>> I'm wondering if it's worth removing 'crda' from the default udev rules.
>
> It was added in 68ac258b5291aee33dd11a6fd0f545f81935b633 long ago, and I
> think it made sense back then.  :-)
>
> Do you think it’s now unnecessary because the kernel can load it all by
> itself?  Or does that depend on kernel build options?

After more testing, no.  We should keep it as default, it is needed if
you want to change you region from userland, with 'iw reg set' for
example.

I don't know how zelously we want to comply to radio frenquency
regulation by being sure our wireless devices don't emit on restricted
frenquecy between the kernel being loaded and userland (crda) setting
the correct region.  If we want to be sure such spourious emssions can't
happen we need to fix the loading of 'regulatory.db' by the kernel
otherwise the current setup should be good enought for most usage.

¹ https://cateee.net/lkddb/web-lkddb/CFG80211_INTERNAL_REGDB.html

Cheers,
- Brice

[Terse reply whilst travelling, but this stuff is extremely important to 
get right.]

Brice, Ludo',

Ludo's suggestion to leverage reproducibility sounds promising!

On 2021-07-20 23:02, Brice Waegeneire wrote:
> We can either, bake the DB into the kernel at build time

This hasn't been supported since 2015 (Linux ~4.14).

> I don't know how zelously we want to comply to radio frenquency
> regulation

Utterly.  Like our future software freedom depends on it.

Luckily, the kernel falls back to a copy of the world regulatory domain, 
the "00" that every Guix System user has been using forever.

> by being sure our wireless devices don't emit on restricted
> frenquecy between the kernel being loaded and userland (crda) setting
> the correct region.

CRDA is obsolete and only for use with the same legacy kernels.

> If we want to be sure such spourious emssions can't
> happen we need to fix the loading of 'regulatory.db' by the kernel

That's not true.  The whole point of the world regulatory domain is to 
be the subset of all other regdb entries.

Kind regards,

T G-R

Sent from a Web browser. Excuse or enjoy my brevity.

Hi!

Tobias Geerinckx-Rice <me@tobias.gr> skribis:

>> If we want to be sure such spourious emssions can't
>> happen we need to fix the loading of 'regulatory.db' by the kernel
>
> That's not true.  The whole point of the world regulatory domain is to
> be the subset of all other regdb entries.

In that case we have a practical interest in making db loading work, as
this would allow (some) users to use a wider part of the frequency
spectrum.

Thanks for looking into this, comrades!

Ludo’.

On 2021-07-23 11:11, Ludovic Courtès wrote:
> In that case we have a practical interest in making db loading work, as
> this would allow (some) users to use a wider part of the frequency
> spectrum.

Absolutely.  It's still important, just not someone-could-get-arrested 
urgent.  So I hope the bit-identical build works out.

Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

Hello Tobias, Ludo’,

Following Tobias corrections, I've extended the previous patch to correctly
enable loading of the wireless regulatory database ('regulatory.db') used by
the kernel subsystem cfg80211, for linux >4.14.  As suggested by Ludo, we now
build 'regulatory.db' ourselve to make sure it's reproducible and reuse
upstream signature.  That way the linux kernel correctly load the wireless
regulatory database at boot which allows us to use a regulatory domain
different than the "00" default by using a kernel argument such as
“cfg80211.ieee80211_regdom=FR“.

This patch doesn't change anything for kernels older than 4.15 for which the
use of CRDA is needed to load the regulatory database through the
'regulatory.bin' file.  IOW the database used by CRDA, is still unsigned and
CRDA doesn't check signatures for it.

Fixes <https://issues.guix.gnu.org/49611.

Cheers,
- Brice

Brice Waegeneire (4):
  gnu: Add regulatory.db in %base-firmware.
  gnu: wireless-regdb: Reuse 'regulatory.db' signature.
  gnu: wireless-regdb: Update to 2021.08.28.
  gnu: crda: Describe it as obsolete.

 gnu/packages/linux.scm | 81 ++++++++++++++++++++++--------------------
 gnu/system.scm         |  3 +-
 2 files changed, 44 insertions(+), 40 deletions(-)


base-commit: 1dfe8c372163d481ebebb97dd3b4cafa49906b28
prerequisite-patch-id: b07befb3646df543510b7fecf567286f53d4eaec

On Sat, Dec 25, 2021 at 07:44:18PM +0100, Brice Waegeneire wrote:
> Brice Waegeneire (4):
>   gnu: Add regulatory.db in %base-firmware.
>   gnu: wireless-regdb: Reuse 'regulatory.db' signature.
>   gnu: wireless-regdb: Update to 2021.08.28.
>   gnu: crda: Describe it as obsolete.

Works for me on 5.15.11, thanks!

Hi Brice,

Looks like this patch series was ready to go.

  https://issues.guix.gnu.org/49649

Could you push it?  If not, please let us know so one of us can do it on
your behalf; let us know if there are additional tests that should be
made beforehand, too.

TIA!

Ludo’.

Ludovic Courtès <ludo@gnu.org> skribis:

> Hi Brice,
>
> Brice Waegeneire <brice@waegenei.re> skribis:
>
>> Following Tobias corrections, I've extended the previous patch to correctly
>> enable loading of the wireless regulatory database ('regulatory.db') used by
>> the kernel subsystem cfg80211, for linux >4.14.  As suggested by Ludo, we now
>> build 'regulatory.db' ourselve to make sure it's reproducible and reuse
>> upstream signature.  That way the linux kernel correctly load the wireless
>> regulatory database at boot which allows us to use a regulatory domain
>> different than the "00" default by using a kernel argument such as
>> “cfg80211.ieee80211_regdom=FR“.
>
> Does that mean it’s up to users to add such an argument to
> ‘kernel-arguments’?  If so, we should probably document it (though
> that’s not a blocker for this series.)
>
>> This patch doesn't change anything for kernels older than 4.15 for which the
>> use of CRDA is needed to load the regulatory database through the
>> 'regulatory.bin' file.  IOW the database used by CRDA, is still unsigned and
>> CRDA doesn't check signatures for it.
>
> Sounds good.
>
> I haven’t actually tested it but the patch series LGTM!  It’s a much
> welcome improvement.
>
>> Fixes <https://issues.guix.gnu.org/49611.
>
> Make sure to add this line in the commit log of patch #2.
>
> Thank you!
>
> Ludo'.