Bluetooth mesh unsupported due to missing crypto modules

[andysan]

With the exception of some crypto drivers, the default Raspberry PI kernel has support for everything that is needed to use it with the new mesh daemon in Bluez. These modules are enabled by default on many other distributions. The following configuration options are missing:

CONFIG_CRYPTO_USER
CONFIG_CRYPTO_USER_API
CONFIG_CRYPTO_USER_API_AEAD
CONFIG_CRYPTO_USER_API_HASH

CONFIG_CRYPTO_AES
CONFIG_CRYPTO_CCM
CONFIG_CRYPTO_AEAD
CONFIG_CRYPTO_CMAC

For more information, see:

• https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/README#n64
• https://www.bluetooth.com/blog/bluez-on-raspberry-pi/

The requirements to get Bluetooth Mesh to work overlap with #3547.

[pelwell]

These modules are enabled by default on many other distributions.

Explain to us why we would want to enable Bluetooth Mesh? We've never been bothered about "keeping up with the Joneses".

[timg236]

It would be useful if you wanted a Pi to act as a gateway between an IP network and a Bluetooth mesh network e.g. a hub in a smart home/building network.
I Zigbee is already support out of the box.
Although, I think the OP needs to quantify any Kernel overhead from having this available but unused and report whether this works with the onboard Bluetooth which I didn't think supported Bluetooth Mesh

[andysan]

Mesh is just one use-case for these modules. The main reason to support Bluetooth Mesh is that the PI is a very good platform for IoT experimentation, especially the new boards that for Bluetooth 5.

Support for the user space crypto API (aka AF_ALG) is important for other applications as well. It's something of a best practice if you want to avoid leaking key material (mprotect-based strategies require root) since the kernel manages the keys and can prevent insecure operations such as swapping. Many crypto libraries, like OpenSSL and WolfSSL already support AF_ALG if the kernel supports it, so users of those libraries would benefit as well. The new iwd daemon requires it (#3547)

It's worth noting that the default configuration on the 5.4.y branch contains everything needed with the exception of CONFIG_CRYPTO_USER_API_HASH and CONFIG_CRYPTO_USER_API_AEAD. It would probably be a good idea to enable CONFIG_CRYPTO_USER_API_RND` as well. Adding these as modules shouldn't make much of a difference in terms of binary size or build time, but would enable several interesting use cases.

[andysan]

It would be useful if you wanted a Pi to act as a gateway between an IP network and a Bluetooth mesh network e.g. a hub in a smart home/building network.
I Zigbee is already support out of the box.
Although, I think the OP needs to quantify any Kernel overhead from having this available but unused and report whether this works with the onboard Bluetooth which I didn't think supported Bluetooth Mesh

The only hardware needed to support Bluetooth Mesh is a radio with support for Bluetooth 4.0, so all Pis with Bluetooth support already have the required hardware. Other than the crypto drivers, all the required Bluetooth functionality already exists in the kernel that ships with Raspbian.

There would be no runtime overhead if the functionality isn't used since all of the required functionality can be built as modules. The additional storage overhead is going to be negligible since the only missing pieces are the API options, all of the algorithms are already built in the default configuration.

If storage overhead is an issue, there is always the option to prune marginally useful modules like ATM (the network protocol) support or the classic PC game port (haven't seen those in a while).

[pelwell]

OK - you're starting to convince me. Put together a Pull Request with the config changes you'd like then we can give it the thumbs up (or down).

[andysan]

Providing a pull request will be complicated for non-technical reasons. :(

I just started to test a new kernel with the following additions to bcm2709_defconfig:

CONFIG_CRYPTO_USER_API_HASH=m
CONFIG_CRYPTO_USER_API_RNG=m
CONFIG_CRYPTO_USER_API_AEAD=m

Adding these options fixes the issue I had in the Bluez mesh daemon and probably fixes iwd, but I haven't verified the latter.

Assuming that the other Pi boards have similar configurations, I would expect that the same change could be applied across the board.

[pelwell]

Another PR added the USER_API_HASH module last week, so I've added the remaining two relatively small modules to complete the set. They will appear in future kernel builds.

[popcornmix]

Can you test rpi-update kernel and check if it has the features you need.

[ShaharHD]

Adding to the discussion here. When building the Zephyr HCI USB and connecting to a PC linux no issue, but when connected to a RPI device, the btmon report the followings:

= bluetoothd: Failed to open crypto                                                                                                                                                                                                                                                         
= bluetoothd: No Bluetooth address for index 0

Seems like the exact same issue.

[andysan]

Just tested the new kernel and I'm happy to report that it seems to work as expected.