On Tue, Jan 05, 2021 at 12:37:38PM -0500, Christopher Friedt wrote: > Hi Alex & all. > > Happy New Year, and thanks for all of the advice :-) > > I ended up taking it and am using TLS for authentication and > encryption. Standards are nice. > > Both one-way authentication (similar to HTTPS) and mutual > authentication (similar to SSH public key) are supported now between > Zephyr[1] and Gbridge[2]. > > On Sat, Nov 7, 2020 at 12:33 PM Alex Elder <elder@xxxxxxxxxx> wrote: > > > > On 9/11/20 8:52 AM, Christopher Friedt wrote: > > I also concur with Greg's questions about why you feel > > these things need to be incorporated *into* Greybus, rather > > than set up *around* Greybus somehow. On Project Ara, the > > I would also concur at this point. My original changes were mostly > doing the same thing that TLS does but just in a non-standard way. > Originally, it was just a proof of concept for the client due to > underspecification, but TLS just makes way more sense. > > I've used Zephyr's TLS extensions for the socket API and OpenSSL > on the Linux side. So it's pretty clean and also very testable. > > There are no changes required to the Greybus spec so that works as-is, > and encryption is kept as a transport-layer option. For gbridge, it's > a separate logical transport and can be used independently of > plain-text TCP/IP too. The service is advertised using > "_greybuss._tcp" rather than "_greybus._tcp". Nice, that sounds very reasonable. > Quite a number of features were added to Zephyr to support this, including > > * DNS-SD (and slight modification of the existing mDNS impl) > * aligned heap allocators > * dynamic pthread stack support > * some minor bugfixes to TCP > * some driver support for the physical layer (IEEE 802.15.4, BLE) > * a forthcoming template for external modules Hey, even better, Zephyr is benefiting from this, great work. > The fact that gbridge uses a separate socket per CPort (although kind > of nice conceptually) does have a non-negligable impact on > memory-constrained devices though. In what way? Is this because a socket has a lot of memory state needed, or is this some other greybus overhead? > That impact is exacerbated when TLS is thrown into the mix. I've added > another pair of tickets to concentrate all traffic into a single socket > connection like what is currently done for the UART transport. That reduces > not only the memory required per socket, but also the duplication of TLS > resources on a per-socket basis (especially when mutual auth is used). A future > change for gbridge and Linux might be to move socket I/O to the kernel > after TLS auth + AES is set up. That was out of scope for my existing > contract, but it would be "interesting" to implement. > > At this point, my Greybus for Zephyr module is alpha ready. It works > over UART, but also any other transport that supports TCP/IP such as > Ethernet, WiFi, BLE, 802.15.4 (both 2.4 GHz and Sub GHz), CAN > (although that's untested). Still lots of work to be done (like > support for different Greybus protocols), but it's quite usable for > GPIO, I2C, and SPI now ;-) Any Linux kernel-side changes needed for any of this? I am interested in getting the remaining greybus code out of staging this year, as there's no good reason for it to be hanging around with no real development happening. If there's anything left to be done on the Linux portion, that would be good to know, otherwise I think we'll just start moving indivdual drivers out of staging slowly... thanks, greg k-h _______________________________________________ greybus-dev mailing list greybus-dev@xxxxxxxxxxxxxxxx https://lists.linaro.org/mailman/listinfo/greybus-dev
|