Fedora: Flicker Free Boot

Fedora 30 now contains all changes changes for a fully Flicker Free Boot. Last week a new version of plymouth landed which implements the new theme for this and also includes a much improved offline-updates experience, following this design. At boot the display will seamlessly transit from the firmware boot-splash into the new plymouth theme, which uses the firmware boot-splash as background[…]

https://fedoraproject.org/wiki/Changes/FlickerFreeBoot

https://hansdegoede.livejournal.com/20119.html

UEFI Forum webinar: Secure Coding

The inherent nature of firmware makes it an appealing target for hackers as the hardening of traditional exploit vectors (e.g., operating systems and the applications) is leading to new routes of attack. Join the UEFI Forum Secure Coding webinar to hear the panel of security experts discuss tips and best practices.

Moderator:
Brian Richardson, Intel Corporation

Panelists:
Dick Wilkins, Phoenix Technologies
Trevor Western, Insyde Software
Eric Johnson, American Megatrends Inc.

https://register.gotowebinar.com/register/8562801240869758977

https://uefi.org/

nanoBench: A tool for running small microbenchmarks on recent Intel and AMD x86 CPUs.

Re: https://firmwaresecurity.com/2018/11/04/upos-info-latency-throughput-and-port-usage-information-for-instructions-on-recent-intel-microarchitectures/

nanoBench is a Linux-based tool for running small microbenchmarks on recent Intel and AMD x86 CPUs. The microbenchmarks are evaluated using hardware performance counters. The reading of the performance counters is implemented in a way that incurs only minimal overhead. There are two variants of the tool: A user-space implementation and a kernel module. The kernel module makes it possible to benchmark privileged instructions, and it can allow for more accurate measurement results as it disables interrupts and preemptions during measurements. The disadvantage of the kernel module compared to the user-space variant is that it is quite risky to allow arbitrary code to be executed in kernel space. Therefore, the kernel module should not be used on a production system. nanoBench is used for running the microbenchmarks for obtaining the latency, throughput, and port usage data that is available on uops.info.

https://github.com/andreas-abel/nanoBench

http://uops.info/

RAVENS: Resilient Architecture for Very Efficient firmware updates of Network-connected Systems

RAVENS (Resilient Architecture for Very Efficient firmware updates of Network-connected Systems) is a software ecosystem built on top of two main components, Hugin and Munin. […] Properly used, Hugin and Munin enable secure and efficient firmware updates of very small IoT devices.

https://github.com/Orange-OpenSource/RAVENS

 

mesos: a simple, debugger-based code coverage and crash monitoring harness

Mesos is a tool to gather binary code coverage on all user-land Windows targets without need for source or recompilation. It also provides an automatic mechanism to save a full minidump of a process if it crashes under mesos. Mesos is technically just a really fast debugger, capable of handling tens of millions of breakpoints. Using this debugger, we apply breakpoints to every single basic block in a program. These breakpoints are removed as they are hit. Thus, mesos converges to 0-cost coverage as gathering coverage only has a cost the first time the basic block is hit.

https://github.com/gamozolabs/mesos

CmpCov – an instrumentation module for clang/SanitizerCoverage

CompareCoverage (CmpCov in short) is a simple instrumentation module for C/C++ programs and libraries, which extracts information about data comparisons taking place in the code at run time, and saves it to disk in the form of standard .sancov files. It is based on the SanitizerCoverage instrumentation available in the clang compiler, which itself is tightly related to AddressSanitizer. Specifically, the library implements the instrumentation callbacks defined by the Tracing data flow feature of SanitizerCoverage.

https://github.com/googleprojectzero/CompareCoverage

The Intel 80386, part 17: Future developments

Re: https://firmwaresecurity.com/2019/01/22/raymond-chen-the-intel-80386-blog-series/

https://blogs.msdn.microsoft.com/oldnewthing/20190212-00/?p=100915

Wow, this new blog series is up to 17-parts now!

First Israeli Conference on Hardware and Side-channel Attacks

We are pleased to invite you to The First Israeli Conference on Hardware and Side-channel Attacks to be held in Barkan Hall, Ben-Gurion University of the Negev, Beer Sheva, from May 5-7, 2019. The conference will bring together researchers from industry and academia, as well as independent hackers. The objective of the conference is to form active research collaborations between Israeli and international researchers in the field of hardware and side-channel attacks, and to bridge the gap between designers, evaluators and attackers of secure systems. In this conference attackers and protectors will have the opportunity to talk about how things fail and how one may aim at protecting our valuables.[…]

https://fichsa.sise.bgu.ac.il/

Securing Bare Metal Hardware at Scale: Matt King and Paul McMillan at BSides PDX 2018

I’ve been eagerly waiting for this video since I couldn’t make the talk in person. This is hands down one of the best talks I’ve seen in firmware security, including some great coverage of the issues with security, development and deployment that are applicable to all sorts of devices, not just servers.

The solution presented is (sadly) only workable for relatively large deployments of relatively homogeneous servers. But it IS a fairly complete solution, unlike the various partial firmware-blob-specific solutions like Secure Boot. Where’s the Secure Boot for my NVMe SSD firmware?

Well worth the time to watch, for anyone responsible for the security of any hardware, or software running on hardware. So really, everyone. I think it is helpful to understand the problem and this solution, even if you’re only responsible for say, your personal laptop and smartphone.

Meltdown And Spectre, One Year Later

About this time last year, reports surfaced about security attacks on today’s most popular microprocessors (μPs). Researchers called them Meltdown, Spectre gaining widespread attention. Today, however, the industry and especially μP vendors have made some progress toward stemming these vulnerabilities. Here is my analysis as we enter into 2019.[…]

https://semiengineering.com/meltdown-and-spectre-one-year-later/

Practical Enclave Malware with Intel SGX

Modern CPU architectures offer strong isolation guarantees towards user applications in the form of enclaves. For instance, Intel’s threat model for SGX assumes fully trusted enclaves, yet there is an ongoing debate on whether this threat model is realistic. In particular, it is unclear to what extent enclave malware could harm a system. In this work, we practically demonstrate the first enclave malware which fully and stealthily impersonates its host application. Together with poorly-deployed application isolation on personal computers, such malware can not only steal or encrypt documents for extortion, but also act on the user’s behalf, e.g., sending phishing emails or mounting denial-of-service attacks. Our SGX-ROP attack uses new TSX-based memory-disclosure primitive and a write-anything-anywhere primitive to construct a code-reuse attack from within an enclave which is then inadvertently executed by the host application. With SGX-ROP, we bypass ASLR, stack canaries, and address sanitizer. We demonstrate that instead of protecting users from harm, SGX currently poses a security threat, facilitating so-called super-malware with ready-to-hit exploits. With our results, we seek to demystify the enclave malware threat and lay solid ground for future research on and defense against enclave malware.

 

https://arxiv.org/abs/1902.03256