Tag: TianoCore

Tianocore to get RISC-V port

~ hucktech ~ 2 Comments

UEFI’s Tianocore implementation has built-in support for Intel/AMD and ARM. The RISCV-V port has been in a branch. Now it appears RISC-V is about to become part of the main branch, with 2 new packages, RiscVPkg and RiscVVirtPkg:

RISC-V is a new ISA which was designed to support computer architecture research and education. But now it becomes a standard open architecture for industry implementations. RISC-V edk2 project is to create a new processor binding in UEFI spec and to have RISC-V edk2 implementation. The goal is to have RISC-V edk2 port as the firmware reference for RISC-V platforms. Also, this proves the UEFI spec and edk2 implementation are flexible and well deisgned for adopting any processor architecture. The following modules are related to edk2 RISC-V port:

RiscVPkg – RISC-V processor package. This package provides RISC-V processor related protocols/libraries accroding to UEFI specification and edk2 implementations.

RiscVVirtPkg – RISC-V QEMU port. This is the RISC-V platform which is based on QEMU implementation. We use PC/At bus architecture as RISC-V platform bus spec. The image built from this package can be launched by QEMU RISC-V port.

https://bugzilla.tianocore.org/show_bug.cgi?id=2532

https://bugzilla.tianocore.org/show_bug.cgi?id=2533

https://github.com/riscv/riscv-uefi-edk2-docs

https://github.com/tianocore/edk2-staging/tree/RISC-V

NASM-UEFI: UEFI sample application built in NASM

~ hucktech ~ 1 Comment

OS Development on Windows – Part 1: Building a UEFI Application in NASM

This is a series of articles on developing your own operating system. We will be focusing on modern techniques, like UEFI booting and 64-bit assembly, and everything will be created from scratch. I will be going step-by-step, explaining every tool we use and every line of code, so that you have a thorough understanding of the process. You should be able to copy-paste these steps and get the same results I am describing. In addition, we will be doing this on Windows and using the tools available on this platform only. OS development is almost exclusively done on UNIX-like systems because the tools are more readily available and documented. I hope to show you how easy this is to do on Windows too.[…]

https://github.com/BrianOtto/nasm-uefi

https://hackerpulp.com/os/os-development-windows-1-building-uefi-applications-nasm/

UEFI

2 new Tianocore/EDK2 security advisories

~ hucktech ~ Leave a comment

Tianocore Security Advisories has 2 new UEFI vulnerabilities:

https://edk2-docs.gitbooks.io/security-advisory/content/

30. EDK II Authenticated Variable Bypass
Logic error in MdeModulePkg in EDK II firmware may allow authenticated user to potentially bypass configuration access controls and escalate privileges via local access.
https://edk2-docs.gitbooks.io/security-advisory/content/edk-ii-authenticated-variable-bypass.html

31. EDK II TianoCompress Bounds Checking Issues: Multiple privilege escalation vulnerabilities in TianoCompress and UEFICompress decompression algorithm may allow authenticated user to potentially manipulate stack and heap buffers via local access.

https://edk2-docs.gitbooks.io/security-advisory/content/edk-ii-tianocompress-bounds-checking-issues.html

Microsoft Project Mu: adaptation of TianoCore’s EDK2

~ hucktech ~ 1 Comment

https://github.com/Microsoft/mu_plus

https://github.com/Microsoft/mu_basecore

6 repos: https://github.com/topics/projectmu

https://microsoft.github.io/mu/faq/

https://microsoft.github.io/mu/

Project Mu is a modular adaptation of TianoCore’s edk2 tuned for building modern devices using a scalable, maintainable, and reusable pattern. Mu is built around the idea that shipping and maintaining a UEFI product is an ongoing collaboration between numerous partners. For too long the industry has built products using a “forking” model combined with copy/paste/rename and with each new product the maintenance burden grows to such a level that updates are near impossible due to cost and risk.

Project Mu also tries to address the complex business relationships and legal challenges facing partners today. To build most products it often requires both closed-source, proprietary assets as well as open source and industry standard code. The distributed build system and multi-repository design allow product teams to keep code separate and connected to their original source while respecting legal and business boundaries.

Project Mu originated from building modern Windows PCs but its patterns and design allow it to be scaled down or up for whatever the final product’s intent. IoT, Server, PC, or any other form factor should be able to leverage the content.

CVE-2018-12169: Tianocore UEFI: Unauthenticated Firmware Chain-of-Trust Bypass

~ hucktech ~ Leave a comment

https://twitter.com/qrs/status/1044157466349633537

https://twitter.com/qrs/status/1044157473882591233

“The issue was reported by Trammell Hudson”

https://edk2-docs.gitbooks.io/security-advisory/content/unauthenticated-firmware-chain-of-trust-bypass.html

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12169

https://nvd.nist.gov/vuln/detail/CVE-2018-12169

https://exchange.xforce.ibmcloud.com/vulnerabilities/150223

fiano – LinuxBoot’s Go-based tools for modifying UEFI firmware images

~ hucktech ~ Leave a comment

utk: generic UEFI tool kit meant to handle rom images. Usage:
    utk parse <rom-file>
    utk extract [–force] <rom-file> <directory-to-extract-to>
    utk assemble <directory-to-extract-to> <out-rom-file>

fmap: parses flash maps. Usage:
    fmap checksum [md5|sha1|sha256] FILE
    fmap extract i FILE
    fmap jget JSONFILE FILE
    fmap jput JSONFILE FILE
    fmap summary FILE
    fmap usage FILE
    fmap verify FILE

https://github.com/linuxboot/fiano

Tianocore Security Advisories page updated

~ hucktech ~ Leave a comment

Re: https://firmwaresecurity.com/2018/07/11/intel-releases-a-dozen-new-security-advisories/

at least one of these recent Intel bugs should also be in the Tianocore Security Advisories list, and at least one of them was just added to it:

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

eg:

https://edk2-docs.gitbooks.io/security-advisory/content/untested-memory-not-covered-by-smm-page-protection.html

VolInfo: tool to dump the contents of a UEFI firmware volume (FV)

~ hucktech ~ Leave a comment

Tianocore includes UEFI developer tools for creating ‘blobs’. But it also includes one tool useful for security researchers to examine existing Firmware Volumes. It is an OS-present tool that works on Mac/Windows/Linux, not a UEFI Shell tool.

https://github.com/tianocore/edk2/blob/master/BaseTools/Source/C/VolInfo/VolInfo.c
https://github.com/tianocore/edk2/tree/master/BaseTools/Source/C/VolInfo
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Tools-List
https://github.com/tianocore/edk2/tree/master/BaseTools/UserManuals
https://raw.githubusercontent.com/tianocore/edk2/master/BaseTools/UserManuals/VolInfo_Utility_Man_Page.rtf
https://edk2-docs.gitbooks.io/edk-ii-build-specification/content/v/release/1.27/2_design_discussion/22_uefipi_firmware_images.html
http://wiki.phoenix.com/wiki/index.php/EFI_FIRMWARE_VOLUME_HEADER

Usage: VolInfo [options] <input_file>
Display Tiano Firmware Volume FFS image information
   -h, –help — Show this help message and exit
   –version — Show program’s version number and exit
   -d [DEBUG], –debug [DEBUG] — Output DEBUG statements, where DEBUG_LEVEL is 0 (min) – 9 (max)
   -v, –verbose — Print informational statements
   -q, –quiet — Returns the exit code, error messages will be displayed
   -s, –silent — Returns only the exit code; informational and errorvmessages are not displayed
   -x XREF_FILENAME, –xref XREF_FILENAME — Parse the basename to file-guid cross reference file(s)
  -f OFFSET, –offset OFFSET — The offset from the start of the input file to start processing an FV
  –hash — Generate HASH value of the entire PE image

Tianocore releases UDK2018

~ hucktech ~ Leave a comment

Tianocore, not the UEFI Forum, has released UDK2018, the latest UEFI Dev Kit, a snapshot of the EDK-II, tied to particular revision of the specs.

https://github.com/tianocore/tianocore.github.io/wiki/UDK2018-Core-Update-Notes

https://github.com/tianocore/tianocore.github.io/wiki/UDK2018-Key-Features

https://github.com/tianocore/tianocore.github.io/wiki/UDK2018

https://github.com/tianocore/edk2/releases/tag/vUDK2018

https://github.com/tianocore-docs/Docs/blob/master/UDK/UDK2018/SecurityPkgNotes.md

 

alt archive for edk2-devel mailing list

~ hucktech ~ Leave a comment

Multiple URLs on this blog point to the Tianocore EDK2 development mailing list for more information.

https://lists.01.org/mailman/listinfo/edk2-devel

However, there’s a few broken links on the archive page for that list.

Here is more info on some changes to the list archives:

https://lists.01.org/pipermail/edk2-devel/2016-July/000000.html

Here is another source of archives of the list:

https://www.mail-archive.com/edk2-devel@lists.01.org/info.html

Thanks to the edk2-devel-owners for a pointer to this alt archive site.

 

docker-edk2-uefi: Docker container for Tianocore EDK2 dev

~ hucktech ~ Leave a comment

Container to build Tianocore EDK2 MdeModules and OVMF and run in OVMF with qemu using X over ssh

UEFI EDKII Development Environment

This docker container can be used to build projects based on the Tiano EDKII UEFI project. It is possible to selected the branch of the EDKII project to be used and compiled at container creation as well as the target architecture. Build Tools are compiled on first ssh login triggered in bashrc. qemu can be run with X over ssh. Scripts are included to build MdeModulePkg and OVMF. Script included to create base for OVMF qemu environment and start qemu (script only for x86/64 right now).[…]

https://hub.docker.com/r/geneerik/docker-edk2-uefi/

Somewhat related, I also found these UEFI/Docker options:

https://hub.docker.com/r/rojuinex/edk2-uefi/~/dockerfile/
https://hub.docker.com/r/michas2/edk2-test/~/dockerfile/

PS: Wondering what he’s been messing with UEFI on:

 

Tianocore Security Advisory 27: Minnowboard UEFI Variable Deletion/Corruption

~ hucktech ~ Leave a comment

Tianocore EDK2 security advisory page has been updated, for the first time since 2016! It looks like a single entry:

https://edk2-docs.gitbooks.io/security-advisory/content/

27. UEFI Variable Deletion/Corruption

Description: Input validation error in MinnowBoard 3 Firmware versions prior to 0.65 allow local attacker to cause denial of service via UEFI APIs.

Recommendation: This update improves input validation by firmware and is strongly recommended. For firmware development projects, incorporate the updates in https://github.com/tianocore/edk2-platforms/tree/devel-MinnowBoard3-UDK2017. When using MinnowBoard 3, update to version 0.65 or later. Updated firmware is available at https://firmware.intel.com/projects/minnowboard3

Acknowledgments: Reported by Intel.

References: CVE-2017-5699

The referenced CVE is still empty, hopefully someone at Intel/MITRE/NIST is going to take care of that sometime.

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2017-5699
https://nvd.nist.gov/vuln/detail/CVE-2017-5699

 

UEFIStarter: framework to simplify UEFI development with TianoCore EDK2

~ hucktech ~ Leave a comment

This is a small C framework for UEFI development built on top of TianoCore EDK2. This project is not a comprehensive course in UEFI development. If you’re just starting to write UEFI code you’ll need to use additional material like the official TianoCore documentation, and the UEFI Specification. The library and UEFI applications included in this code are meant to simplify a few repetitive tasks when developing UEFI code. For example there is a configurable command line argument parser that will validate input strings and convert them into the target datatype, e.g. integers. This project started out with another UEFI development kit (gnu-efi) but eventually outgrew the original SDK, so I migrated it to TianoCore EDK2017. As a result of this there are still a few library functions included that are already built-in into TianoCore. It is my hope that this code helps anyone looking into, or starting with, UEFI development: I did that myself a few months ago and found parts of the various documentations frustratingly lacking. If I can spare you some of the headache I had I’m happy.

https://github.com/rinusser/UEFIStarter

Pete Batard adds ARM support for VS2017 to Tianocore

~ hucktech ~ Leave a comment

Pete Batard  is adding Visual Studio for ARM support to the Tianocore UEFI dev toolchain:

This is a v2 of the previous patch, that takes into account the alignment of suppressed level 4 warnings between IA32, X64 and ARM, and that also removes compiler options that weren’t actually needed. The following series adds ARM compilation support for the VS2017 toolchain. With these patches, VS2017 toolchain users should be able to compile regular UEFI ARM applications using EDK2. Note that, unlike ARM64 support, ARM support does not require a specific update of Visual Studio 2017, as the ARM toolchain has been available from the very first release. We tested compiling and running the full UEFI Shell with this series, as well as a small set of applications and drivers, and found no issues. With an additional patch [1], it is also possible to use this proposal to compile a complete QEMU ARM firmware. As the patch shows, the changes that need to be applied to the EDK2 sources to achieve this are actually very minimal. However, the generated firmware does not currently boot, possibly because of the following warnings being generated by the MS compiler[…[]At this stage, since the goal of this series is to allow users to compile regular ARM UEFI applications using the VS2017 toolchain, I have non plans to spend more time on the QEMU firmware issues, especially as I suspect that reducing the firmware size back to 2 MB may not be achievable without Microsoft altering their compiler. I am however hopeful that ARM specialists can take this matter over eventually…

[1] https://github.com/pbatard/edk2/commit/c4ce41094a46f4f3dc7ccc64a90604813f037b13

More info:
http://pete.akeo.ie/2017/05/compiling-desktop-arm-applications-with.html
https://lists.01.org/mailman/listinfo/edk2-devel
https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/18614308-add-arm-support-back
https://blogs.msdn.microsoft.com/vcblog/2017/10/23/arm-gcc-cross-compilation-in-visual-studio/
https://github.com/microsoft/vslinux/issues
https://github.com/Microsoft/VSLinux/issues/110

See-also:
http://shadetail.com/blog/using-visual-studio-code-for-arm-development-introduction/

Note that Pete is not from the Microsoft Visual Studio team, he’s just doing their work for them… I hope the VS team gives Pete a complementary subscription to their commercial product! [Strange, I don’t think I’ve ever seen Microsoft add suppport for their own tools to Tianocore, it is always an external vendor that does Microsoft’s work…]

 

Fall UEFI Plugfest agenda

~ hucktech ~ Leave a comment

The Fall UEFI Plugfest is happening, a week of interop testing with UEFI vendors, along with some presentations. The presentation abstracts are below, see the full itenary for speaker bios.

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

http://www.uefi.org/sites/default/files/resources/Agenda%20and%20Session%20Abstracts%20-%20Final_Oct%2024%202017.pdf

“Last Mile” Barriers to Removing Legacy BIOS (Intel)
While UEFI has become a dominant standard since its introduction in 2005, many use cases still rely on compatibility with PC/AT Legacy BIOS. These legacy corner cases are a barrier to completing the transition to modern firmware standards. Intel has identified maintaining compatibility as an issue for platform security and validation costs, and plans to eliminate legacy BIOS elements in our 2020 data center platforms. This session discusses “last mile” gaps for 16-bit compatibility and identifies UEFI capabilities that the industry can promote as alternatives, including HTTPS Boot, OS Recovery, and Signed Capsule Update.

UEFI Firmware – Security Concerns and Best Practices (Phoenix)
(no Abstract)

Strategies for Stronger Software SMI Security in UEFI Firmware (Insyde)
Avoid design errors and software coding pitfalls when implementing SMI handlers. Device manufacturers customize UEFI firmware using new runtime interfaces that are implemented using software SMIs. Heavy customization, tight deadlines and poor code implementation can accidentally allow malware to abuse the power of SMM. This session focuses on four common software SMI vulnerabilities and how to change your UEFI firmware and applications to avoid them.

Advances of UEFI Technologies in ARM Systems (ARM)
This session will discuss the ARM-related interfaces defined in the latest UEFI and ACPI specifications, the requirements of the UEFI and ACPI interfaces for the SBBR Specification, and the use of UEFI SCT and FWTS in the SBBR compliance test. Also, discussed will be the required UEFI interfaces for the embedded space when the separation of the device and OS development is desired.

Introduction to the Self-Certification Test (SCT) in UEFI World (Canonical and Intel)
The UEFI Test Working Group (UTWG) endorses two test suites: Firmware Test Suite (FWTS) and the UEFI Self-Certification Test (SCT). FWTS is focused on validating Linux compatibility, and is endorsed by UTWG for ACPI validation. The UEFI SCT is designed to validate firmware and driver behavior per the UEFI Specification. This session demonstrates the operation of both tools, and discusses how they use open source models to improve test quality.

Firmware Test Suite Introduction: Uses, Development, Contribution and GPL (Canonical)
Firmware Test Suite (FWTS) is the recommended ACPI 6.1 Self-Certification Test (SCT). This command line tool is easy to use and provides explanatory and informative. Its open-source nature allows developers to add new tests easily, and many code examples such as ACPI, UEFI and SMBIOS are available for references. Code contribution are appreciated and technical discussion and code reviews on the mailing list are answered by an active community. As licensed by GPL, FWTS ensures it is available and suitable to everyone who wants to use it publicly and privately.

NFC and UEFI (AMI)
NFC is a technology that has permeated many aspects of everyday life. Using NFC, you can now pay with your phone or enter secure building areas. However, the UEFI specification lacks any implementation of NFC. AMI will cover a proposed solution for NFC implementation in UEFI, how to best fit NFC into the UEFI specification, and potential use cases.

Edk2 Platforms Overview (Linaro)
For a couple of years now, the Linaro OpenPlatformPkg repository has been used to collate a number of (at least partially) open source EDK2 platform ports. However, with a now properly defined process for the TianoCore edk2-platforms and edk2-non-osi repositories, these platforms are now moving over there and OpenPlatformPkg. This session will discuss the process, the current state of things and the practicalities of working with edk2-platforms.

UEFI Manageability and REST Services (HPE and Intel)
With the increase in platform firmware complexity and capabilities, there is an increased need to standard firmware manageability is increasing. The UEFI 2.7 Specification defines REST services to provide secure solutions for managing modern platforms. This session describes enterprise configuration scenarios, discusses implementation gaps in the UEFI specification, and proposes enhancements related to vendor-specific REST services.

Alex updates smmtestbuildscript for Fedora 26 and QEMU 2.9

~ hucktech ~ Leave a comment

A while ago[1], Alex Floyd of PreOS Security wrote a shell script to help codify this wiki article[2] by Laslo Ersek of Red Hat, setting up a UEFI SMM/OVMF testing environment for Fedora-based systems. Recently, Alex updated this script to work with the recently-released Fedora 26. Quoting email from Alex on the changes in this release:

The build script has been updated for Fedora 26 support. It now uses the native QEMU 2.9 library from Fedora 26 and no longer builds a snapshot of QEMU 2.9 which makes some new testing possibilities available.

https://github.com/gencymex/smmtestbuildscript

[1] https://firmwaresecurity.com/2017/04/19/shell-script-for-laszlos-smm-test-environment-article/

[2] https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt