Evolution of the x86 context switch in Linux

While researching archaic facts about the 80386 hardware context switch last weekend, I remembered that early versions of the Linux kernel relied on it. I was promptly sidetracked for hours reading code I hadn’t seen in years. This weekend, I’ve decided to write down the journey to consolidate all the nuggets of fun stuff I discovered along the way.

http://www.maizure.org/projects/evolution_x86_context_switch_linux/

Linux x86 context switch

Formally verified big step semantics out of x86-64 binaries

This paper presents a methodology for generating formally proven equivalence theorems between decompiled x86-64 machine code and big step semantics. These proofs are built on top of two additional contributions. First, a robust and tested formal x86-64 machine model containing small step semantics for 1625 instructions. Second, a decompilation-into-logic methodology supporting both x86-64 assembly and machine code at large scale. This work enables black-box binary verification, i.e., formal verification of a binary where source code is unavailable. As such, it can be applied to safety-critical systems that consist of legacy components, or components whose source code is unavailable due to proprietary reasons. The methodology minimizes the trusted code base by leveraging machine-learned semantics to build a formal machine model. We apply the methodology to several case studies, including binaries that heavily rely on the SSE2 floating-point instruction set, and binaries that are obtained by compiling code that is obtained by inlining assembly into C code.

https://dl.acm.org/citation.cfm?doid=3293880.3294102

Firmware-BiosUpgrades: Update BIOS for any make and model (incremental if needed) [using PowerShell]

Update BIOS for any make and model (incremental if needed).
Invoke-BIOSUpgrade.ps1 – Checks the make and model and bios version, then compares that with whats in a corresponding folder (BIOS<make><model>). Does check for Bios password in plain text file BIOSPassword.txt (if exists). It will attempt to suspend bitlocker if enabled. Also sets a SMSTS environment variable SMSTS_BiosRebootRequired, SMSTS_BiosBatteryCharge, SMSTS_BiosBatteryCharge which can be used for a additional sequences. Also set a variable (SMSTS_MutipleBIOSUpdatesNeeded), which allows the bios to update incrementally if needed. This does require to have two steps in the tasksequence to run this script twice (or three times), but one of them should check if this variable is true.

https://github.com/PowerShellCrack/Firmware-BiosUpgrades

 

3 new research papers on fuzzing

 

https://arxiv.org/abs/1901.01142

https://arxiv.org/abs/1812.01197

https://arxiv.org/abs/1812.00140

 

Azure IoT automatic device management helps deploying firmware updates at scale

Automatic device management in Azure IoT Hub automates many of the repetitive and complex tasks of managing large device fleets over the entirety of their lifecycles. Since the feature shipped in June 2018, there has been a lot of interest in the firmware update use case. This blog article highlights some of the ways you can kickstart your own implementation.

Azure IoT automatic device management helps deploying firmware updates at scale

When a Patch is Not Enough – HardFails: Software-Exploitable Hardware Bugs

When a Patch is Not Enough – HardFails: Software-Exploitable Hardware Bugs
Ghada Dessouky, David Gens, Patrick Haney, Garrett Persyn, Arun Kanuparthi, Hareesh Khattri, Jason M. Fung, Ahmad-Reza Sadeghi, Jeyavijayan Rajendran
(Submitted on 1 Dec 2018)

In this paper, we take a deep dive into microarchitectural security from a hardware designer’s perspective by reviewing the existing approaches to detect hardware vulnerabilities during the design phase. We show that a protection gap currently exists in practice that leaves chip designs vulnerable to software-based attacks. In particular, existing verification approaches fail to detect specific classes of vulnerabilities, which we call HardFails: these bugs evade detection by current verification techniques while being exploitable from software. We demonstrate such vulnerabilities in real-world SoCs using RISC-V to showcase and analyze concrete instantiations of HardFails. Patching these hardware bugs may not always be possible and can potentially result in a product recall. We base our findings on two extensive case studies: the recent Hack@DAC 2018 hardware security competition, where 54 independent teams of researchers competed world-wide over a period of 12 weeks to catch inserted security bugs in SoC RTL designs, and an in-depth systematic evaluation of state-of-the-art verification approaches. Our findings indicate that even combinations of techniques will miss high-impact bugs due to the large number of modules with complex interdependencies and fundamental limitations of current detection approaches. We also craft a real-world software attack that exploits one of the RTL bugs from Hack@DAC that evaded detection and discuss novel approaches to mitigate the growing problem of cross-layer bugs at design time.

https://arxiv.org/abs/1812.00197

SPECTECTOR: Principled Detection of Speculative Information Flows

SPECTECTOR: Principled Detection of Speculative Information Flows
Marco Guarnieri, Boris Köpf, José F. Morales, Jan Reineke, Andrés Sánchez
(Submitted on 20 Dec 2018)

Since the advent of SPECTRE, a number of countermeasures have been proposed and deployed. Rigorously reasoning about their effectiveness, however, requires a well-defined notion of security against speculative execution attacks, which has been missing until now. We present a novel, principled approach for reasoning about software defenses against SPECTRE-style attacks. Our approach builds on speculative non-interference, the first semantic notion of security against speculative execution attacks. We develop SPECTECTOR, an algorithm based on symbolic execution for automatically proving speculative non-interference, or detecting violations.
We implement SPECTECTOR in a tool, and we use it to detect subtle leaks — and optimizations opportunities — in the way major compilers place SPECTRE countermeasures.

https://arxiv.org/abs/1812.08639

[AMD] SEVered attack: Extracting Secrets from Encrypted VMs

Extracting Secrets from Encrypted Virtual Machines
Mathias Morbitzer, Manuel Huber, Julian Horsch
(Submitted on 7 Jan 2019)

AMD SEV is a hardware extension for main memory encryption on multi-tenant systems. SEV uses an on-chip coprocessor, the AMD Secure Processor, to transparently encrypt virtual machine memory with individual, ephemeral keys never leaving the coprocessor. The goal is to protect the confidentiality of the tenants’ memory from a malicious or compromised hypervisor and from memory attacks, for instance via cold boot or DMA. The SEVered attack has shown that it is nevertheless possible for a hypervisor to extract memory in plaintext from SEV-encrypted virtual machines without access to their encryption keys. However, the encryption impedes traditional virtual machine introspection techniques from locating secrets in memory prior to extraction. This can require the extraction of large amounts of memory to retrieve specific secrets and thus result in a time-consuming, obvious attack. We present an approach that allows a malicious hypervisor quick identification and theft of secrets, such as TLS, SSH or FDE keys, from encrypted virtual machines on current SEV hardware. We first observe activities of a virtual machine from within the hypervisor in order to infer the memory regions most likely to contain the secrets. Then, we systematically extract those memory regions and analyze their contents on-the-fly. This allows for the efficient retrieval of targeted secrets, strongly increasing the chances of a fast, robust and stealthy theft.

https://arxiv.org/abs/1901.01759

Latest S2E released, adds QEMU v3 support

S²E is a platform for writing tools that analyze the properties and behavior of software systems. S²E comes as a modular library that gives virtual machines symbolic execution and program analysis capabilities. S²E runs unmodified x86, x86-64, or ARM software stacks, including programs, libraries, the kernel, and drivers. Symbolic execution then automatically explores hundreds of thousands of paths through the system, while analyzers check that the desired properties hold on these paths and selectors focus path exploration on components of interest. S²E is now commercially supported by Cyberhaven. It is free for non-commercial use. S²E was a research project of the Dependable Systems Lab at EPFL in Lausanne.

http://s2e.systems/docs/DesignAndImplementation/KvmInterface.html

https://github.com/s2e/

https://github.com/S2E/qemu

 

Keegan Ryan: Spectre on a Television

This past January, I ordered a new TV. […] The TV was manufactured by Sceptre Inc. (note the ‘C’ and ‘P’ switch) and was covered in SCEPTRE branding. My goal for this project was to perform a hardware-level attack against the TV and change the branding to SPECTRE as an homage to the microarchitectural attack. This project has nothing to do with exploiting speculative execution, but instead it demonstrates several common techniques NCC Group uses when analyzing embedded systems.[…]

https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2018/december/spectre-on-a-television/

Hacking Your Way to a Custom TV Boot Screen

Spectre TV

Sail-Arm: Sail version of ARM ISA definition, currently for ARMv8.5-A

https://github.com/rems-project/sail-arm

see-also:

https://github.com/rems-project/sail

https://alastairreid.github.io/papers/FMCAD_16/

Bareflank’s hypervisor: lightweight hypervisor SDK written in C++ with support for Windows, Linux and UEFI

The Bareflank Hypervisor is an open source, hypervisor Software Development Toolkit (SDK), led by Assured Information Security, Inc. (AIS), that provides a set of APIs needed to rapidly prototype and create new hypervisors. To ease development, Bareflank is written in C/C++, and includes support for C++ exceptions, JSON, the GSL and the C++ Standard Template Library (STL).

https://github.com/Bareflank/hypervisor

AIS HOME 23

Bareflank

Debian UEFI Secure Boot changes!

Steve McIntyre has posted an update on Debian’s UEFI Secure Boot status, to the debian-boot and debian-efi mailing lists. Excerpt:

I’ve just pushed changes to a few bits of d-i this weekend to make SB work for amd64:

* build/util/efi-image: […]
* build/config/arm.cfg, build/config/x86.cfg: […]
* debian/control: […]
* grub-installer/grub-installer: […]

The effect of these changes is that the next daily and weekly debian installer images (tomorrow) should Just Work (TM) end-to-end with UEFI Secure Boot. The changes to efi-image also mean that our next live image builds will do SB (for live and installation).

I’ll test all these again in the next couple of days to verify that things have pulled through as I expect, then it’s time to post to d-d-a and write a blog too. We’ve made great progress already. These last changes just tie it all together for end users.

More info:

https://lists.debian.org/msgid-search/20190113192343.qg3ekmtnyepscwxb@tack.einval.com

hdk – (unofficial) Hyper-V® Development Kit

The HDK is an updated version of the HvGdk.h header file published under MSR-LA as part of the Singularity Research Kernel. It has been updated to add the latest definitions, structures and definitions as described in the Microsoft Hypervisor Top-Level Functional Specification (TLFS) 5.0c published June 2018.

https://ionescu007.github.io/hdk/

UEFI-based screen capture tools

I notice that Microsoft’s Project Mu has a PrintScreenLogger tool (Ctrl+PrtScn):

https://github.com/Microsoft/mu_plus/tree/release/201808/MsGraphicsPkg/PrintScreenLogger

https://microsoft.github.io/mu/dyn/mu_plus/MsGraphicsPkg/PrintScreenLogger/Readme/#printscreenlogger-operation

and that it is already getting some forks:

https://github.com/vscpp/PrintScreenLogger

Before that, there was RU.EFI command line tool (F12):

RU.EFI updated, screen snapshot support

and Nikolaj’s CrScreenShotDXE (LeftCtrl+LeftAlt+F12):

screenshot-taking UEFI DXE driver

William reviews CrScreenshotDxe

And there are probably a few other options I’m not aware of, including by IBVs/ODMs.