chengkai15 commented on PR #20686: URL: https://github.com/apache/nuttx/pull/20686#issuecomment-6497081098
Hi, Let's take this discussion to GitHub. If you have any further comments, please reply on PR #20686 https://github.com/apache/nuttx/pull/20686. I won't be responding further on this mailing list. BRs, chao an ***@***.***> 于2026年10月29日周四 20:42写道： > Hi, Tomek, > > Let me put it this way: I'm not going to make promises or speeches about > security. Let's let actions do the talking. If PR #20686 > https://github.com/apache/nuttx/pull/20686 gets merged, I will take > ownership of all CVE issues related to this code going forward. Would that > work for you? > > BRs, > > Tomek CEDRO ***@***.***> 于2026年10月29日周四 20:36写道： > >> No Anchao, we have long backlog of security issues which are handled >> by usually one or two overwhelmed people, your single help is most >> welcome and appreciated, but it was not here for last ~2 years, and >> this is real problem for us, thus Alan as the one who reported and >> fixed the security issues recently can use this as an argument, >> because he knows how the process looks like himself. >> >> Here are hints on how to approach: >> https://nuttx.apache.org/docs/latest/security.html >> >> In my other reply I also mentioned security and maintenance as the >> weak points of your approach - to take someone else code and then >> maintain it yourself forever - other people also tell you this is not >> the good way.. only you seem not to notice it sorry. >> >> -- >> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >> >> On Thu, Oct 29, 2026 at 1:29 PM chao an ***@***.***> wrote: >> > >> > Alin, >> > >> > Apologies, >> > >> > Alan, I've spent a lot of time and sent many emails on this topic over >> the >> > past days, and I find the discussion keeps circling back to points that >> I >> > thought were already addressed. No one seems to be engaging with the >> actual >> > question of how to move NuttX's Bluetooth support forward. I'd >> appreciate >> > it if we could stop revisiting the CVE argument — security is an ongoing >> > responsibility for any code we maintain, and it's not unique to this >> > contribution. >> > >> > BRs, >> > >> > Alin Jerpelea ***@***.***> 于2026年10月29日周四 20:22写道： >> > >> > > Hi, >> > > >> > > please remember that the patches for CVE should not be disclosed >> until they >> > > are part of a release >> > > This is a public mailing list ! >> > > >> > > Bets regards >> > > Alin >> > > >> > > On Thu, Oct 29, 2026 at 1:13 PM chao an ***@***.***> wrote: >> > > >> > > > Alan, >> > > > >> > > > First, I need to clarify an important point: Xiaomi's zblue >> approach is >> > > > completely different from what I submitted in PR #20686 >> > > > https://github.com/apache/nuttx/pull/20686. Xiaomi's version keeps >> > > > Zephyr's >> > > > original headers and coding style largely intact, whereas my >> libs/zblue >> > > > submission is fully adapted for NuttX — headers restructured to >> > > > include/nuttx/net/bluetooth/, OS adaptation layer integrated, and >> the >> > > > entire tree reorganized to fit NuttX's build system. They are not >> the >> > > same >> > > > technical approach. >> > > > >> > > > I've already laid out the advantages of having the protocol stack >> in-tree >> > > > in PR #20686 — build integration, API cohesion, OS-level >> optimization >> > > > opportunities, and avoiding the friction of out-of-tree maintenance. >> > > > Reading your latest reply, I have to be honest: I'm disappointed, >> because >> > > > it feels like you haven't really engaged with what I was saying >> there. >> > > > >> > > > Regarding security — you keep raising this concern, and I want to >> address >> > > > it directly. Security issues are solvable. I don't just say this in >> the >> > > > abstract — I'm currently fixing 9 security vulnerabilities across >> NuttX's >> > > > networking and USB subsystems: >> > > > >> > > > 1. IPv6 extension-header out-of-bounds read — #20885 >> > > > https://github.com/apache/nuttx/pull/20885 >> > > > 2. MLDv2 report record-count out-of-bounds read — #20886 >> > > > https://github.com/apache/nuttx/pull/20886 >> > > > 3. ICMPv6 Router Advertisement prefix option out-of-bounds read — >> > > #20888 >> > > > https://github.com/apache/nuttx/pull/20888 >> > > > 4. USB host config-descriptor walk out-of-bounds read and >> infinite >> > > loop >> > > > — #21101 https://github.com/apache/nuttx/pull/21101 >> > > > 5. USB host composite copyinterface heap buffer overflow — #21101 >> > > > https://github.com/apache/nuttx/pull/21101 >> > > > 6. USB host composite member array out-of-bounds write — #21101 >> > > > https://github.com/apache/nuttx/pull/21101 >> > > > 7. CDC-MBIM NCM frame NDP/DPE walk out-of-bounds read and >> infinite >> > > loop >> > > > — #20884 https://github.com/apache/nuttx/pull/20884 >> > > > 8. USB mass-storage zero block size divide-by-zero in partition >> scan — >> > > > #21101 https://github.com/apache/nuttx/pull/21101 >> > > > 9. CDC-MBIM transmit divide-by-zero on zero bulk max packet size >> — >> > > > #20884 https://github.com/apache/nuttx/pull/20884 >> > > > >> > > > These are all in NuttX's own native code — networking, USB host, >> CDC — >> > > > subsystems I've worked on extensively. A CVE in any of these would >> > > likewise >> > > > disrupt devices in the field. Security is a universal concern for >> every >> > > > line of code we ship, regardless of its origin. We deal with it >> through >> > > > review, testing, and prompt fixes — exactly what I'm doing here. I >> > > > genuinely don't understand why you keep bringing this up as if it >> were >> > > > unique to zblue. >> > > > >> > > > >> > > > BRs, >> > > > >> > > > Alan C. Assis ***@***.***> 于2026年10月29日周四 19:38写道： >> > > > >> > > > > Hi Anchao and Chengkai, >> > > > > >> > > > > Thank you for moving this discussion forward. >> > > > > >> > > > > I think the agreement that NuttX should have only one Bluetooth >> stack >> > > > (the >> > > > > Zephyr ZBlue stack) is not universally agreed upon, as we saw in >> the PR >> > > > > discussions. >> > > > > >> > > > > If NuttX selects only one BLE stack it should be its own stack >> (which >> > > is >> > > > > very limited currently and not a feasible option at this moment). >> > > > > >> > > > > Moving zblue to nuttx-apps and making it just an option like the >> NimBLE >> > > > > appears to be the right thing to do. >> > > > > >> > > > > It could be the stack that most people will use (instead of >> NimBLE or >> > > the >> > > > > native one), but it shouldn't be the only option because it shares >> > > almost >> > > > > 1M LoC from Zephyr and poses a huge security risk due to the >> > > monoculture >> > > > > effect: a CVE found on Zephyr ZBlue would disrupt all their >> devices on >> > > > the >> > > > > field and also all NuttX devices using zblue. >> > > > > >> > > > > Imagine if Windows were open-source and someone in the Linux >> community >> > > > > decided to use the Windows windowing subsystem. It would make it >> very >> > > > easy >> > > > > for vendors to implement graphical applications for both Windows >> and >> > > > Linux, >> > > > > but any vulnerability found in Windows would affect Linux. That is >> > > > > basically the scenario here for NuttX. >> > > > > >> > > > > As I said I like the idea of having the option to use a Bluetooth >> stack >> > > > > like zblue until we evolve our own stack. >> > > > > >> > > > > BR, >> > > > > >> > > > > Alan >> > > > > >> > > > > On Thu, Oct 29, 2026 at 3:51 AM chao an ***@***.***> >> wrote: >> > > > > >> > > > > > Hi Chengkai, >> > > > > > >> > > > > > >> > > > > > >> > > > > > Thanks for the clarification. >> > > > > > >> > > > > > >> > > > > > >> > > > > > For question 1, by "NuttX-native integration" I mean more than >> only >> > > > > > Kconfig, >> > > > > > build glue, driver binding, and public headers. I think the >> > > > > Zephyr-derived >> > > > > > >> > > > > > Bluetooth host should be adapted into a NuttX-maintained stack, >> with >> > > a >> > > > > > >> > > > > > structure that can evolve toward the NuttX kernel/socket >> > > architecture. >> > > > > > >> > > > > > >> > > > > > >> > > > > > If we only keep the Zephyr Bluetooth source almost untouched >> and add >> > > a >> > > > > > large >> > > > > > compatibility layer around it, then I do not think that is the >> right >> > > > > > long-term >> > > > > > direction for the official NuttX Bluetooth architecture. >> > > > > > >> > > > > > >> > > > > > >> > > > > > For question 2, I think NimBLE and Zephyr Bluetooth are >> different >> > > > cases. >> > > > > > >> > > > > > NimBLE officially provides an OS abstraction layer, so each OS >> can >> > > > > > integrate it >> > > > > > through its own OSAL. Zephyr Bluetooth does not provide the >> same OSAL >> > > > > > boundary; >> > > > > > it is deeply tied to the Zephyr kernel model. >> > > > > > >> > > > > > >> > > > > > >> > > > > > That means zblue needs many Zephyr kernel API/header >> compatibility >> > > > > pieces: >> > > > > > >> > > > > > kernel objects, work queues, timers, buffers, iterable >> sections, and >> > > > > other >> > > > > > >> > > > > > Zephyr-style assumptions. Even if placed in nuttx-apps, it is >> not >> > > > really >> > > > > a >> > > > > > >> > > > > > clean standalone userspace library like NimBLE. >> > > > > > >> > > > > > >> > > > > > >> > > > > > My main concern is the long-term roadmap. If we preserve an >> almost >> > > > > > unmodified >> > > > > > Zephyr Bluetooth tree, then moving L2CAP and lower layers into >> the >> > > > NuttX >> > > > > > >> > > > > > kernel later will be very difficult, because L2CAP is tightly >> coupled >> > > > > with >> > > > > > >> > > > > > connection management, buffers, work queues, ATT/SMP, and the >> Zephyr >> > > > > > execution >> > > > > > model. That migration may become close to a second rewrite. >> > > > > > >> > > > > > >> > > > > > >> > > > > > This is different from the current libs/zblue PR, where the >> stack is >> > > > > > already >> > > > > > treated as NuttX-maintained code and can diverge from Zephyr >> where >> > > the >> > > > > > NuttX >> > > > > > architecture requires it. >> > > > > > >> > > > > > >> > > > > > >> > > > > > So my concern is not only external repo vs in-tree. The bigger >> > > concern >> > > > is >> > > > > > >> > > > > > whether we are building a real NuttX Bluetooth architecture, or >> > > mainly >> > > > > > keeping >> > > > > > a Zephyr runtime compatibility layer around the Zephyr Bluetooth >> > > stack. >> > > > > > >> > > > > > >> > > > > > >> > > > > > I agree this should be decided by the community, but my >> preference is >> > > > > still >> > > > > > to >> > > > > > adapt the code into a NuttX-native stack first, then submit it >> > > directly >> > > > > to >> > > > > > >> > > > > > nuttx.git or nuttx-apps.git depending on the agreed layering. >> > > > > > >> > > > > > BRs, >> > > > > > >> > > > > > 成凯 via dev ***@***.***> 于2026年10月29日周四 14:38写道： >> > > > > > >> > > > > > > hi anchao >> > > > > > > >> > > > > > > Thanks, good to see we are aligned on the direction. >> > > > > > > >> > > > > > > On open point 2, I think the difference is mainly about the >> > > starting >> > > > > > point, >> > > > > > > not the end state. We agree the stack should end up reviewed, >> built >> > > > and >> > > > > > > tested as part of the NuttX repositories. Step 3 of the plan >> > > already >> > > > > > allows >> > > > > > > moving the userspace part into nuttx-apps.git. >> > > > > > > >> > > > > > > Two things I would like to understand better: >> > > > > > > >> > > > > > > 1. By "NuttX-style public headers" and "native integration", >> do you >> > > > > mean >> > > > > > > reformatting the Zephyr-derived code to nxstyle, or only >> the >> > > NuttX >> > > > > > glue >> > > > > > > (Kconfig, build, driver binding, public API headers)? We >> are >> > > fine >> > > > > with >> > > > > > > the >> > > > > > > latter. The former makes picking up upstream fixes much >> harder, >> > > > > which >> > > > > > is >> > > > > > > our main concern. >> > > > > > > 2. NimBLE is already integrated this way (download at a pinned >> > > > > revision). >> > > > > > > Could you share which specific dependency or maintenance >> issues >> > > > you >> > > > > > are >> > > > > > > worried about? That would help us address them in the >> design. >> > > > > > > >> > > > > > > Since this is a project-level decision, I would like to hear >> from >> > > the >> > > > > PMC >> > > > > > > and everyone who has reviewed PR #20686 -- Xiang Xiao, Alan >> > > Carvalho >> > > > de >> > > > > > > Assis, Alin Jerpelea, raiden00pl, Tomasz CEDRO (cederom), >> LingaoM >> > > and >> > > > > > > casaroli -- on whether to start with a pinned external >> repository >> > > or >> > > > > with >> > > > > > > in-tree code. We will follow the community's decision. >> > > > > > > >> > > > > > > Best regards, >> > > > > > > Kai Cheng >> > > > > > > >> > > > > > > >> > > > > > > ________________________________ >> > > > > > > From: archer ***@***.***> >> > > > > > > Sent: Thursday, October 29, 2026 12:19 PM >> > > > > > > To: apache/nuttx >> > > > > > > Cc: 成凯; Mention >> > > > > > > Subject: [External Mail]Re: [apache/nuttx] net/bt: Add native >> > > > Bluetooth >> > > > > > > host stack (PR #20686) >> > > > > > > >> > > > > > > >> > > > > > > [外部邮件] ***@***.*** >> 进行反馈 >> > > > > > > >> > > > > > > [ >> https://avatars.githubusercontent.com/u/758493?s=20&v=4]anchao >> > > > left a >> > > > > > > comment (apache/nuttx#20686)< >> > > > > > > >> https://github.com/apache/nuttx/pull/20686#issuecomment-6487811997 >> > > > >> > > > > > > >> > > > > > > @chengkai15<https://github.com/chengkai15> >> > > > > > > >> > > > > > > Thanks for the clarification. I think we are mostly aligned >> on the >> > > > > > > long-term direction, especially about converging to one >> > > Zephyr-based >> > > > > > > Bluetooth host and moving toward a BlueZ/Linux-style split for >> > > > > > > protected/kernel builds. >> > > > > > > >> > > > > > > For open point 2, I still prefer not to start from an external >> > > > > repository >> > > > > > > model in the main NuttX integration path. >> > > > > > > >> > > > > > > My suggestion is that the code should first be adapted into a >> > > > > > NuttX-native >> > > > > > > integration style, and then submitted directly to either >> nuttx.git >> > > or >> > > > > > > nuttx-apps.git, depending on the agreed layering. Fetching a >> large >> > > > > > external >> > > > > > > repository at build time will also bring dependency and >> maintenance >> > > > > > issues >> > > > > > > with other third-party code, and I do not think that is the >> best >> > > > > > long-term >> > > > > > > integration model for an official NuttX Bluetooth stack. >> > > > > > > >> > > > > > > In my view, if the stack is going to become part of the NuttX >> > > > Bluetooth >> > > > > > > architecture, it should be reviewed, built, tested, and >> maintained >> > > as >> > > > > > part >> > > > > > > of the NuttX repositories, not as an external component that >> is >> > > only >> > > > > > pinned >> > > > > > > by revision. >> > > > > > > >> > > > > > > Maybe you can use the current PR as a reference for the >> > > NuttX-native >> > > > > > > integration structure: top-level CONFIG_ZBLUE_ENABLED, NuttX >> > > > > > build/Kconfig >> > > > > > > integration, NuttX-style public headers, and direct >> integration >> > > with >> > > > > the >> > > > > > > NuttX Bluetooth driver path. The implementation details can >> > > certainly >> > > > > be >> > > > > > > changed, but I think this kind of native integration is a >> better >> > > > > > direction >> > > > > > > than relying on an external fetched repository. >> > > > > > > >> > > > > > > If the openvela version is adjusted in this direction and >> accepted >> > > by >> > > > > the >> > > > > > > community as the common upstream solution, I am willing to >> drop my >> > > > > > current >> > > > > > > PR and help with that effort. My goal is not to keep my own >> patch, >> > > > but >> > > > > to >> > > > > > > help NuttX get a complete and maintainable Bluetooth stack. >> > > > > > > >> > > > > > > — >> > > > > > > Reply to this email directly, view it on GitHub< >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> https://github.com/apache/nuttx/pull/20686?email_source=notifications&email_token=ABDILOITAS5PRPRBASVZXOD5WLAN7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMNBYG44DCMJZHE32M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-6487811997 >> > > > > > >, >> > > > > > > or unsubscribe< >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> https://github.com/notifications/unsubscribe-auth/ABDILONP3W2NPDI7EX4JEGT5WLAN7AVCNFSNUABFKJSXA33TNF2G64TZHMZDEOBRGAZTENZTHNEXG43VMU5TKOBWG4ZTIMBYG4Z2C5QC >> > > > > > > >. >> > > > > > > You are receiving this because you were mentioned.Message ID: >> > > > > > > ***@***.***> >> > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> #/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ >> > > > > > > This e-mail and its attachments contain confidential >> information >> > > from >> > > > > > > XIAOMI, which is intended only for the person or entity whose >> > > address >> > > > > is >> > > > > > > listed above. Any use of the information contained herein in >> any >> > > way >> > > > > > > (including, but not limited to, total or partial disclosure, >> > > > > > reproduction, >> > > > > > > or dissemination) by persons other than the intended >> recipient(s) >> > > is >> > > > > > > prohibited. If you receive this e-mail in error, please >> notify the >> > > > > sender >> > > > > > > by phone or email immediately and delete it!******/# >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > -- 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]
