Tag: UEFI

new editions of Beyond BIOS and Harnessing the UEFI Shell

~ hucktech ~ Leave a comment

Intel Press published the first and second editions of these two books a few years ago, but it appears Degruyter is publishing revised third editions!

Harnessing the UEFI Shell: Moving the Platform Beyond DOS, Third Edition
Rothman, Michael / Zimmer, Vincent / Lewis, Tim
https://www.degruyter.com/view/product/484477

Beyond BIOS: Developing with the Unified Extensible Firmware Interface, Third Edition
Zimmer, Vincent / Marisetty, Suresh / Rothman, Michael
https://www.degruyter.com/view/product/484468

 

Tetris for UEFI

~ hucktech ~ Leave a comment

Nikolaj points out that there’s a UEFI port of the game Tetris …but I can’t find the source, only the binary:

As mentioned in the below Defiant UEFI game engine post below, there’s a Tetris for UEFI on Github with source, unclear if this is a different one than above:

EFI Pong

Firmware-Maze: UEFI game

dEFIant: new UEFI game engine

https://github.com/swmicro/Tetris

If someone has some spare time, please port MAME to UEFI. Please!

Tianocore updates Security Advisories

~ hucktech ~ Leave a comment

Previously, the advisories were in PDF format. There were 2 advisories, each PDF contained a number (19?, I forget) of issues. Now, they’ve moved to Github-hosted content using Gitbooks.

I’ve not yet checked if there are any NEW advisories in the new content.

https://www.gitbook.com/book/edk2-docs/security-advisory/details

PCIleech -vs- Apple Mac OS X

~ hucktech ~ Leave a comment

It appears Mac OS X 10.12.2 has some firmware-related security updates, with some defense against PCILeech:

http://blog.frizk.net/2016/12/filevault-password-retrieval.html
https://github.com/ufrisk/pcileech

https://twitter.com/aionescu/status/809590186447228928

 macOS FileVault2 Password Retrieval

“macOS FileVault2 let attackers with physical access retrieve the password in clear text by plugging in a $300 Thunderbolt device into a locked or sleeping mac. The password may be used to unlock the mac to access everything on it. To secure your mac just update it with the December 2016 patches. Anyone including, but not limited to, your colleagues, the police, the evil maid and the thief will have full access to your data as long as they can gain physical access – unless the mac is completely shut down. If the mac is sleeping it is still vulnerable. Just stroll up to a locked mac, plug in the Thunderbolt device, force a reboot (ctrl+cmd+power) and wait for the password to be displayed in less than 30 seconds!
[…]
Recovering the password is just one of the things that are possible unless the security update is applied. Since EFI memory can be overwritten it is possible to do more evil …
[…]
December 13th: Apple released macOS 10.12.2 which contains the security update. At least for some hardware – like my MacBook Air.
[…]”

Look at recent Tweets from Xeno Kovah, he has multiple posts with information about the 10.12.2 update:

https://twitter.com/XenoKovah/

Firmware passwords:
https://support.apple.com/en-us/HT202796
https://support.apple.com/en-us/HT204455
https://support.apple.com/en-us/HT203409

I’ll admit, I didn’t find any firmwaer information in their release:
https://support.apple.com/en-us/HT207423

ACPIview

~ hucktech ~ Leave a comment

Evan Lloyd and Sami Mujawar of ARM have submitted a new ACPI UEFI Shell tool for Tianocore.

[edk2] [PATCH] ShellPkg: Add acpiview tool to dump ACPI tables

This program is provided to allow examination of ACPI table contents from the UEFI Shell.  This can help with investigations, especially at that stage where the tables are not enabling an OS to boot. The program is not exhaustive, and only encapsulates detailed knowledge of a limited number of table types. Default behaviour is to display the content of all tables installed. ‘Known’ table types will be parsed and displayed with descriptions and field values.  Where appropriate a degree of consistency checking is done and errors may be reported in the output. Other table types will be displayed as an array of Hexadecimal bytes. To facilitate debugging, the -t and -b options can be used to generate a binary file image of a table that can be copied elsewhere for investigation using tools such as those provided by acpica.org.  This is especially relevant for AML type tables like DSDT and SSDT. The inspiration for this is the existing smbiosview Debug1 Shell command, and the command is also intended for Debug1. Many tables are not explicitly handled, in part because no examples are available for our testing. The program is designed to be extended to new tables with minimal effort, and contributions are invited.

The code is available for examination at:
https://github.com/EvanLloyd/tianocore/tree/651_acpiview_v1

STM added to Tianocore

~ hucktech ~ Leave a comment

Intel has submitted a patch to Tianocore to add STM support!

[edk2] [patch 0/4] Add STM (Smi Tranfer Monitor) support

This patch series is used to add STM support to UefiCpuPkg. More details about STM are described in:
http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf
https://firmware.intel.com/sites/default/files/STM_User_Guide-001.pdf
https://firmware.intel.com/sites/default/files/A_Tour_Beyond_BIOS_Launching_STM_to_Monitor_SMM_in_EFI_Developer_Kit_II.pdf

28 files changed, 6036 insertions(+), 65 deletions(-)

More info:
https://lists.01.org/mailman/listinfo/edk2-devel
https://firmwaresecurity.com/tag/stm/

 

Linux Kernel lockdown

~ hucktech ~ Leave a comment

David Howells of Red Hat submitted a 16-part patch to the Linux-(Security,EFI,Kernel) mailing lists, with an interesting security patch for the Linux kenel. The patch includes contributions from: David Howells, Josh Boyer, Kyle McMartin, Matthew Garrett, and Dave Young. Quoting the patch announcement:

These patches provide a facility by which a variety of avenues by which userspace can feasibly modify the running kernel image can be locked down. These include:

* No unsigned modules and no modules for which can’t validate the signature.
* No use of ioperm(), iopl() and no writing to /dev/port.
* No writing to /dev/mem or /dev/kmem.
* No hibernation.
* Restrict PCI BAR access.
* Restrict MSR access.
* No kexec_load().
* Certain ACPI restrictions.
* Restrict debugfs interface to ASUS WMI.

The lock-down can be configured to be triggered by the EFI secure boot status, provided the shim isn’t insecure.  The lock-down can be lifted by typing SysRq+x on a keyboard attached to the system. They are dependent for some EFI definitions on the keys-uefi branch.

Copy secure_boot flag in boot params across kexec reboot
Add the ability to lock down access to the running kernel image
efi: Get the secure boot status
efi: Lock down the kernel if booted in secure boot mode
efi: Disable secure boot if shim is in insecure mode
efi: Add EFI_SECURE_BOOT bit
hibernate: Disable when the kernel is locked down
acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down
Add a sysrq option to exit secure boot mode
kexec: Disable at runtime if the kernel is locked down
PCI: Lock down BAR access when the kernel is locked down
x86: Lock down IO port access when the kernel is locked down
ACPI: Limit access to custom_method when the kernel is locked down
asus-wmi: Restrict debugfs interface when the kernel is locked down
Restrict /dev/mem and /dev/kmem when the kernel is locked down
x86: Restrict MSR access when the kernel is locked down

More information:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-lockdown
http://vger.kernel.org/majordomo-info.html

Linux 4.10 UEFI changes

~ hucktech ~ Leave a comment

Matt Fleming posted UEFI changes for Linux 4.10 kernel.

Folks, please pull the following v4.10 material. There isn’t a huge amount of stuff here. The biggest change is the EFI dev path parser code from Lukas to get thunderbolt working on his macbook.
 * Fix an allocation bug in the generic EFI libstub where alignment and adjusted size isn’t taken into account – Roy Franz
 * Update the EFI MAINTAINERS entry to include ARM and arm64 files and directories – Ard Biesheuvel
 * Add new feature to seed the RNG from the stashed value returned by EFI_RNG_PROTOCOL in EFI stub and wire up for ARM/arm64 – Ard Biesheuvel
 * Retrieve Apple device properties from within the EFI stub to fully support thunderbolt devices on Apple Macbooks – Lukas Wunner

More details on the Thunderbolt patch:

thunderbolt: Use Device ROM retrieved from EFI:
Macs with Thunderbolt 1 do not have a unit-specific DROM: The DROM is empty with uid 0x1000000000000. (Apple started factory-burning a unit- specific DROM with Thunderbolt 2.) Instead, the NHI EFI driver supplies a DROM in a device property. Use it if available. It’s only available when booting with the efistub.  If it’s not available, silently fall back to our hardcoded DROM.  The size of the DROM is always 256 bytes. The number is hardcoded into the NHI EFI driver. This commit can deal with an arbitrary size however, just in case they ever change that.  Background information: The EFI firmware volume contains ROM files for the NHI, GMUX and several other chips as well as key material. This strategy allows Apple to deploy ROM or key updates by simply publishing an EFI firmware update on their website. Drivers do not access those files directly but rather through a file server via EFI protocol AC5E4829-A8FD-440B-AF33-9FFE013B12D8. Files are identified by GUID, the NHI DROM has 339370BD-CFC6-4454-8EF7-704653120818.  The NHI EFI driver amends that file with a unit-specific uid. The uid has 64 bit but its entropy is much lower: 24 bit represent the model, 24 bit are taken from a serial number, 16 bit are fixed. The NHI EFI driver obtains the serial number via the DataHub protocol, copies it into the DROM, calculates the CRC and submits the result as a device property.  A modification is needed in the resume code where we currently read the uid of all switches in the hierarchy to detect plug events that occurred during sleep. On Thunderbolt 1 root switches this will now lead to a mismatch between the uid of the empty DROM and the EFI DROM. Exempt the root switch from this check: It’s built in, so the uid should never change. However we continue to *read* the uid of the root switch, this seems like a good way to test its reachability after resume.

http://vger.kernel.org/majordomo-info.html
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-next