 So I'm Gil Pitney, I'm from Texas Instruments, and I'm also an assignee into the, into Lenaro and the light team, the Lenaro Internet of Things and Embedded team. We're working on getting ARM platforms well supported into the Zephyr project, being from TI of course, getting the TI platforms into Zephyr specifically. I've been working on one of our SOCs that's a CC3220 ASF which deals with, which offloads Wi-Fi onto a coprocessor from the MCU, the MCU running Zephyr coprocessor running a different operating system. So the motivation for this work is we, as I said, we have the simple link family of MCUs that has a SOC which also has an SDK, and it completely offloads the Wi-Fi stack onto an integrated network processor, and NWP is the network coprocessor. So the reason for doing this makes it easier to integrate Wi-Fi into your solution. It offloads the memory, the power management, everything onto this coprocessor. All the security and secure communications is also offloaded and it's in a separate processor, so it's in some address space so it can't be accessed, fiddled with from the MCU, running possibly not secure stuff. And the current simple link SDK supports the TI RTOS, TI's own real-time operating system and free RTOS, but is designed, the software architecture is designed to be portable to other OSs, which allowed me to port this to Zephyr. And so the Zephyr networking stack, assume that people have already a little familiar with Zephyr here, I'll mainly be talking about the networking stack. It already has support for Wi-Fi via an offload tap for the data and some Wi-Fi control plane APIs. And recently Zephyr has added support for TLS security into the VSD socket APIs, which measures well with the TI simple link design, we kind of do the same kind of thing. And the goal here is to efficiently integrate the simple link offload capabilities into Zephyr, but also while leveraging Zephyr's upcoming socket-based networking protocol. So, yeah, all this work was done on the CC3220 SF Launch XL development board, which is a development board from TI. Okay, so what I'm going to be doing is, and the rest of the talk is talking about the hardware architecture and software architecture of simple link of the chip. I'll talk a bit about Zephyr and the networking stack as it pertains to this integration. Keeping in mind that the networking stack in Zephyr has undergone quite a bit of evolution in the past year or so since I've been working on this. So I'll show you sort of a before and after picture of the networking stack as it's evolved to the point where it's allowed this offload to work very efficiently. So the hardware architecture basically, this is a very high level, but so this is the SOC, as I said, it's an MCU, it's a 80 MHz Cortex-M4 with 256K of RAM, SRAM, a megabyte of flashes. There's a secure flash also, four megabytes that holds secrets, assets there to be protected. There's a network co-processor, part of the SOC. The communication between the MCU and the network processor is through a dedicated spy connection. And the network processor is what talks to the internet. So this is, did I do something? This is a Wi-Fi chip, so it has all the Wi-Fi lower layer stuff, physical, radio, baseband, supplicant, all that on the network co-processor, a separate address space from the MCU. It also includes complete TCP IP stack is on the network co-processor. Also, security is handled on the co-processor, so SSL, handshake, ciphers, crypto through hardware accelerators, often hardware accelerators are there to accelerate the crypto. And there's even an HTTPS secure server, web server that lives on the co-processor. So there's a lot of stuff that's offloaded onto the co-processor, including there's power management policies you can set for the co-processor so that it handles power management so it can go to sleep when nothing's happening. It can keep sessions open and go to sleep and wake up when a packet comes in. So that's all handled transparently on this co-processor. There are a lot of security features of this chip that ensure that people can't say fiddle with the application that you've delivered. So there's a secure boot that if this flash were to change, it checks the hash against what's been programmed as the factory image on the production line. And if it's different, then it will load from here so someone can't insert some new code unbeknownst to the device. There's advice keys that are used for verification and encryption of service packs that have the firmware that update the network processor. All the certificates used in the TLS handshake are keys, private keys are stored on secure flash in the file system, which is accessible by the network processor. Of course Wi-Fi itself has security that supports WPA, personal security and enterprise security. And there's a lot more security features that there's pages and pages of security features in the TRM which exercise for the reader. So software architecture, so a simple leak. As I said, it's a family of processors. I'm talking about Wi-Fi but there's also Bluetooth low energy, some gigahertz. So this is just the Wi-Fi. I'm talking about the SoC at 3220. There's also, you can just buy the network code processor and hook it up to another MCU of your choice, ARM MCU of your choice. I guess it doesn't have to be ARM. And this SDK comes with all the APIs that allow easy access to the code on the network code processor for doing basically control and data plane stuff. So a couple of key points. So there's a little, a thin OS abstraction layer that allows the host driver. It's called the host driver which is basically the device driver that interfaces with the co-processor to be ported to another OS. And as I said before, it's currently supporting TI's stable production worthy RTOS and also free RTOS. And so I would basically use this layer to port this to Zephyr without too much effort. So the other thing that's worth noting is in order to allow this to be used in other applications, naturally for the data communications, TI chose to export, use a standard Socket API, so POSIX APIs. So for the Sockets, that's the way to get communications. And to handle secure communications, they've put the TLS as part of the Socket API. So normally in a lot of applications, TLS is a wrapper, is on top of the Socket APIs. In this design, TLS is sort of embedded in the Socket APIs. And I'll talk more about that later and show you an example of how that's working. So that's the simple link SOCE architecture in a high level. And so we want to integrate this into Zephyr. So this is sort of a high level picture of the networking stack. So basically, let's start from the top. So there are Zephyr networking protocols like WebSock and QTT, LWM2M, DNS, HP, S&P, typical networking protocols that are built on top of the API that Zephyr supports for communication. So this is sort of a previous state, but a current state, minus some new additions. There is an API called NetContext, which is sort of like a Socket API, but it's called back base, it's not synchronous. So which works well with a lot of these asynchronous protocols. Callbacks go back into the networking protocols, passing network buffers, network packets that need to be parsed. There are linked lists of fragments of buffers that you need to parse through. And on top of that, there is an API called NetApp, which is sort of a convenience API, which helps with some of the client server setups, say static IP setting, and also mainly handling the TLS support. So Zephyr is using embed TLS as the TLS library. There are many other libraries, there's Polar, SSL, OpenSSL, WolfSSL. But this is the one that's used by Zephyr. And that provides all the hard work of doing the TLS handshake for setting up secure communication channels. And that's based on NetContext, which is, like I said, a socket-like API. But it's a non-standard API. So some of the discussion over time has been, well, we'd like to be able to support protocols, third-party protocols coming in that are based on sockets. A lot of vendors like TI create their value by giving something that can be easily integrated into other systems and what's better than having something that's a standard API or something that's closer to a standard API. So this was a bit of a rub. And then over time, it was determined stakeholder input, you know, so, well, we want more positive APIs. And so the BSD socket API was added to Zephyr under the name Zsoc. And over that, there were some samples. And MicroPython, ModSocket was written so that you can use that. So this is sort of how things are moving more towards sockets and away from NetContext. There's also, in the networking stack, a management subsystem which handles callbacks from lower layers, from drivers that, say, connect to, say, an IP address established through DHCP. A callback will come that, yeah, we have an IPv4 address and that can be sent back up to NetApp or other applications as a notification. So the actual IP stack, the TCP IP stack is built on a network interface and then there's various technologies under the L2 interface for Ethernet, 802, 15.4 Bluetooth. The point is there is no real technology for Wi-Fi built into Zephyr. The idea was that the plan has been to support Wi-Fi via offload chips and via a tap from this NetContext level through a configuration option. So it basically vector communication through NetContext to your TCP IP offload engine which could be running on a coprocessor, typically on a coprocessor. And so that's the plan. So there are no Wi-Fi L2 drivers currently. There's no Wi-Fi supplicant in Zephyr or provisioning support yet. The plan is, as I said, to support things through offload, an offload tap. And again, secure communications are provided through this NVIDIA TLS library. So when we look at this, this is the state, and looking at how we would integrate our network coprocessor into this, there's various options we can take. One is we could just, well like I said, SimpleLink has an SDK, has a whole set of APIs. You could just, in Zephyr write an application that, as I said, the SDK was ported to Zephyr. In fact, the SDK is part of the Zephyr tree. It's imported as one of the EXT slash HAL TI external libraries. You could just include the SimpleLink SDK headers, SimpleLink.h and syssocket.h, and then use all of the control and data APIs that SimpleLink provides to use Zephyr for sensors and other device drivers that are not networking-related. So the advantage there is you get full access of the SimpleLink capabilities, full hardware entitlement. You can still use Zephyr drivers, as I said. The cons are it doesn't really integrate very well with Zephyr with event management, and it doesn't really leverage the Zephyr's socket-based protocols that will be coming up. Yeah, you can go into the Zephyr protocol code and switch if def TI stuff, use ours, but you really don't want to do that. It would be nice to, out of the box, be able to use the Zephyr protocols with our stuff through some kind of an offload tab. The other option is to go down to this level here and write an L2 driver, a low-level driver, using send-receive calls. SimpleLink has a raw socket mode called a transceiver mode at a very low level. You could write something like that. That would hook deeply into the Zephyr core, so it would enable some features that Zephyr would like to have, like rooting packets between network interfaces. But this doesn't really leverage what TI is providing, so you're not really getting the hardware entitlement of this network processor because it's not offloading all the network buffer queuing and management that the network processor is doing. It's duplicating it. The DHCP, the DNS is not getting offloaded. It's going to be done in Zephyr. And the security is being done by embed TLS, not by us, or not by the network processor. So, you know, why buy the chip in that case? The other option is offloader that net context level. And that's pretty good. That does offload the TCP IP stack. That's at this level. But it doesn't offload the security. So, this will be using embed TLS. But the security that we handle is not being used. There's some other issues in using that, and that is that there's some overhead mapping between the Zephyr socket APIs to the network, asynchronous callback-based network context of APIs and back to the synchronous socket APIs. Data that's received from the network processor has to be copied into another network buffer structure and cued. And there's typically a driver thread that needs to select sockets that are available and trigger callbacks into the net context, asynchronous callback-based stack. So, there's some overhead in using this solution. And as I said, the main thing is the TLS handshake and all the crypto is not offloaded in this case. So, it seems natural to, well, just offload at this socket layer. That's another option, which has recently been added into Zephyr. And the way that's enabled is you define a net socket offload configuration option and then all the calls through sockets get offloaded to the socket APIs provided by the SimpleLink driver. So, here we have a Wi-Fi driver that basically provides socket operations into Zephyr and this is kind of inspired by the same solution that's in Minute, another IOTOS. And it's actually very simple to implement. And so, the pros here is it avoids all the overheads of the previous option, option three. Secure communications are fully offloaded. DNS is offloaded to via get address info hook. The only cons currently is that there's only one socket provider allowed in the system and no packet routing across net interfaces. Well, for our use case, it doesn't matter so much. We typically have devices that are connected to an AP and they send up data periodically to one access point and there's really no packet routing across network interfaces. So, this is how, so this is the option we choose for SimpleLink and this is how it looks now. So, we have TLS, so some other changes that have happened since that previous networking stack slide is in Zephyr TLS is also being handled at the socket layer. There's some recent APIs that have allowed this to happen through some setsockopt APIs and a new protocol family that's sent into the socket call. There is this new offload tap that allows offloading at the socket layer as well as this layer here for those that are not having to worry about or find have security done on the MCU. So, these are Wi-Fi drivers, these are actual device drivers and each one of them has a control interface currently for Wi-Fi. So, a new Wi-Fi management module has been developed that allows scan, disconnect and callbacks into the Wi-Fi management system when a connection occurs, disconnection occurs, or scan results come back from these drivers. And there's an initialization of the interface, the network interface which sets up the co-processor defaults, wireless LAN defaults, like the station mode, the station or access point mode, network parameters like lease times, stuff like that. Right now that's all set up just by defaulting values in the Wi-Fi drivers. There's no extra control plane APIs right now to set that up in Zephyr. That's probably something that will be needed in the future. And the other big thing that's changing is these protocols which were previously written to the NetApp and NetContext API are being rewritten to the socket API. So that's just happening. There are a couple of PRs for MQTT and Lightweight M2M that are in play and going through the birthing pains of getting it working on sockets and linear buffers and moving away from net packet and things like that. So that's sort of where it's going. So I mentioned that TLS is being added to the socket APIs. So why is this being done? So there was a lot of debate on this. The motivation is that TLS is hard to get right. Depending on what TLS library use, there are many APIs, configuration options. The idea is to try to make it easy to add TLS to non-secure socket-based networking applications and protocols. Someone who's not familiar, I'm not that familiar with security as well, but if you're not that familiar with it and you see all these configuration options, you got to do a lot of reading, you might choose some wrong settings that actually make your application insecure. So for example, adding TLS to a networking app with Embed TLS involves these various steps, creation of contacts, registration of your entropy generator, setting up certificates, configuring the SSL layer for what it does, the handshake. You create the socket and then call Embed TLS APIs for Connect, which does the handshake and reading and writing and then tear it out of contacts. Now admittedly that's not that bad. It's probably better than some other APIs, but we could do better. Zephyr wrapped all this with NetApp, but we'd like to also leverage standard APIs, like the VSD socket APIs, because people are familiar with NetApp, they're not familiar with NetContext. So more details on what's involved in establishing a secure channel. This is the TLS handshake. So you first need to have your certificates and keys stored provision somewhere in your secure flash, ideally secure. You don't want this really sitting in RAM, especially your private keys. In the case of TI, TI has a catalog of trusted root CA certificates. So if a root certificate comes in that's not known, it'll give you a warning in error, which you can ignore, I suppose. But it checks the time and date stamp and gives you an error. The handshake starts with the sort of hello messages that the client sends to the server, the TLS version it's dealing with, the cipher suites it can support, the server selects a cipher suite and then the server sends a certificate, gets verified by the client, then there's an optional verification of the client by the server and then at some point they determine a secret session key that they use to encrypt the communication from then on. And so quite a bit involved, the state machines involved in setting up a secure communication. So I mentioned that the certificates and keys should be provisioned to the device, by provisioning the enemy, basically burnt to a flash. And the secret should be kept secure from the non-secure apps. So for example on the TI CC3220 SF for secure flash, the network processor runs the TCPI stack in crypto as I said on a separate CPU address from the MCU and the network processor has full access to the keys. The MCU can write new secrets via over-the-air updates, but the secrets are signed encrypted with a device key, a secret device key, and there's rewrite access control levels. Another way you could keep the separation would be like on an ARM V8M device that has trusted execution environment where secrets can be stored in a secure memory partition and there's a talk later Tuesday by Andy Gross on, might touch upon some of that. So there's kind of two methods. There's one is you write a separate provisioning app to store the search and keys into a secure flash file system or use a vendor production line tool to provision the keys to secure flash and that's sort of what, that's the method that I'm using here in this solution. So an example of method one, so Zephyr has added TLS credential add API. So you could have code that looks something like this. If you, you have a config variable which you can enable a new TLS credentials API which allows you to store a root CA certificate into memory. Right now in Zephyr this is, this is adding this into RAM. This is not a big deal in this example because this is a public certificate but if you had private keys you would ideally want that to be in a secure partition or secure flash. But this is how you get an association of the content of, with method one, content of the actual certificate with a tag. So this associates a tag with the root certificate. Another method would be like in the case of TI we have a Uniflash tool, some production line tool which allows you to access a secure flash and add new trusted root catalogs, add new certificates and keys. For example, in the example I'm going to show next, we'll have an HTTP GET example that uses a global sign R2 certificate to access the Google web page or HTTPS. So you can just take this DER file and write it into secure flash. Then at runtime, find the certificate file name through the tag, through a setsockopt and you'll be able to use it to set up secure communication. The way that looks like is like this at initialization time, you can define our tag and if we're doing secure offload, we can set in this array called CA certificate in the previous example it was the actual byte array of the certificate, in this case it's just the file name of the certificate as it was stored on secure flash in the secure file system. Else we use method one. And then we can do the TLS credential add as before where we associate the tag with the certificate. In this case, the certificate is just the file name. And then at runtime, this is the HTTP GET example modified for secure offloading. This is just the preamble which sets up the port for 3 for HTTPS and then starts to set up some stuff. Sorry for any denting. It doesn't get added info to get the address into the res structure to do the socket connect. And then if we're dealing with credentials doing TLS in the socket APIs, we do this bit of code, otherwise it's this bit of code. And then the rest of the networking application looks the same. So what's happening here, if we're using TLS in sockets, when we create the socket, we have a new protocol family, iPrototLS and the version of TLS we're using. And then we make our list of tags and set that to the socket via a setsockopt call with the socket option TLS and then the flag and then the list of tags. And then after that, when we do the connect, this will automatically call the TLS handshake, whether it's using embed TLS or the TI network processor, which case it gets offloaded. And then when we do send and receive at that point, it's all over a secure channel. So the point of this is, so with a few lines of code, we've added TLS security to our socket-based application. And if SimpleLink is the platform here under the covers, all the secure offload, all the secure communications is going to be offloaded to the network processor. So just with a few changes to some initialization code in the networking protocol. So in summary, as I said, the SOC that we have allows the whole TCPIP stack, Wi-Fi, secure communications to be offloaded to the network processor. It's achieved by taking the host driver from SimpleLink SDK porting that to Zephyr via its OSEL, writing a Zephyr Wi-Fi driver that implements just the control plane API for scan, connect, disconnect, and the callbacks into the networking stack. And then for the sockets, providing the socket APIs through a function table that goes up to the, that's registered with the socket shim layer. Certificates are provisioned using the TI Uniflash tool. And with the help of this new TLS API, then we can get full secure socket offload, and that will be available to the upcoming socket-based network protocols. That's it. So there's a lot of time, I think. Yeah, questions? Concealably, since you already have on your network processor a microcontroller, and I assume there's a serial link between the two processors, would it make sense if you beefed up your network processor to just run Zephyr directly? We don't have, what would be the advantage of that? No, we don't have any plans. Bill of materials? There's a lot of, I don't know what the IP is on that side, but there's a lot of work that went into it. The OS that's currently running that stack is something that we've had for many years. It's gone into automotive processes, automotive customers. It's very robust and high quality, and Zephyr still needs to get there. So we're interested in using Zephyr here because we want to expand our ecosystem. Zephyr on the MCU, because we want to expand our ecosystem. On the other hand, we have this network processor with certain capabilities, and we haven't really entertained that thought. Well, it seems like ostensibly, it's a network for both processors. It's also Wi-Fi, functional, so it's got a problem after all, and I think it's hard to handle that. There's a lot of stuff going on in there, so from an awful perspective, we've had this chip for a long time, and we're trying to enable it in Zephyr in applications of also using Zephyr as a monthly app site. So there's not a real benefit on an existing platform to do that, and maybe on a new platform, we would consider integrating Wi-Fi at a much more tighter version of Zephyr. That will happen. Yeah, the other thing is, when you get to the network processor, Zephyr may not have the kind of device drivers to support the Mac and other things like that. If you let Mac layer up there sitting here, you don't have that for Zephyr. Maybe you want to go with the noise rough, like the MRA-52. You actually have the hook up to the arm, the base band. Possibly. The blue-tooth case, possibly. Oh, yes. You know, on the hardware, the specific stuff, it seems like you were describing, excuse me, it seems like you were describing two different ways of getting the certificates in there, one with this tool, which is your TI tool, which puts it actually into the... I guess you got a secure subsystem flash inside of that chip. But the other way with the Zephyr way, where's it putting it? So currently, it's just going around. Okay, that's not good then, right? So, yeah, it's fine for this example with just the public key, but when you have client authentication with the private key, that needs to go into some secure area. So, as I mentioned, it's... When we have, you know, on V8M, maybe there'll be a secure partition and that can be handled. Well, I'm wondering if the experience that you've gone through on this platform, if we couldn't abstract Zephyr in such a way that allows you to even go through the Zephyr way of setting this, but it goes through to your secure... That needs to be added. That's something that's not there right now. Right now I'm just using the method two. The method one can be implemented because we do have... There is a possibility to do file system calls if you have the signature and everything right to update, because we have to do that with OTA anyway. If you want to update certificates in the field. So, yeah, that's something that's not hooked in right here. My expectation is that we're going to have to expand this API a bit. Thank you. Yes. Speaking of OTA and updates, it's nice when you can offload, for example, TLS to a core processor because then you don't have to implement it in your application. But on the other hand, what is if there's a security problem in the implementation of the TLS, like it was hardbleeds a year ago, or if I want to have a newer version because I once throw away maybe the IoT device after two, three years, can this be updated to this network core processor? Yeah, so that's a common concern, especially in the Linux community for having this kind of offload in a mainline operating system like Linux. It's the same concern here, as you mentioned. So, yeah, there's a service pack which is signed by TI which can be updated for the device that has new firmware for the network core processor. So if there's a new hack that's been identified, then TI can provide that. And through over-the-air updates, you can update the new image. It'll be signed also. So that you can update for any security holes, security bug fixes that might occur over time. But it would come from TI. Yeah. Okay. Anything else? All right. Well, thank you very much.