Tag: UEFI

AMI announces NVMe UEFI Option ROM service for OEMs

~ hucktech ~ Leave a comment

American Megatrends Provides Service for Developing NVMe UEFI Option ROMs for UEFI BIOS Firmware

AMI is pleased to announce new service for developing NVMe® UEFI Option ROMs. Recently, AMI added support for technologies such as NVMe metadata/data encryption and NVMe namespace management. Continuing its support for NVMe-related technologies, AMI has also developed UEFI NVMe Option ROMs. This service for developing UEFI NVMe Option ROMs enables OEMs and NVMe device manufacturers to ship NVMe devices with Option ROMs embedded in them. OEMs and NVMe device manufacturers will have the ability to add features that are traditionally unavailable with generic UEFI drivers and can implement vendor-specific commands and features within their devices. Some of the additional features that are available for NVMe Option ROMs include disk management for namespace management in BIOS setup, metadata/end-to-end data protection, NVMe firmware updates in BIOS setup and SMART data information. Interested OEMs and NVMe drive manufacturers should contact their AMI sales representative for more information.

https://ami.com/en/news/press-releases/american-megatrends-provides-service-for-developing-nvme-uefi-option-roms-for-uefi-bios-firmware/
http://ami.com/products/bios-uefi-firmware/aptio-v/

Minoca 0.4 released

~ hucktech ~ Leave a comment

I just noticed that Yabits  has a new Github project called “uefi”, which is a:

“A minoca based UEFI coreboot payload”

https://github.com/yabits/uefi

Yikes, I don’t know what Minoca is.

“Minoca OS is a general purpose operating system written from scratch. It aims to be lean, maintainable, modular, and compatible with existing software. It features a POSIX-like interface towards application software, and a growing suite of popular packages already built and ready to go. On the backend, it contains a powerful driver model between device drivers and the kernel. The driver model enables drivers to be written in a forward compatible manner, so that kernel level components can be upgraded without necessarily requiring a recompilation of all device drivers. Minoca OS is event driven, preemptible, SMP ready, and network capable. It currently runs on x86 PCs and a range of ARM boards.”

https://github.com/minoca/os/tree/master/boot/bootman/efi
https://github.com/minoca/os
https://www.minocacorp.com/documentation/developers/debug/docs/reference/
https://blog.minocacorp.com/minoca-os-0-4-we-love-the-eighties-170a93112db1
https://fossbytes.com/minoca-os-interview-open-source/
https://www.minocacorp.com/product/

Installing Git on Minoca OS

 

McAfee releases CHIPSEC 1.3.2

~ hucktech ~ Leave a comment

New or Updated Modules:
* Updated X64 Python for UEFI Shell

New or Updated Functionality:
* Updated FREG definitions
* Added mmap support to kernel module and chipsec device

Fixes:
* Fixed memory reads with kernel 4.8+
* Fixed version display in chipsec_util
* Fixed UEFI Shell X64 calling convention for SW SMI generation
* Fixed range check in bios_wp
* Fixed P2SB register accesses
* Fixed IOCTL_WRMMIO for x86_64 in Linux driver

Above relnotes aside, there are some other smaller features not listed above, in the changelog:
https://github.com/chipsec/chipsec/commits/master

I wish the CHIPSEC team signed their binary-only release of CPython 2.7x for UEFI, and/or included their build tree of the EDK2 that generates this, so we can build our own, hopefully ‘reproducably’.

I don’t see any ARM support[1]. Obviously, the title of below blog post was wrong, it was not released at Black Hat, AFAICT. Was this patch lost in Las Vegas? Is the ARM code a non-McAfee patch by Eclypsium that won’t be upstreamed into the GPL’ed CHIPSEC codebase? I wish I knew…

[1] https://firmwaresecurity.com/2017/07/25/chipsec-for-arm-to-be-released-at-black-hat/

Corona-X UEFI Bootloader

~ hucktech ~ Leave a comment

Corona makes a cross-platform 2D game engine. Wikipedia says: “Corona SDK is a software development kit (SDK) developed by Corona Labs Inc. Corona SDK allows software programmers to build mobile applications for iOS, Android, and Kindle, desktop applications for Windows and OS X, and connected TV applications for Apple TV and Android TV. Corona uses integrated Lua layered on top of C++/OpenGL to build graphic applications. The software has two subscription tiers: the free Corona SDK and the paid Corona Enterprise. A Corona Enterprise subscription adds the ability to use native code in app development.”

They also have a UEFI-based bootloader, not sure how this ties into their game engine…

Corona-X UEFI Bootloader and Kernel Loader
https://github.com/Corona-X/CXSystemLoader

https://coronalabs.com/

HellsRansomeware virus, aka UEFI ransomeware

~ hucktech ~ Leave a comment

I don’t know much about this other than below text. Heck, the below web site may be malware-laden, I’m not sure, click at your own risk.

https://twitter.com/2spyware/status/894859391979196416

http://www.2-spyware.com/remove-hellsransomware-virus.html

“HellsRansomware virus, or alternatively called as UEFI ransomware, is another file-encrypting threat ready to lock sensitive users’ data. To IT security specialists’ amusement, the developers claim the virus to be “the only legit ransomware which will give you your files back unlike the others which do not.”

 

UEFI BoF at LPC

~ hucktech ~ Leave a comment

UEFI Forum member Harry Hsiung of Intel will be presenting a Birds of a Feather presentation titled “The State of UEFI Technology.” The session will cover the latest UEFI specifications and variables, as well as features like HTTP Boot, Wi-Fi, Bluetooth, NVDIMM, Secure Boot and capsule update. Attendees will also learn about the latest UEFI SCT updates and other tests like the Linux UEFI Validation (LUV) and the Linux Firmware Test Suite (FWTS).

http://www.uefi.org/events/upcoming

http://www.uefi.org/node/3738

https://www.linuxplumbersconf.org/2017/

U-Boot UEFI updates, for standard distro boot

~ hucktech ~ Leave a comment

Rob Clark has a new 20-part RFC patch to U-Boot to significantly improve U-Boot’s UEFI support. I’ve included most of Rob’s comments below, see the patch for the code.

[PATCH v0 00/20] enough UEFI for standard distro boot

This patchset fleshes out EFI_LOADER enough to support booting an upstream \EFI\BOOT\bootaa64.efi (which then loads fallback.efi and then eventually the per-distro shim.efi which loads the per-distro grubaa64.efi) without resorting to hacks to hard-code u-boot to load a particular distro’s grub, or other hacks like setting up the distro installation as live-media. The first seven patches add dependencies that will be needed later in the series. Patches 8-15 make u-boot work with upstream grub, without relying on distro patches. Patches 16-19 add missing bits of the UEFI implementation needed to support shim/fallback. And finally patch 20 adds bootmanager support to avoid shim/fallback after first boot.

Background: with a normal UEFI implementation, the boot process is:

a) firmware (u-boot) looks at BootOrder and the BootXXXX variables to try to determine what to boot.
b) the firmware will look at the BootXXXX variables (which contain an EFI_LOAD_OPTION “struct” in order specified by BootOrder, and will boot the first bootable option.
c) The EFI_LOAD_OPTION specifies a device-path which identifies the device and file path of the .efi payload to exectute.

If there are no bootable options the firmware falls back to loading \EFI\BOOT\bootaa64.efi (exact name varies depending on arch), which then loads fallback.efi which uses the EFI_SIMPLE_FILE_SYSTEM_PROTCOL and EFI_FILE_PROTOCOL to search for \EFI\*\boot.csv, and will then set BootOrder and BootXXXX EFI variables accordingly so that on next boot fallback.efi is not necessary.

(I’m ignoring secure boot, it is out of scope here.)

For example, if you had both fedora and opensuse installed on the same disk in different partitions, you would have both:

+ \EFI\fedora\boot.csv
+ \EFI\opensuse\boot.csv

The former would contain the filename of \EFI\fedora\shim.efi and the latter to \EFI\opensuse\shim.efi (each of which would know to load \EFI\fedora\grubaa64.efi or \EFI\opensuse\grubaa64.efi). Based on this, fallback.efi would setup EFI_LOAD_OPTION’s Boot0000 and Boot0001 (and BootOrder would control the order the load-options are considered).

With a real UEFI fw there would also be some sort of boot-order menu (ie. hold down f9 at boot, and get a menu to pick which of the Boot* load-options to try first). That is not part of this patchset but would be a useful next step to allow installing multiple operating systems on the same disk.

This patchset provides EFI variable support during bootservices, so viewing or modifying EFI variables after linux ExitBootServices()’s is not possible. If the board supports saveenv() this will be called in efi_exit_boot_services() to persist variables that where set during the boot process. Making variables available after EBS is tricky on hardware that does not have dedicated storage, as after EBS u-boot no longer controls the devices. An approach that Alexander Graf suggested, is that since reboot/halt is controlled via UEFI, is that on boards that can ensure memory is persisted across reboot, to store modified EFI variables in a special memory location and turn halt into reboot uboot -> appropriate setenv() calls -> saveenv() -> halt in order to persist modified variables. Which is also not part of this patchset, and will likely require some board-specific help.

There will be some updates to this patchset depending on whether we move to c11 as Heinrich suggested (ie s/L”string”/u”string” and some changeups in the vsprintf patch). But rather than calling this an RFC (which I figured was more likely to get ignored for review) I am calling this a v0.

Thanks to Peter Jones for a couple of the patches, and a bunch of help understanding what the things above the UEFI fw expect (and fixing a few shim and grub bugs that we found along the way).

32 files changed, 2508 insertions(+), 329 deletions(-)

Full announcement from Rob:
https://lists.denx.de/pipermail/u-boot/2017-August/301203.html

 

archlinux-fde-uefi

~ hucktech ~ Leave a comment

A collection of brief guides for installing Arch Linux with LUKS full disk encryption over a UEFI based system. While I was further exploring the linux universe seeking the answer to the meaning of life, I met a challenge of never matched difficulty: full disk encryption using LUKS over a UEFI based system. Many are the guides available on the web but none of them fullfilled my thirst for knowledge, as some were for older non-GPT installs or a bit too vague for a first time approach of the argument. Therefore, here I share with you what I’ve learned during my journey… BTRFS as well!

https://github.com/archmirak/archlinux-fde-uefi

Hardened Linux: coreboot and CHIPSEC

~ hucktech ~ 1 Comment

A bit more information on Hardened Linux’s use of CHIPSEC, in this case coreboot-centric:

Hardened Linux: using CHIPSEC

“# Enabling some security features at runtime in case of which vendor provided implementation improperly.”

https://github.com/hardenedlinux/Debian-GNU-Linux-Profiles/blob/master/scripts/harbian_fw/fw_hardening_runtime.py

There aren’t many CHIPSEC-based codebases, Hardened Linux is one relatively new one.

UEFI-Boot

~ hucktech ~ Leave a comment

[[
CORRECTION:
It is not a boot loader, is a few bash shell scripts, that calls the efibootmgr to configure UEFI with Linux kernel, presuming a Ubuntu-based system.

I should have read the code before calling the code a boot loader. Mea culpa.
]]

UEFI-Boot is a new UEFI-centric, Linux-centric bootloader that lets you “Boot Linux directly from UEFI firmware (without any bootloader)”:

UEFI Boot – is a small and simple project aimed to organize the loading of linux kernel via UEFI firmware (without any bootloader). The synchronization of UEFI boot options with installed kernel versions is triggered via /etc/kernel/postinst.d and /etc/kernel/postrm.d kernel triggers.

https://github.com/slytomcat/UEFI-Boot

Intel’s Black Hat UEFI presentation online

~ hucktech ~ Leave a comment

Vincent has a new blog post about the recent talk about UEFI security that Intel just gave at Black Hat Briefings.

http://vzimmer.blogspot.com/2017/08/black-hat-usa-2017-firmware-is-new-black.html

https://www.blackhat.com/us-17/briefings.html#firmware-is-the-new-black-analyzing-past-three-years-of-bios-uefi-security-vulnerabilities

https://github.com/rrbranco/BlackHat2017

Click to access BlackHat2017-BlackBIOS-v0.13-Published.pdf

https://www.darkreading.com/vulnerabilities—threats/7-hardware-and-firmware-hacks-highlighted-at-black-hat-2017/d/d-id/1329442

Brian on UEFI security

~ hucktech ~ Leave a comment

Brian Richardson of Intel recently gave a talk about UEFI security at BSides Asheville, NC. Slides are on the below blog URL:

What you don’t know about firmware might get you 0wn3d

Following firmware developers on social media during Black Hat & Def Con can be a bit bewildering. Firmware is becoming more important in the realm of cybersecurity research. Most of the work I do is working with other firmware developers to make sure they understand current capabilities and trends, but that work may take months or years to hit the market. The people on the front lines of computer security need some understanding of what they can do today to help secure their systems. While many of my colleagues spent a very hot and crowded week in Las Vegas, I had a much cooler weekend at the Bsides conference in Asheville, NC. My “What you don’t know about firmware might get you 0wn3d” presentation is designed to describe the importance of firmware in computer security, and what can be done today to mitigate and detect common attacks against firmware. There are practical methods to prevent a number of common bootkit/rootkit attacks, platform security features to consider when purchasing new systems, and responsible ways to research firmware issues.[…]

https://software.intel.com/en-us/blogs/2017/07/29/what-you-don-t-know-about-firmware-might-get-you-0wn3d

CrowdStrike seeks UEFI/hypervisor researcher

~ hucktech ~ Leave a comment

Researcher – Strategic Research Initiatives (SRI):
As the core research and development arm of the CrowdStrike Falcon product, the Strategic Research Initiatives (SRI) Team is at the forefront of cutting-edge research into security-related systems and techniques. The team strives to deliver cross-platform features for mid to long-term, visionary projects that expand the capabilities of Falcon Sensor. New EDR techniques and data sources, UEFI/Hypervisor capability, PnP and network stack visibility, containerization, scripting engine introspection, and emulation/sandboxing are just a few examples of SRI projects.[…]

https://jobs.jobvite.com/careers/crowdstrike/job/oAlo4fw7?__jvst=Job%20Board

Google NERF: Non-Extensible Reduced Firmware

~ hucktech ~ Leave a comment

 

Open Source Summit North America 2017
September 11-14, 2017 – Los Angeles, CA
Replace Your Exploit-Ridden Firmware with Linux – Ronald Minnich, Google

With the WikiLeaks release of the vault7 material, the security of the UEFI (Unified Extensible Firmware Interface) firmware used in most PCs and laptops is once again a concern. UEFI is a proprietary and closed-source operating system, with a codebase almost as large as the Linux kernel, that runs when the system is powered on and continues to run after it boots the OS (hence its designation as a “Ring -2 hypervisor”). It is a great place to hide exploits since it never stops running, and these exploits are undetectable by kernels and programs. Our answer to this is NERF (Non-Extensible Reduced Firmware), an open source software system developed at Google to replace almost all of UEFI firmware with a tiny Linux kernel and initramfs. The initramfs file system contains an init and command line utilities from the u-root project (http://u-root.tk/), which are written in the Go language.

https://ossna2017.sched.com/event/BCsr/replace-your-exploit-ridden-firmware-with-linux-ronald-minnich-google?iframe=no&w=100%&sidebar=yes&bg=no

https://www.linkedin.com/pulse/open-hardware-servers-step-forward-jean-marie-verdun

Click to access Denver_2017_coreboot_u-root.pdf

U-Root: firmware solution written in Go

https://linuxfr.org/news/un-pas-en-avant-pour-les-serveurs-libres-le-projet-nerf

Porting UEFI to Apple PowerPC…

~ hucktech ~ 1 Comment

Porting UEFI to a new architecture:
So it turns out that blogging about something after the fact is pretty tough. I really wanted to blog about my PoC port of UEFI to the OpenPower ecosystem, but it’s incredibly difficult to go back and try to systematize something that’s been a few years back. So let’s try this again. This time, our victim will be a G4 12″ PowerBook6,8 with a 7447A. That’s a 32-bit PowerPC. Now, I’ll go in small steps and document everything. For added fun, we’ll begin porting on the target itself, at least until that gets too tedious. Also, I’ve a few OldWorld machines, a spare G4 12″ for parts and a G5, so hopefully this odyssey won’t be interrupted by old and failing hardware ;-). Keep in mind that each part is checked in along with the source code, so look at the entire commit. Each blog post will focus on the most important details.[…]

http://osdevnotes.blogspot.com/2017/07/porting-uefi-to-xxx-step-1.html
https://github.com/andreiw/ppcnw-edk2
https://github.com/andreiw/ppcnw-edk2/blob/master/PortingHowTo_p1.md

See-also:

Interview with Andrei Warkentin, OpenPOWER UEFI porter

Tianocore for OpenPOWER

 

UEFI:NTFS

~ hucktech ~ Leave a comment

UEFI:NTFS is a generic bootloader, that is designed to allow boot from an NTFS partition, in pure UEFI mode, even if your system does not natively support it. This is primarily intended for use with Rufus, but can also be used independently. In other words, UEFI:NTFS is designed to remove the restriction, which most UEFI systems have, of only providing boot support from a FAT32 partition, and enable the ability to also boot from NTFS partitions. This can be used, for instance, to UEFI-boot a Windows NTFS installation media, containing an install.wim that is larger than 4 GB (something FAT32 cannot support) or to allow dual BIOS + UEFI boot of ‘Windows To Go’ drives. […] Secure Boot must be disabled for UEFI:NTFS to work.[…]

https://github.com/eventus77/uefi-ntfs-boot

http://efi.akeo.ie/
https://rufus.akeo.ie/

 

Grub UEFI Settings Entry Adder

~ hucktech ~ Leave a comment

Grub UEFI Settings Entry Adder

The following repository adds a grub bootloader entry to boot into your UEFI/BIOS firmware settings. The underlying grub entry script (uefi-firmware) is a trimmed down version of this[1] script distributed by jsherz.com. The conditions have been removed as they no longer apply to recent linux versions. It shall be noted that I have NOT replaced the conditions, but rather removed them, hence I should remind you that the grub entry may not function on every device, depending on it’s linux setup, version and the hardware.

 

https://github.com/CTXz/grub-uefi-settings-entry

[1] https://jsherz.com/centos/grub/grub2/bios/uefi/boot/2015/11/21/centos-uefi-firmware-option.html