Welcome to the August 2018 edition of the Embedded Artistry Newsletter! This is a monthly newsletter of curated and original content to help you build superior embedded systems. This newsletter is intended to supplement the website and covers topics not mentioned there.
This month we'll cover:
- More Speculative Execution attacks: SpectreRSB and NetSpectre
- The new version of the Freestanding C++ proposal
- The Embedded Artistry Technology Radar
- Interesting links from around the web
- Embedded Artistry website updates and popular posts
Speculative Execution Attacks
Earlier this year we covered Spectre and Meltdown, two speculative execution vulnerabilities that affect a majority of the world's processors. In June, there was another announcement regarding an Intel speculative execution vulnerability dubbed lazy floating-point state restore.
The trend continues, and two more speculative execution attack vectors have come to light in the past few weeks:
- SpectreRSB, which exploits speculative execution of the return stack buffer
- NetSpectre, a remote attack which does not require attacker-controlled code to run on the victim's machine
Exploring these speculative execution vulnerabilities is a great way for embedded developers to learn the details about how processors work.
SpectreRSB is a speculative execution vulnerability which exploits the return stack buffer (RSB). The RSB is a structure similar to the branch predictor which is used to predict return addresses. When a call instruction is issued, the RSB pushes the return address onto an internal hardware stack.
SpectreRSB has six variants, but the basic flow is as follows:
- Context switch to the attacker:
- The attacker flushes shared address entries (i.e. flush reload)
- The attacker pollutes the RSB with the target address of a payload gadget in the victim’s address space
- The attacker yields the CPU back to the victim
- The victim eventually executes a return
- Speculative execution occurs at the address which the attacker injected into RSB
- Control switches back to the attacker, data is leaked
The authors of the paper claim that the existing mitigations against Spectre variant 1 do not protect against SpectreRSB. Intel claims that SpectreRSB is related to branch target injections which have already been mitigated. On some processors, an RSB refilling patch is available that interferes with SpectreRSB’s attack mechanism.
Intel, AMD, and ARM processors are affected, as they all utilize RSBs to predict return addresses.
More on SpectreRSB:
- The Register: Spectre Rises from the Dead to Bite Intel in the Return Stack Buffer
- ThreadPost: New Spectre-Level Flaw Targets Return Stack Buffer
- Spectre Returns! Speculation Attacks Using the Return Stack Buffer
- Ret2Spec: Speculative Execution Using Return Stack Buffers
The NetSpectre vulnerability is related to Spectre variant 1 in that it uses speculative execution to perform bounds-check bypass. NetSpectre can be used to defeat address-space layout randomization on a remote system.
Unlike other Spectre variants, NetSpectre does not require a victim to download and run malicious code their machine. Instead NetSpectre only requires the victim to have an active network connection. NetSpectre variations are currently too slow to be valuable to attackers, with exfiltration speeds between 15 and 60 bits/hr. Even if the attack vector is not currently usable, it demonstrates that Spectre is not simply a local vulnerability.
It’s reported that all CPUs affected by the Spectre variant 1 are also affected by NetSpectre, therefore existing vendor mitigations should be enough to protect against it. These mitigations require firmware and OS updates, so unpatched devices remain vulnerable.
More on NetSpectre:
- NetSpectre: Read Arbitrary Memory Over Network
- NetSpectre: New Remote Spectre Attack Steals Data Over the Network
- New NetSpectre Attack Can Steal CPU Secrets via Network Connections
New Freestanding C++ Proposal
In the June 2018 Newsletter, we mentioned the C++ standards proposal to support a "Freestanding" C++ language subset which is suitable for use without an underlying operating system.
A new version of the Freestanding proposal has been released: P1105R0: Leaving no room for a lower-level language: A C++ Subset.
The primary goal of the proposal is to make core language features (such as exceptions, RTTI, and thread local storage) optional if they have an OS dependency or incur storage space overhead. This would better-enable C++ to support the embedded systems and kernel programming communities.
For more on Freestanding C++:
- June 2018 Newsletter: P0829R2 Freestanding
- P1105R0: Leaving no room for a lower-level language: A C++ Subset
Embedded Artistry's Technology Radar
I was introduced to the Technology Radar concept while at Bredemeyer Consulting's Software Architecture Workshop. The Technology Radar concept was created by ThoughtWorks, and they regularly publish updates to their own radar.
I immediately latched onto the concept as a way to keep track of the technologies and techniques that we are investigating at Embedded Artistry. The technology radar also helps us document the solutions that we recommend others adopt.
We’ve identified four categories that we plan to explore as an embedded systems consulting firm:
- Libraries and Frameworks
- Platforms (both hardware and RTOS)
We've released the first-draft of our technology radar and will update it on an ongoing basis.
You can find our Technology Radar on the website under the Resources menu.
For more on technology radars:
Around the Web
IT Hare has published another article on (Re)Actors: CAS (Re)Actor for Non-Blocking Multithreaded Primitives.
An amusing RISC-V smear campaign by ARM has brought a lot of public attention to the RISC-V architecture. If you're unfamiliar with RISC-V, check out this IEEE article: RISC-V's Open-Source Architecture Shakes Up Chip Design. You can learn more on the RISC-V Foundation website.
Segger, who produces the J-Link and J-Trace tools, has announced their own C-based embedded OS called emPack. In addition to an operating system, Segger is also providing emPack plugins for GUI, File System, TCP/IP, USB-Device, USB-Host, and more.
We've created a Support page which will stay updated with the ways you can support the website.
We updated the following blog posts this month:
- Debugging: 9 Indispensable Rules
- Master Issue List Template
- MAC Allocation Tracker
- A Simple Consulting Services Agreement
Our Glossary is always expanding and has been updated with a plethora of new terms.
As mentioned we added a link to the Embedded Artistry Technology Radar under the Resources menu.
These articles were published on our website in July:
- Musings on Tight Coupling Between Firmware and Hardware
- Embedded Artistry's Project Proposal Template
- What I Learned at Bredemeyer Consulting's Software Architecture Workshop
- Enforcing Binary Size Limits using Make
- Leadership Advice from the Tao Te Ching
- LINEAR11 Conversion Using a Sign Extension Bit Twiddling Hack
- Simple Fixed-Point Conversion in C
- crect: A C++14 Library for Generating a Stack Resource Policy Scheduler at Compile Time
These were our most popular articles in July:
- Circular Buffers in C/C++
- Jenkins: Configuring a Linux Slave Node
- Installing LLVM/Clang on OSX
- Jenkins: Running Steps as sudo
- An Overview of C++ STL Containers
- Implementing an Asynchronous Dispatch Queue
- A Simple Consulting Services Agreement
- Creating and Enforcing a Code Formatting Standard with clang-format
- Demystifying ARM Floating-Point Compiler Options
Thanks for Reading!
Have any feedback, questions, suggestions, interesting articles, or resources to recommend to other developers? Simply reply to this email!