Cryptographic protection of memory is an essential ingredient for any technology that allows a closed computing system to run software in a trustworthy manner and handle secrets, while its external memory is susceptible to eavesdropping and tampering. An example for such a technology is Intel’s emerging Software Guard Extensions technology (Intel SGX) that appears in the latest processor generation, Architecture Codename Skylake. This technology operates under the assumption that the security perimeter includes only the internals of the CPU package, and in particular, leaves the DRAM untrusted. It is supported by an autonomous hardware unit called the Memory Encryption Engine (MEE), whose role is to protect the confidentiality, integrity, and freshness of the CPU-DRAM traffic over some memory range. To succeed in adding this unit to the micro architecture of a general purpose processor product, it must be designed under very strict engineering constraints. This requires a careful combination of cryptographic primitives operating over a customized integrity tree that mostly resides on the DRAM while relying only on a small internally stored root. The purpose of this paper is to explain how this hardware component of SGX works, and the rationale behind some of its design choices. To this end, we formalize the MEE threat model and security objectives, describe the MEE design, cryptographic properties, security margins, and report some concrete performance results.
Don’t do any “complex workloads” on your Skylake boxes until you get a BIOS update…
BIOS updates on the way to fix problem says Intel
Four days ago Intel reported that its engineering department had identified the issue which “only occurs under certain complex workload conditions… [when] the processor may hang or cause unpredictable system behaviour”. It has released a fix for the issue to hardware partners which will be distributed via BIOS updates for Skylake compatible motherboards. Now users will just have to wait for their motherboard vendors to publish BIOS updates with the Intel fix incorporated.
You might want to check here for updates from Intel-based devices:
More on this recent research:
# ./rowhammer[-architecture] [-t nsecs] [-p percent] [-c cores] [-d dimms] [-r row] [-f first_offset] [-s second_offset]
”-c” the number of cores (only important with ”#define EVICTION_BASED”)
”-p” percent of memory to use
”-d” number of dimms (very important)
”-r” loop only over the specified row
”-f” only test addresses with the specified first aggressor offset
”-s” only test addresses with the specified second aggressor offset
Reverse Engineering Intel DRAM Addressing and Exploitation
Peter Pessl, Daniel Gruss, Clémentine Maurice, Michael Schwarz, Stefan Mangard
In this paper, we present a method to reverse engineer DRAM addressing functions based on a physical bus probing. Second, we present an automatic and generic method to reverse engineer DRAM addressing functions merely from performing a timing attack. This timing attack can be performed on any system without privileges and even in virtual machines to derive information about the mapping to physical DRAM channels, ranks and banks. We reversed the complex adressing functions on a diverse set of Intel processors and DRAM configurations. Our work enables side-channel attacks and covert channels based on inner-bank row conflicts and overlaps. Thus, our attack does not exploit the CPU as a shared resource, but only the DRAM that might even be shared across multiple CPUs. We demonstrate the power of such attacks by implementing a high speed covert channel that achieves transmission rates of up to 1.5Mb/s, which is three orders of magnitude faster than current covert channels on main memory. Finally, we show how our results can be used to increase the efficiency of the Rowhammer attack significantly by reducing the search space by a factor of up to 16384.
The coreboot blog has a long post, which covers the last five weeks of changes, and there were a lot: 314 commits. Some highlights:
Over one third of the commits covers Intel Skylake development, where boards and chipset code saw misc improvements and tons of clean ups.
There also was a notable effort of unifying common code across the more recent Intel SoCs, removing lots of duplicated code all over the place.
On x86, the romstage is now relocated for its final location in CBFS by cbfstool, obsoleting the old approach that had us link it twice, once to determine its final size and then to the actual location it’s supposed to run from. In the future this same approach may be extended to other files that need to be executed in place such as the FSP binary.
The romstage change eliminated the need for cbfstool’s “locate” command, and so it was removed. cbfstool also saw other extensions, the biggest one a compatible change to the format to allow for per-file attributes in CBFS. These attributes can contain additional information about a file, currently the compression method and uncompressed size of a file. cbfstool and the build system were extended to allow compressing files, libpayload is able to uncompress these files.
On the AMD side, there were various bugfixes both for new (merlin falcon) and old (Fam10) chipsets.
ARM64 and Tegra210 saw various bugfixes and improvements to power use. For the latter, coreboot also learned how to reserve memory for other functions than the main processor.
Rockchip’s RK3288 ARMv7 SoC also saw a number of bug fixes and the code was restructured to use a single mainboard directory for a large number of very similar Google Veyron mainboards based on that SoC.
Our RISCV support now boots on the Spike simulator which (besides supporting a wider variety of emulators) is notable because unlike the QEmu RISCV support, Spike supports RISCV’s revised ABI.
Speaking of emulators, recent versions of qemu-x86 expect the firmware to initialize the LAPIC, which we now do.
The ongoing effort to move CPU microcode into CBFS (and to store these as binaries in 3rdparty/blobs instead of header files in the main sources) saw some progress.
Lots of interesting things were omitted above. Full post:
I don’t give enough news to new CPUs. Skylake has been in the news for a while, but Intel just officially announced it:
Excerpt from press release:
“Coming Soon: Intel® Iris™ Graphics, Intel® vPro™ for business, and products for IoT
In the coming months, Intel plans to deliver more than 48 processors in the 6th Gen Intel Core processor family, featuring Intel® Iris™ and Iris Pro graphics, as well as Intel Xeon E3-1500M processor family for mobile workstations and 6th Gen Intel® vPro™ processors for business and enterprises. A variety of devices across a wide range of form factors will be available now and over the coming months from manufacturers around the world. In addition, Intel is offering more than 25 products for the Internet of Things (IoT) with up to 7-year long-life supply and error correcting code (ECC) at multiple TDP levels. Retail, medical, industrial, and digital surveillance and security industries will all benefit from the new 6th Gen Intel Core processor improvements and includes IoT designs from the edge to the cloud.”
Last week Intel announced the upcoming Xeon Processor E3-1500M v5 Product Family for notebooks. This is the 6th Generation Intel Core family based on Skylake architecture.
“Intel Xeon-based mobile workstations will have key features such as error-correcting code memory that automatically detects and repairs errors on-the-fly that cause data corruption and system crashes for peace-of-mind reliability. These new systems will also enjoy the benefits of the unique hardware-assisted security, manageability, and productivity capabilities of Intel vPro Technology. Mobile workstations featuring Intel Xeon will also feature Thunderbolt 3 – the USB-C that does it all.”
Jeff Thomas at Sage Engineering wrote a blog post yesterday on the new Intel Skylake board.
(Sage is an open source-friendly IBV, they focus on coreboot and Chrome OS, and know a lot more about AMD platforms than I know. Jeff is an active blogger, and a good source of industry news.)
On a somewhat related note, from an open source OS-level perspective, Skylake has graphics that require non-free firmware blobs, which is IMO unfortunate: