In the beginning, Bell Labs created “Unix“. Later, then did a follow-up, called “Plan 9“. Later still, Bell Labs (then Lucent) took Plan 9, added some Java-like features and renamed it to “Inferno” (after Dante’s book), then fairly quickly sold it off to Vita Nova.
The Plan 9 file system, “9P“, called “Styx” in Inferno, as in the River from the book, has been implemented in many places. Today, both Plan9 and Inferno OSes continue, and 9P/Styx is implemented in a variety of other OSes, most recently a UEFI version of 9P client.
“9pfsPkg is a Plan 9 file system protocol (9P) client for UEFI. It provides EFI_SIMPLE_FILE_SYSTEM_PROTOCOL interface for network transparent file system operation.”
No idea WHAT has changed, but this Microsoft OEM UEFI guidance document has recently changed:
I wish that this was a Wiki with a History link on it, or in some other way the Microsoft writers would provide some indication of WHAT has changed in the latest release. Important technical documents should include revision history, like a decent technical document. Because the document is HTTP-centric should not let technical writers from providing this.
Archive.org’s Changes feature hangs for this URL, for me:
Besides locally caching and diff’ing the two versions of the HTML document, if there is any other online option to track changes in online HTML documents like this, please leave a Comment on this blog post. Thanks.
Authors: K R M Parameswar, S Devendra, Dr. P Swarnalatha
New computers use UEFI rather than the standard BIOS. Both UEFI and BIOS are low-level that begins while booting the PC before booting the OS. UEFI provides higher graphics and mouse cursors. Also, UEFI termed as popular solution as it has ability to use bigger hard disks and provides more secure features, faster boot times etc. UEFI provides mouse pointer option which is not available in BIOS. UEFI termed as best replacement for the standard BIOS on PCs. There’s no real way to change from BIOS to UEFI on a current laptop. We’d like to search for new equipment that underpins and incorporates UEFI, as most new PCs do. In design part, UEFI again beats the LEGACY mode. This was obvious because UEFI was built years after DOS and thus had a better technological advancement in that field. Most UEFI usage give BIOS impersonating as such we will get a kick out of the chance to present and boot old working systems that expect BIOS rather than UEFI, along these way they’re backward great “This new specification shows many limitations of BIOS and also limits the disk partition size and therefore the amount of time BIOS takes to complete the tasks”.
Exciting new feature in the works, related to: “fwupdmgr security –force”
Secure and User-Friendly Over-the-Air Firmware Distribution in a Portable Faraday Cage
Martin Striegel, Florian Jakobsmeier, Yacov Matveev, Johann Heyszl, Georg Sigl
Setting up a large-scale wireless sensor network is challenging, as firmware must be distributed and trust between sensor nodes and a backend needs to be established. To perform this task efficiently, we propose an approach named Box, which utilizes an intelligent Faraday cage (FC). The FC acquires firmware images and secret keys from a backend, patches the firmware with the keys and deploys those customized images over the air to sensor nodes placed in the FC. Electromagnetic shielding protects this exchange against passive attackers. […]
The UEFI Forum’s Tianocore implementation is written in C, with a bit of assembly language. The U-Boot EFI implementation is in C. Most operating systems are written in C (although I hear that the current Windows kernel has been (or is being) rewritten from C to C++). There are a few C++/UEFI projects on Github, including a few C++-friendly versions of the UEFI Forum’s C-centric core header files. And I just noticed there was a talk at CppCon18 on this topic, video and slides below.
PS: To someone with a bit of spare time, who has an interest in UEFI and C++: please port Nmap to UEFI. Thanks!
Re: https://firmwaresecurity.com/2017/05/25/intel-atr-releases-uefi-firmware-training-materials/ and https://firmwaresecurity.com/2019/11/22/intel-atr-training-no-longer-publicly-available/
A few years ago, Intel had a group called Advanced Threat Research (ATR), and they created some great training material for Intel BIOS/UEFI security. This training material was used in expensive multi-day pre-conference training by led by Intel and others.
A few Intel reorgs later, and with many of the people moved on (mostly to Eclypsium), and for reasons I am not sure, the training material was taken down, for reason(s) I am not aware of. There’s a comment in the above blog post where someone had a copy of the content, but that Google Drive URL is now 404.
Anyway, I notice there’s at least two current source of this training, if you have not studied this stuff before it is worth reading.
Don’t presume these files will be there in the future, cache a copy locally.
Non-Volatile Kernel Root kit Detection and Prevention in Cloud Computing
R.Geetha Ramani, S Suresh Kumar
The field of web has turned into a basic part in everyday life. Security in the web has dependably been a significant issue. Malware is utilized to rupture into the objective framework. There are various kinds of malwares, for example, infection, worms, rootkits, trojan pony, ransomware, etc. Each malware has its own way to deal with influence the objective framework in various ways, in this manner making hurt the framework. The rootkit may be in some arbitrary records, which when opened can change or erase the substance or information in the objective framework. Likewise, by opening the rootkit contaminated record may debase the framework execution. Hence, in this paper, a Kernel Rootkit Detection and Prevention (KRDP) framework is proposed an avert the records. The avoidance system in this paper utilizes a calculation to forestall the opening of the rootkit influenced record as portrayed. By and large, the framework comprises of a free antivirus programming which is restricted to certain functionalities. The proposed model beats the functionalities by utilizing a calculation, in this way identifying the rootkits first and afterward cautioning the client to react to the rootkit tainted record. In this way, keeping the client from opening the rootkit contaminated record. Inevitably, in the wake of expelling the tainted document from the framework will give an improvement in the general framework execution.
I’m not sure what is up with this driver, if there are now two versions of this UEFI driver source, or if this is a fork. But new network support outside of Tianocore tree is rare enough.
The IPMI is a set of computer interface specifications for an autonomous computer subsystem that provides management and monitoring capabilities independently of the host system’s CPU, firmware (BIOS or UEFI) and operating system. The python-ipmi library provides API for using IPMI protocol within the python environment.[…]
This isn’t the first SuperMicro IPMI Python project. There are others, for example:
VisualUefiBios is a utility that lets you run EDK2 UEFI firmware inside QUEMU. This helps geeks provide build environment without messing up with lot of edk2 build commands.
Somewhat similar to QEMU usage inside VisualUEFI, AFAICT.
A new UEFI exploit project. CHIPSEC-, Windows-, and Powershell-dependent. Includes a verbose PDF.
“A standalone python script leveraging ntdll for UEFI variable enumeration. This uses elements from the “chipsec” toolkit for formatting when extracting NVRAM buffer from the ntdll library function and underlying runtime service.”
Here’s a few UEFI tools I’ve not seen before. But they’re binary-only Windows executables, no source code provided in the Github repro, so be careful if you try to run them. It appears you might need to have an AMI BIOS for some of the tools.
Most laptop manufactures lock down their BIOSes very securely with RSA signing nowadays. This bypasses the dillema of finding a bypass to flash a modified BIOS and instead modifies the NVRAM registers instead.[…]
This tool is based on Windows 7/10 and python 2.7, and works for AMI UEFI BIOS
1. Open Windows console
2. Call AMISetup_IFR.bat <motherboard-bios-file>
3. Call python main.py
4. Copy all files in ‘_Setup’ directory to GRUB2 config directory, overwrite the file if already exists
5. Reboot your computer from GRUB2 disk in UEFI mode
Gate is sample macOS app that contains a CryptoTokenKit (CTK) extension and demonstrates some new ways to work with tokens in macOS:
1. Insert and remove X.509 certificates into the keychain API without a physical smartcard insertion event. Applications can insert certificates into the keychain that are used for cryptographic operations with an embedded CryptoTokenKit extension.
2. Associate a certificate with a ECC private key created in the Secure Enclave on T2-enabled Macs.
3. Authenticate with built-in authentication (Login Window, Screen Saver, System Preferences locks, sudo, ssh, web) using an identity in the Secure Enclave.
Detecting backdoors in hardware is hard. I just noticed this paper from last year:
X-Ray Tech Lays Chip Secrets Bare: Researchers in Switzerland and the U.S. have a non-destructive technique that can reverse engineer an entire chip without damaging it[…]
By: Dominik Maier, Lukas Seidel, Shinjo Park
Rogue base stations are an effective attack vector. Cellular basebands represent a critical part of the smartphone’s security: they parse large amounts of data even before authentication. They can, therefore, grant an attacker a very stealthy way to gather information about calls placed and even to escalate to the main operating system, over-the-air. In this paper, we discuss a novel cellular fuzzing framework that aims to help security researchers find critical bugs in cellular basebands and similar embedded systems. BaseSAFE allows partial rehosting of cellular basebands for fast instrumented fuzzing off-device, even for closed-source firmware blobs. BaseSAFE’s sanitizing drop-in allocator, enables spotting heap-based buffer-overflows quickly. Using our proof-of-concept harness, we fuzzed various parsers of the Nucleus RTOS-based MediaTek cellular baseband that are accessible from rogue base stations. The emulator instrumentation is highly optimized, reaching hundreds of executions per second on each core for our complex test case, around 15k test-cases per second in total. Furthermore, we discuss attack vectors for baseband modems. To the best of our knowledge, this is the first use of emulation-based fuzzing for security testing of commercial cellular basebands. Most of the tooling and approaches of BaseSAFE are also applicable for other low-level kernels and firmware. Using BaseSAFE, we were able to find memory corruptions including heap out-of-bounds writes using our proof-of-concept fuzzing harness in the MediaTek cellular baseband. BaseSAFE, the harness, and a large collection of LTE signaling message test cases will be released open-source upon publication of this paper.
Maybe we need to wait until WiSec2020 to see code?