Tag: UEFI

Simple-UEFI-Bootloader: for bare-metal x86-64 applications

~ hucktech ~ Leave a comment

Simple-UEFI-Bootloader

A UEFI bootloader for bare-metal x86-64 applications. It’s like a much simpler version of GRUB, mainly meant for writing your own operating system-less 64-bit programs. Supports Windows, Linux, and Mac executable binaries (PE32+, 64-bit ELF, and 64-bit Mach-O formats). It also supports… Well, I’ll let you figure that one out yourself. ;)[…]

 

https://github.com/KNNSpeed/Simple-UEFI-Bootloader

PeiBackdoor

~ hucktech ~ Leave a comment

Re: https://firmwaresecurity.com/2016/08/28/peibackdoor-new-uefi-payloadbackdoor-tool/

N0where.net has a new story showing how to use this backdoor, and various Twitter news sites are also covering this. 🙂

https://github.com/Cr4sh/PeiBackdoor

https://twitter.com/Hackers_toolbox/status/941957029878468608

https://n0where.net/pei-stage-backdoor-for-uefi-compatible-firmware-peibackdoor/

BTW, the blog site for Dmytro has been down for a few days. A few months ago, it was down for about a week. Hopefully it’ll come back again.
http://blog.cr4.sh/

 

 

RaspberryPiPkg – 64-bit Tiano Core UEFI for the Raspberry Pi 3

~ hucktech ~ Leave a comment

64-bit Tiano Core UEFI for the Raspberry Pi 3

Last updated December 14th, 2017.

This is an implementation of a 64-bit UEFI firmware for the RPi3 platform, based off Ard Bisheuvel’s 64-bit http://www.workofard.com/2017/02/uefi-on-the-pi/ and Microsoft’s 32-bit https://github.com/ms-iot/RPi-UEFI/tree/ms-iot/Pi3BoardPkg. Initially, this was supposed to be an easy walk in the park, where the Microsoft drivers just sorta slide into Ard’s UEFI implementation, and I call it a day. It turned out to be a bit more frustrating of an experience than that :-). This is meant as a generally useful 64-bit UEFI implementation for the Pi3, good enough for most kinds of UEFI development and good enough for running real operating systems. It has been validated to install and boot Linux and FreeBSD.[…]

https://github.com/andreiw/RaspberryPiPkg

Linaro releases Enterprise Reference Platform 17.12

~ hucktech ~ Leave a comment

ERP 17.12 has been released!

The goal of the Linaro Enterprise Reference Platform is to provide a fully tested, end to end, documented, open source implementation for ARM based Enterprise servers. The Reference Platform includes kernel, a community supported userspace and additional relevant open source projects, and is validated against existing firmware releases. The Linaro Enterprise Reference Platform is built and tested on Linaro Enterprise Group members hardware and the Linaro Developer Cloud. It is intended to be a reference example for use as a foundation for members and partners for their products based on open source technologies. The members and partners to include distribution, hyperscaler or OEM/ODM vendors, can leverage the reference for ARM in the datacenter.
[…]
– Focused on ACPI and UEFI use-cases.
[…]

http://releases.linaro.org/reference-platform/enterprise/17.12/
https://platforms.linaro.org/documentation/Reference-Platform/Platforms/Enterprise/ReleaseNotes-17.12.md/

More info: linaro-announce@lists.linaro.org list archives:
https://lists.linaro.org/mailman/listinfo/linaro-announce

FAT-EFI: FAT EFI loader plugin for Hopper Disassembler

~ hucktech ~ Leave a comment

This project is a FAT EFI loader plugin for Hopper Disassembler. Apple uses an extension to the standard PE format for EFI binaries to allow FAT EFI binaries that contain both 32 and 64 bits executables. It is very similar to the FAT format, except for a different magic number and for little endianness. This plugin allows to read these FAT EFI binaries with Hopper Disassembler.[…]

https://github.com/pascalwerz/FAT-EFI

https://www.hopperapp.com/

Similar: https://github.com/0xc010d/EFIFatBinary.hopperLoader

Brian: Using CHIPSEC Whitelists to Improve Firmware Security

~ hucktech ~ Leave a comment

[Strange, I was doing the previous blog post on Brian, and during that time, he did a new blog post…]

Brian Richardson of Intel has a new blog post on using CHIPSEC whitelist command to help with UEFI security:

Using Whitelists to Improve Firmware Security

Firmware has become more popular in the world of computer security research. Attacks operating at the firmware level can be difficult to discover, and have the potential to persist even in bare-metal recovery scenarios. This type of hack has been well documented by investigations of the HackingTeam and Vault7 exploits. Fortunately, there are methods for detecting and defending against such attacks. Firmware-based attacks typically attempt to add or modify system firmware modules stored in NVRAM. Tools provided by the open source CHIPSEC project can be used to generate and verify hashes of these modules, so users can detect unauthorized changes.[…]

https://software.intel.com/en-us/blogs/2017/12/05/using-whitelists-to-improve-firmware-security
https://github.com/chipsec/chipsec

CHIPSEC in Ubuntu Linux

UEFI-var-in-disk: Inject the UEFI variable in the first sector of hard disk

~ hucktech ~ Leave a comment

Bluntly, I’m not sure what this month-old project does yet, the title/tagline sounds more interesting than the usage, and I’ve not done a code review yet.

Inject the UEFI variable in the first sector of hard disk

usage text:
efi2disk version %s\n”, TOOL_VERSION);
usage: efi2disk [options]
-r | –read Read UFEI variable information
-V | –version return version and exit
-h | –help show help/usage

https://github.com/NeoCui/UEFI-var-in-disk

proposal: add Security Version to Linux Shim

~ hucktech ~ Leave a comment

Gary Ching-Pang Lin of SuSE has submitted a proposal for Linux kernel and Shim to include a Security Version. In addition to below shim wiki page, there is active discussion on this on the Linux-EFI list.

Security Version

When a vulnerability is found, every distro will release the patch as soon as possible and push it into the update channel. However, since the signature of the old kernel is still valid, the attacker may trick the user to boot the old and insecure kernel to exploit the system. For the system with UEFI Secure Boot, although the admin can add the hashes of the insecure kernels into MokX, it could be burdensome to do this in large scale. Besides, it’s almost impossible to obsolete the kernels before a certain version. Not to mention that the old kernel sometimes might be useful for debugging. To keep the system secure and also flexible, we propose “Security Version”. The basic concept of Security Version is to use a whitelist to record the “version” of the latest known secure linux kernel. If the “version” of the kernel is lower than that in the whitelist, then the kernel is considered as “not secure”. The “version” in the whitelist can only be incremented monotonically unless the user decides to lower it.[…]

https://github.com/lcp/shim/wiki/Security-Version

https://marc.info/?l=linux-efi&m=151246813626512&w=2

PS:  Hmm, Gmane’s linux-efi links aren’t working for me.
http://dir.gmane.org/gmane.linux.kernel.efi

IfrViewer: Viewer for IFR structures

~ hucktech ~ 1 Comment

IfrViewer: tool that is able to read a binary HPK package and most (hopefully all in future) of its HII and IFR structures. A HPK file (used by EDKII) holds so called HII packages (Human Interface Infrastructure). The content of such a file follows the kind of file structure definition from UEFI specification. It can consist of many various things but in most cases it consists of strings for different languages and IFR structures (Internal Forms Representation) to be able to build the SETUP menu for UEFI capable systems.

* List all IFR structures in order to view a HPK’s content
* Improve GUI to handle this data more efficient
* Create HTML pages which can be viewed by standard web browser showing the skeleton of the HPK’s forms

 

https://github.com/topeterk/IfrViewer

 

Qualcomm seeks bootloader engineer

~ hucktech ~ Leave a comment

Embedded Software Engineer – Bootloaders
Qualcomm processors provide integrated solutions for millions of diverse mobile and new emerging platforms across IoT, Automotive and Compute markets. It all starts with the Boot Firmware the first mission critical code to execute on our SoC(System on chip) and prepare the system for operation. We design and develop the software we put in mask boot ROM, along with system boot-loaders. Features we work on include image authentication, multicore setup, the UEFI pre-boot environment, configuration of next-generation DDR memories, ARM CPU and custom Qualcomm DSP/microprocessors, MMU/Cache memory management and advanced driver development for multiple boot/storage devices including eMMC, UFS, NAND, SPI-NOR, QSPI and flashless boot transport interfaces such as PCIe, SDIO, USB. Embedded Bootloader design & development involves architecting solutions to address different use cases and feature requirements in the early bootloader environment before the handoff to the High Level Operating System kernel. Engineer is expected to work with different Qualcomm build infrastructure tools and ARM compiler tool chains to enable different drivers and services for Bootloaders, optimizing them both for boot time, internal memory size constraints and power metrics.
* Design, development and integration of custom and/or open source Bootloaders for QCT mobile platforms.
* ThreadX, Linux, Android, Windows Boot process knowhow
* UEFI (Unified Extensible Firmware Interface) based bootloader and device driver model experience
* coreboot, uboot based bootloader experiences

 

https://jobs.qualcomm.com/public/jobDetails.xhtml?requisitionId=1960693

AMI on Intel’s BIOS end-of-life announcement

~ hucktech ~ Leave a comment

 

https://ami.com/en/tech-blog/intel-says-bye-to-bios-by-2020/

Click to access Brian_Richardson_Intel_Final.pdf

 

The UEFI Forum likes to frame UEFI -vs- BIOS, and has a 3-5 Class heirarchy of those systems, including having to deal with UEFI systems that also provide BIOS via Compatibility Support Module (CSM), referring to BIOS as Legacy Mode. If you look at BIOS outside of the framing of the UEFI Forum, it is usually based security, and UEFI has some security where BIOS has none. But there’s another ‘class’: non-UEFI coreboot, optionally secured with Verified Boot, with a BIOS payload. UEFI Forum doesn’t include this in their Class heirarchy… AFAICT, the mainstream IBVs have given up on BIOS and migrated to UEFI. The only places where BIOS will probably remain are in Purism boxes, where they will use TPM+Heads to secure BIOS, or on Chrome boxes, where they will use coreboot Verified Boot to secure BIOS, or in SeaBIOS-based VMs. When Intel stops offering Intel’s implementation of BIOS, maybe this means that the remaining BIOS users will switch to the open source SeaBIOS project, which is great news. Getting rid of the complex class of dual UEFI/BIOS systems will be a joy. 🙂

Nyan-Load (and EFI-Example)

~ hucktech ~ 1 Comment

nyan-load:
have you ever wanted a moving nyan cat as your bootloader? of course! now you can. the rainbow and cat tail moves as of right now, and work is being done to add stars in the background.
nyan-load code is based on efi-example.

EFI-example:  Self-contained minimal example of building an EFI application (under 64 bit Linux atm) without external build dependencies. This project was created to research the base for an EFI bootloader for the Haiku Operating System.

https://github.com/puckipedia/efi-example

https://github.com/ohnx/nyan-load

https://en.wikipedia.org/wiki/Nyan_Cat

image

Genode 17.11 released, UEFI support

~ hucktech ~ Leave a comment

[…]At the platform level, the release unifies the boot concept across all supported x86 microkernels and offers the option to boot 64-bit kernels via UEFI. For both UEFI and legacy boot, Genode consistently uses GRUB2 now.[…]

https://genode.org/documentation/release-notes/17.11
http://genode.org/