anchao commented on PR #20686:
URL: https://github.com/apache/nuttx/pull/20686#issuecomment-6207056161
> Hi @anchao I think we need to evolve the NuttX BLE and although the
initial BLE stack used on NuttX is the same used on Zephyr that came from
Intel, I don't know if we should use the code from Zephyr. Or is it a rewrite
from scratch?
>
> I think for the size of this PR and the importance of this subject, I
suggest it should be better if you send first an email to the mailing list
explaining your proposal/approach.
>
> I think if we use code from Zephyr, the same CVEs which affect them will
affect us. And it will prevent the diversity protection (when a company uses
multiple RTOSs to avoid an single hacking put down all theirs devices).
@acassis
I agree that this is an important topic and probably deserves broader
discussion on the mailing list before we decide the long-term direction. I can
prepare a proposal email to explain the motivation, scope, current limitation,
and the
maintenance plan.
To clarify the approach: this is not a rewrite from scratch. The current PR
is a port/adaptation of the Zephyr Bluetooth host stack into NuttX, with a
NuttX compatibility layer for kernel primitives, work queues, timeout handling,
logging, settings, net_buf, iterable sections, and build integration.
The reason I took this approach is that the Bluetooth stack has evolved far
beyond a basic BLE host. Today, a practical Bluetooth host needs to cover much
more than GAP/GATT/ATT/SMP:
- BLE peripheral/central roles
- GATT services and clients
- BR/EDR Classic
- SDP/RFCOMM
- A2DP
- AVRCP
- HID/HFP/PBAP/MAP/BIP/OBEX/GOEP
- Bluetooth Mesh
- LE Audio
- BAP/CAP/PACS/ASCS
- VCP/MICP/CSIP/TBS/MCS/HAS/TMAP/GMAP/PBP and related profiles
Rebuilding all of this on top of the original NuttX BLE implementation would
be a very large multi-year effort. Even if we start from the existing NuttX BLE
code, we would still need to implement and maintain a large amount of profile
and protocol code that already exists and is actively used in Zephyr. My
concern is that evolving the original BLE-only implementation into a full
modern Bluetooth host stack may not be realistic with the current maintenance
capacity.
About the CVE concern: I think this is a valid point. If we import or derive
code from Zephyr, some vulnerabilities may also apply to the NuttX port. But I
think there are also trade-offs:
1. Reusing a mature and widely tested stack gives us a much broader feature
set and a better-tested protocol base than writing everything from scratch.
2. Known Zephyr Bluetooth CVEs become easier to track, because we can
monitor upstream fixes and apply the relevant ones to the NuttX port.
3. A from-scratch implementation would avoid sharing the exact same code,
but it would also introduce new implementation risks and would require
significant security review across a very large protocol surface.
4. The NuttX port is not intended to blindly expose Zephyr internals. The
compatibility layer is kept local to `net/bt`, and the public API is exposed
through the NuttX namespace. This gives us room to adapt, harden, and maintain
the integration in a NuttX-specific way.
So I think the main question is the trade-off between:
- keeping diversity by evolving an independent NuttX BLE stack, but with a
much smaller feature set and much higher implementation cost; or
- adopting a mature Bluetooth host stack as the base, accepting the need to
track upstream security fixes, but gaining Classic Bluetooth, Mesh, LE Audio,
and many profiles much earlier.
For the current PR, I also want to make the limitation explicit:
- Current support is limited to flat builds only.
- Protected/kernel builds are not supported yet.
- The current validation target is the simulator platform.
- The simulator test framework covers Classic Bluetooth and BLE paths.
- Support for protected/kernel builds is planned for 27Q2~4, and the related
profiles will be added to the libc build where needed.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
