Can we implement a lite BMC using a generic MCU?
We heard this request for many years. This answer depends. When I was developing the BMC (Baseboard Management Controller) firmware in IPMI era, around 2005 or earlier, the answer to the question would be yes. At that time the MCU (Microcontroller Unit) was even an 8-bit or 16-bit MCU chip. The side-band network was implemented by driving a specially designed shared host NIC via proprietary i2c protocol. All of us can imagine the performance bottleneck it would have. But it’s ok in the old days, because there were still no (at least we rarely heard that) many serious cyberattacks we meet today. As days passed, more and more advanced features like web server, Serial over LAN, Ethernet-based KVM, virtual media, remote host CPU debugging, centralized user management, and the more and more serious cyberattacks appeared, drove BMC designs to be highly performant and SOC-based. The management protocol was also moved to over HTTP and Web Socket, for UDP based IPMI packets will be blocked by modern firewalls when crossing domains, and so that to implement the modern secure networking practice, because security of IPMI network session and user management is just more than nothing in today’s viewpoint. Therefore, my answer to the above-mentioned question would be NO, if you asked me a few years ago.
In fact, some essential features of modern BMCs require high network bandwidth to get user experience good enough, such as KVM and virtual media. Back to the question, most people asking this usually come from fields like IPC (Industrial PC) and IoT (Internet of Things) applications which are cost sensitive, or have machines deployed in open environments, where no high-speed network are available, making SOC-based BMC tasteless. The situation lasted for a period, until ARM Cortex-M appeared. Some people asked about this question again, because there are so many Cortex-M based MCUs with Ethernet equipped, but my answer is still – it depends. You may wonder why, since there are so many network examples in SDK associated with these chips, especially, http server. Supposedly we can build a web server, or the so-called mini, or lite BMC based on these examples, right?
Many problems hide behind networking considerations
First of all, are the limited resources of an MCU enough for implementing a web server that is strong enough and supports secure TLS connections, and how many connections can this web server support at the same time? Before we go to examine the resource requirement in real cases, let us observe a major tradeoff that we have to evaluate at the design stage. To improve the network performance, almost all TCP stacks in modern OSs implement delayed acknowledgement and Nagle’s algorithm. If our MCU-based network application tries to send or receive small chunks of data over TCP connections most of the time, we can imagine that network throughput can be roughly estimated by how many Ethernet packets are transmitted before the corresponding ACK is received from peer, let’s assume it a period around 40ms. Under such a condition, if the receiver’s TCP window is designed as size of 8 regular TCP packets, and the transmitter always send small chunks of data, we get a throughput about 8*1.5K bytes within 40ms, or 2.4M bits per second. (Recall Ethernet specifications. Have you ever seen any Ethernet with throughput at this level?) The larger the receiver’s TCP window is, the higher performance the transmitter gets. Even with MCU acting as the transmitter to talk with a receiver with much bigger TCP window size, since MCU cannot receive the acknowledge packets from receiver in time, MCU has to keep all the data it sent out, that usually runs out all the buffers MCU prepared earlier than the time MCU reaches receiver’s TCP window limit. With such small, low-performant TCP window setting, in order to sustain a single TCP connection, most likely we already need to reserve 15KB RAM or so for it. Taking it as a base line, and considering some buffers for operations using UDP packets, we get several tens of KB to reserve. Let’s take 40KB for 2 TCP connections and a bit more for UDP traffic here. This is the portion of packet buffers only.
This is just one of the tradeoffs that we have to judge. We still have many modules to include. According to our experience, in an RTOS-based firmware implementation, the bottom line consisting of the popular TCP/IP library lwIP most people adopted, the custom cryptographic library from Mbedtls for TLS communication, and some spaces for stack and heap usage, already means a resource requirement more than 210KB. So far we still did not count the extra modules in, such as HTTP and Web Socket, JSON parser/generator, and the certificate chain required to authenticate this web server. Conservatively speaking, a resource requirement baseline of approximately 250KB would be more realistic here.
It’s still not the end. Now we can start to consider the extra spaces required for the application part, including the web server, APIs, modern user management like a secure LDAP client, and defense against various cyberattacks we will meet today, if we still have resources left.
OK. I just have an MCU with resources big enough in any case, can I do it?
Here the second problem comes, network security. In fact, this is a more important and gating consideration that is why we don’t recommend implementing web server using an MCU.
We already know the resource required for packet buffers grows as count of connections a web server plans to support goes up. You may say, OK, let’s set a limit over the maximal count of simultaneous connections. Is that safe? I’m afraid not. Now let’s consider the most common cyberattack, DDoS (Distributed Denial of Service), which means your web server may get a lot of incoming connection requests from zombies of worldwide botnets. Now your lwIP stack has to check each of them to decide whether to accept or drop it, and this starves all your computing power, and makes your network broken effectively.
In fact, an even much simpler attack, i.e., flooded UDP attack can make your web server crash easily. Without specially designed packet filters, a general purpose Ethernet gets jammed quickly when this happens, because all the packet buffers we prepared for TCP packets are occupied. Given a basic 100Mbps network, it takes about 5us only to receive a short UDP packet (i.e., 64 bytes long). Now, we can imagine our packet buffers will be consumed at a speed of 1.5KB per 5us, and we only reserved 40KB as assumed previously, how long can it sustain working? The answer is obvious and does not need further explanation.
Then, are there no other opportunities for a secure network application made by MCU like Lite BMC?
Not necessarily. To address the concerns mentioned above, we can change our design direction, to implement a web client instead of a web server, and choose an MCU equipped with Ethernet packet filters. As a web client, and with the help of incoming packet filters, now lwIP doesn’t need to check the incoming TCP connection requests or flooded UDP packets any more. This condition perfectly resolves threats from the two kinds of cyberattacks. Of course this scheme requires an intermediate server responsible for the information aggregation and traffic bridging between users and MCU network applications. You may think that the intermediate server looks like an extra cost in this scheme, but let us take the real situation into consideration. Even with SOC-based BMC which has its own web server embedded, in most cases with a lot of machines to manage, IT personnel often establish another intermediate server to collect information from all the BMCs under management via standard interfaces like Redfish. Aren’t they with familiar looking? An even better result along with this design direction is that, now we can implement any interface we wish on the intermediate server, to fulfill our requirements adapting other management systems, or visualize the individual / aggregated information of managed machines, to a maximum extent without MCU firmware changes.
NMC and NMC Web Monitor Server
This is why we design this concept project, NMC (Node Management Controller. Looking similar to BMC, right?) and NMC Web Monitor Server. With Nuvoton’s NMC product line-up (renamed as eBMC, meaning 'Edge computing BMC', since December 2023), we can manage remote machines in the out-of-band way, such as operating their consoles or BIOS setup menu, a.k.a. Serial over LAN, checking their health and events, pushing new firmware for update, and cycling power of machines remotely when required, without arriving the spot in person. The low cost MCU-based design of NMC didn’t sacrifice the network security, because all the communication between NMC Web Monitor Server, NMCs, and users were done via modern TLS-based, secure HTTP and Web Socket connections, and even more, NMC implemented extra PKI-based security enforcement, to guard all the crucial actions to be applied on remote machines.
A noteworthy point here is, NMC is not designed as a replacement of BMC. They are different. If your application needs the advanced BMC features, especially those requiring high network speed such as KVM, virtual media, and remote host CPU debugging, Nuvoton’s BMC line-up is still your best choice.
If you are interested in this concept project, welcome to visit our YouTube channel to see some introduction and demonstration videos, and our website for more details. If you also like these videos and the website, it would be appreciated if you give them a thumbs-up and share them. If you are also interested in this idea, welcome to contact us (Nuvoton Technology Corp.), or leave messages under YouTube videos or Twitter. Your encouragement is the driving force for us to keep updating and implementing more concept projects on our experimental website NTCCSAPP.com in the future. Don’t forget to subscribe to our YouTube and keep tracking.
Thanks for all your time viewing this.