Welcome to the November 2017 edition of the Embedded Artistry Newsletter! This is a monthly newsletter of curated and original content to help you build better embedded systems. This newsletter is intended to supplement the website and covers topics not mentioned there.
This month we'll be covering:
- The recently announced vulnerability in the WPA2 algorithm
- Industry standard APIs to make multi-core programming more accessible
- The EMB² multicore programming framework
- The recently announced ARM Platform Security Architecture
- "The Coming Software Apocalypse"
WPA2 Vulnerability: Key Reinstallation Attacks
A serious flaw in the WPA2 security algorithm, which protects our Wifi networks, was announced this month. The attack vectors is dubbed KRACK for "Key Reinstallation Attack." The KRACK vector exploits a flaw in the WPA2 algorithm itself. Any correct implementation is likely to be affected. By exploiting the 4-away handshake protocol used to exchange encryption keys, a third-party can collect and replay the key installation message. This vulnerability enables packet replays, packet forgery, packet decryption, or man-in-the-middle attacks.
Stay alert and update your devices as soon as updates are available. Do not switch back to the less-secure WEP security protocol: once this flaw is patched, WPA2 will remain secure. If you are building or supporting a Wifi-enabled device, check with your chip or SDK vendors for updates and timelines.
More on the KRACK attack vector:
Industry Standard Multicore APIs
Multicore embedded systems are becoming increasingly popular. However, writing programs to use multicore processors effectively is a challenge. The Multicore Association (MCA) aims to improve the adoption of multicore programming by defining and promoting specifications that better enable multicore product development. If you are writing software destined for a multicore embedded system, consider using these APIs to keep your software portable and abstracted from underlying architectures.
The aim of the Multicore Task Management API (MTAPI) is to create a standardized API for task-parallel programming on a wide range of hardware architectures. Manually creating and managing threads can be complex, error-prone, and depends on your operating system and hardware. MTAPI abstracts hardware and operating system details and allows programmers to focus on the parallel programming solution. There are no compiler, hardware, or operating system dependencies, and the API is written in C to minimize ABI interoperability problems. The API can be implemented on resource-limited devices and covers a variety of multicore architectures and hardware acceleration units. Task scheduling can be optimized for latency and fairness, enabling its use on systems with soft real-time requirements.
The Multicore Resource Management API (MRAPI) specifies application-level resource management capabilities. This API allows multicore applications to coordinate concurrent access to various system resources.
The Multicore Communications API (MCAPI) defines an API and semantics for communicating and synchronizing processing cores in embedded systems. MCAPI is a message-passing API that is designed for closely-distributed systems (e.g. multiple cores on a single chip, multiple chips on a single board). The API is kept simple to support sufficient functionality while allowing efficient implementations for resource constrained systems.
More information on the MCA standards:
Multicore Framework: Embedded Multicore Building Blocks
Embedded Multicore Building Blocks (EMB²) is an open-source C/C++ library for developing parallel embedded systems applications. EMB² is built on the Multicore Task Management API that we reviewed in the previous section.
EMB² provides generic building blocks for building parallel embedded applications, including basic parallel algorithms, concurrent data structures, and application skeletons. The majority of the framework APIs are non-blocking, avoiding common multi-threaded problems encountered when using locks.The framework utilizes an abstraction layer that makes it easily ported to new operating systems and processor architectures.
EMB² is implemented as a C API with C++ wrappers. The project is based on C99 and C++03 to provide maximum usability in the embedded world. C11 and C++11 can be selected for use of the standard atomic operations instead of the EMB² atomics.
My favorite aspect about this project is the emphasis on quality: the project maintains zero compiler warnings, sports 90% unit test coverage, utilizes static analysis and automated rule checks, and has formally validated pieces of the system. It's refreshing to find a team that cares about quality!
If you're looking for a simple framework to get started with multicore embedded development, check out EMB²:
The ARM Platform Security Architecture
As the news frequently highlights, inadequate security implementations on embedded systems is a major problem. Last September, ARM announced their intentions to work on a platform security architecture to help combat this threat. based on announcements this month, it looks like ARM is delivering on their promise.
Dubbed the Platform Security Architecture (PSA), ARM is focusing on three major components:
- Threat Models and Security Analyses derived from a range of typical IoT use cases
- Architecture specifications for firmware and hardware
- An open source project similar to Arm Trusted Firmware
The PSA is targeted for smaller cores and low-cost devices. Sensitive assets, such as keys and credentials, will be managed by a Secure Processing Environment (SPE) and will be separated from the application firmware.
In addition to the PSA, ARM has announced two new security-related cores. The CryptoIsland-300 is a programmable security core which expands upon the CryptoCell that they announced last year. The SDC-600 is a secure debugging channel that will allow users to enable or disable debugging abilities by using a cryptographic certificate.
The PSA is initially targeted for Cortex-M devices and will include open-source implementation examples. The PSA release is expected in Q1 of 2018. Support for Cortex-R and Cortex-A devices will follow after Cortex-M.
More on the ARM PSA:
The Coming Software Apocalypse
The Atlantic recently published an article titled "The Coming Software Apocalypse". Our world is becoming increasingly digitized and we are encountering more and more flaws in the software we depend on. Even our cars, which were primarily mechanical systems once upon a time, are now comprised of 100 million lines of code. The article dives into some of the challenges involved with the increase in software complexity, primarily focusing on limitations in our intellectual management of large software project. Following this premise, the author advocates increased emphasis on using tools during the development process. Software should be modeled before any code is written, algorithms should be checked with formal methods or tools such as TLA+, and code generators should be used to reduce programmer errors.
I later stumbled across a response to The Atlantic's article titled "Tools are not the Answer". The author of this post emphasizes a point which I wholeheartedly agree with: tools are helpful, but not the complete answer. Programmers must hold themselves to higher standards.
The rebuttal emphasizes that our software woes primarily stem from two causes:
- Too many programmers take sloppy short-cuts under schedule pressure.
- Too many other programmers think it’s fine, and provide cover.
And the obvious solution:
- Raise the level of software discipline and professionalism.
- Never make excuses for sloppy work.
This is not to say that tools won't help: our software is still becoming increasingly complex and difficult to manage. We must improve our development processes and hold ourselves to higher standards.
Read more here:
Selected Quotes from the Articles
“Typically the main problem with software coding—and I’m a coder myself,” Bantégnie says, “is not the skills of the coders. The people know how to code. The problem is what to code. Because most of the requirements are kind of natural language, ambiguous, and a requirement is never extremely precise, it’s often understood differently by the guy who’s supposed to code.”
This is the trouble with making things out of code, as opposed to something physical. “The complexity,” as Leveson puts it, “is invisible to the eye.”
The software did exactly what it was told to do. The reason it failed is that it was told to do the wrong thing.
Take error handling and correction seriously in your designs:
But, as described in a report to the FCC, “the situation occurred at a point in the application logic that was not designed to perform any automated corrective actions.”
We already know how to make complex software reliable, but in so many places, we’re choosing not to. Why?
I stood before a sea of programmers a few days ago. I asked them the question I always ask: “How many of you write unit tests on a regular basis?” > Not one in twenty raised their hands.
These were the most popular articles in October:
- Circular Buffers in C/C++
- Installing LLVM/Clang on OSX
- Implementing Malloc: First-fit Free List
- std::string vs C-strings
- An Overview of C++ STL Containers
Thanks for Reading!
Have any feedback, suggestions, interesting articles, or resources to recommend to other developers? Respond to this email and let me know!