I'm not an OpenBSD expert, but seems like you should be able to pass BT through USB and then do that in a subsystem or an isolated environment like a VM.
I use a Creative BT-W2 bluetooth usb dongle. Small and has a button on it for pairing. OpenBSD sees it as a normal audio device.
Yes, but this is exactly the point. And running OpenBSD is not a problem, until you run into a brick wall like this.
If you don't need it (and things like it), then that's all fine. As with everything, the last 10% takes 99% of the work, and code, and therefore contains about 99% of the security problems.
IIRC they were also very late to being able to run virtual machines, and even USB.
If you simply don't implement the things you don't need for a use case (e.g. a webserver) then that scales down to the fact that the compressor controller chip in your (dumb) fridge is not remotely exploitable too.
The Bluetooth Classic spec is indeed fairly awful, but the Bluetooth LE spec is not too bad. Plus, the entire specification is available free-of-charge, without even needing to register an account.
Bluetooth LE used to be limited to tiny accessories, but these days it supports nearly everything—I've completely disabled Bluetooth Classic on my (Linux) laptop because of how much of a disaster it is, but I'm still able to use my mouse and headphones over LE only.
> OpenBSD does not have kernel modules, so it’s either in or not.
But I'm assuming that not all kernel code is active at all times? Because it would seem odd to me if the amdgpu code was always active on something like a Raspberry Pi.
There are also architecture specific builds, so the aarch64 build won't include driver code at all for devices that are specific to x86.
It mostly a drivers tree that describe how to probe for hadrware. Like mainbus -> pci -> xhci -> usb -> uaudio -> audio.