Tag: Secure Boot

SwiftOnSecurity on Windows/UEFI security

~ hucktech ~ Leave a comment

http://decentsecurity.com/#/securing-your-computer/

There’s a new guide to securing Windows systems. I enjoyed it because step 2 of the steps are firmware-centric, excerpted below, view the original doc, the excerpted formatting is a bit mangled, sorry.

I wish the advice mentioned using CHIPSEC to do security tests to see if system came from OEM with unfixable security flaws, and to use CHIPSEC or other tools — perhaps via LUV-live or directly — to save  a NIST SP-147-style ‘golden image’ of your ROM, doing periodic offline/forensic examination of your ROM images with CHIPSEC, UEFI Firmware Parser, and other tools. (I have no input as to the non-firmware Windows-centric input in the list.)

—

1.) Update BIOS
For best compatibility and security you should update your computer’s BIOS. A modern BIOS (really UEFI) is a full operating system that runs below and at the same time as Windows, and it needs patches too. People who built computers in the early 2000’s will tell you BIOS updates are risky, and they were, but not anymore. They deliver fixes, features, and security updates you won’t hear about on the news. Even new computers/motherboards need updates. If you’re starting from scratch, do the BIOS update after installing Windows 10. You can find the BIOS update tool on your manufacturer’s driver page for your computer model. You will need to reboot for it to take effect. If you have a Surface, BIOS updates are delivered through Windows Update.

—

3.) Configure BIOS
This is important and is something nobody talks about. From the boot of your computer, press the setup hotkey. It may be F1, F2, F8, F10, Del, or something else to get into SETUP mode. In the BIOS: Set a setup password. Make it simple, this is only to prevent malicious modification by someone in front of the computer or by a program trying to corrupt it. Change boot to/prioritize UEFI. Disable everything except UEFI DVD, UEFI HDD, and USB UEFI if you plan on using a USB stick to install Windows. Enable the TPM (if available) and SecureBoot (if available) options. This is super important. Disable 1394 (FireWire) and ExpressCard/PCMCIA (if you’re on a laptop) as a layer to further mitigate DMA attacks. This isn’t as important anymore, but if you don’t use them you might as well turn it off. If you want, and if the computer offers it, you can enable a System and HDD password. We will be using BitLocker to protect the disk, but this is an extra layer you can add if you want. I don’t. If you don’t use webcam or microphone, you may be able to turn them off in the BIOS. Save settings and shut down.

—

The Linux Foundation has some UEFI-centric, Linux-centric desktop advice, which has some overlaps in security methods to the above UEFI-centric, Windows-centric desktop advice:

Linux Foundation IT Security Policies: firmware guidance

The Crypto Party Handbook also has some related advice, for security/privacy-minded use. The Secure Desktop mailing list is the center of the universe for this, where the handful of Linux distributions that focus on secure/privacy as their main features, hang out. If you care about a secure OS, you should be using one of theirs, not an OS where security is not their primary concern.

https://github.com/cryptoparty/handbook

https://secure-os.org/pipermail/desktops/2015-October/000000.html
https://secure-os.org/desktops/charter/

[I need to find some similar security hardening checklist for ChomeOS-based, coreboot-based systems, instead of Windows-based UEFI/BIOS-based systems,  talking about ensuring TPM on x86/x64, using coreboot with Verified Boot, specifics on how to best adopt those keys, like how Nikolaj shows us how to adopt UEFI Secure Boot keys, and others show how to use MOK. Any tips appreciated, please leave a Comment (see left) or send email (see above right). Thanks.]

Ubuntu’s UEFI Secure Boot: not a security measure

~ hucktech ~ Leave a comment

[[UPDATE: As Teddy Reed points out, this information is in the Ubuntu wiki, not just in a Ubuntu bug report:

https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1401532

“IMPORTANT: Canonical’s Secure Boot implementation in Ubuntu 15.10 and early is primarily about hardware-enablement and this page focuses on how to test Secure Boot for common hardware-enablement configurations, not for enabling Secure Boot to harden your system. If you want to use Secure Boot as a security mechanism, an appropriate solution would be to use your own keys (optionally enrolling additional keys, see above) and update the bootloader to prohibit booting an unsigned kernel. Ubuntu 16.04 LTS is planned to enable enforcing secure boot (see LP: #1401532 for details). “]]

Research the implementation of UEFI Secure Boot by a Linux/FreeBSD distro before presuming to rely on it to provide any security. 😦

“Ubuntu’s support for secure boot is solely intended as a compatibility measure so that media can boot on secure boot enabled computers. There are no current plans to enable secure boot as a security measure.”

https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1475954/comments/1

 

FreeBSD’s 2015 UEFI update

~ hucktech ~ Leave a comment

From the FreeBSD Foundation’s December 2015 (end-of-year) update, in summarizing their development efforts, they mention firmware (as well as improvements to x86 hardware support, and AArch64 support):

 

UEFI and secure boot: FreeBSD’s UEFI boot support needs to interoperate with many different EFI firmware implementations, and it’s only after broad testing that we were able to identify some incompatibilities. Through effort from Foundation staff and from volunteers in the FreeBSD community we’ve fixed UEFI boot on a variety of hardware and virtualization platforms, including Apple Macbook and Mac Pro computers and VirtualBox and VMware. These improvements will be available in FreeBSD 11.0 and 10.3. We also started working on support for secure boot. To date we’ve been working on individual tools — the uefisign(8) utility to add Authenticode signatures to EFI files, and the sysutils/pesign, sysutils/sbsigntool and sysutils/shim ports. Next year we’ll integrate these components into a broader secure boot implementation.

More information: click on the tiny-URL PDF in the below tweet:

https://wiki.freebsd.org/UEFI

https://wiki.freebsd.org/SecureBoot

Brian on Secure Boot -vs- Nemesis

~ hucktech ~ Leave a comment

Brian Richardson of Intel wrote a new blog on the recent Nemesis malware:

(Nemesis targets BIOS-centric MBR not UEFI-centric GPT partititions.)

http://blogs.intel.com/evangelists/2015/12/08/nemesis-meet-uefi-secure-boot/

Linux and Secure Boot HOW-TO

~ hucktech ~ Leave a comment

Greig Paul has an article in Linux Journal, a new Security HOW-TO on UEFI Secure Boot.

Take Control of Your PC with UEFI Secure Boot

[..] This article focuses on a single useful but typically overlooked feature of UEFI: secure boot. Often maligned, you’ve probably encountered UEFI secure boot only when you disabled it during initial setup of your computer. Indeed, the introduction of secure boot was mired with controversy over Microsoft being in charge of signing third-party operating system code that would boot under a secure boot environment. In this article, we explore the basics of secure boot and how to take control of it. We describe how to install your own keys and sign your own binaries with those keys. We also show how you can build a single standalone GRUB EFI binary, which will protect your system from tampering, such as cold-boot attacks. Finally, we show how full disk encryption can be used to protect the entire hard disk, including the kernel image (which ordinarily needs to be stored unencrypted). […]

Full article:

http://www.linuxjournal.com/content/take-control-your-pc-uefi-secure-boot

Teddy Reed on bypassing Linux Secure Boot

~ hucktech ~ Leave a comment

Teddy Reed has a second article on UEFI, MinnowboardMax and Linux! This one is called “Minnowboard Max: Booting Linux Securely”, and talks about how the Linux shim is used, and enumerates the various ways this boot security can be bypassed.

[…] I say ‘more-or-less’ because there are tons of places where the verification can be subverted. Unfortunately, if you start examining the implementation and configuration details of the streamlined Secure Boot support, you’ll find plenty of bypasses. Let’s talk briefly about each bypass and conclude with a simple way to use Secure Boot and enforce a signed kernel execution on Ubuntu. To be clear, there are no vulnerabilities here as there is no documented intention to boot Linux securely (e.g., BUG/1401532), only to support a Secure Boot and boot Linux. […]

http://prosauce.org/blog/2015/10/31/booting-linux-securely

Teddy Reed research on Minnow firmware

Secure Boot strength varies by Linux implementation

USB Armory security

~ hucktech ~ Leave a comment

Two stories, 1 post:

1) USB Armory, an Open Source Hardware-based ARM device by Inverse Path, has secured it’s boot sequence, and uses the term “Secure Boot”, not to be confused by UEFI Secure Boot, and have finished documenting it:

Excerpt, just of the disclaimer, since it is a serious one:

IMPORTANT DISCLAIMER: enabling secure boot functionality on the USB armory SoC, unlike similar features on modern PCs, is an irreversible action that permanently fuses verification keys hashes on the device. This means that any errors in the process or loss of the signing PKI will result in a bricked device incapable of executing unsigned code. This is a security feature, not a bug. The activation and use of the secure boot functionality is therefore at your own risk and must be approached with care.

https://github.com/inversepath/usbarmory/wiki/Secure-boot

2) A second USB Armory story:

https://twitter.com/Yann2192/status/658590304392650752

WordPress.com processes URLs I include in text, including embedding the entire docment of git.github-based URLs, I have to split this URL in have, you’ll have to recombine it, sorry (alternately, click on the URL inside the Twitter ‘box’ above):
https://gist.github.com/
yann2192/f989143c86567237460e

MJG on Secure Boot, Intel TXT, Linux, and security

~ hucktech ~ Leave a comment

A short security lesson from Matthew (click on Twitter link for follow-up post):

[BTW, sorry WordPress doesn’t seem to render Twitter’s HTML table when scrolling through the site If you ever see multiple blank lines in the post it is probably a Twitter URL that WordPress didn’t render, refresh to fix. You have to refresh on new pages, often, or view the post on a separate page (which generates a refresh). I post messages while online and finding news, but don’t spend a huge amount of extra time formatting the posting, simple ASCII text plus a few URLs. The interactive WordPress HTML UI to add a hyperlink triples the time to post each message, and WordPress won’t accept HTML <A> links. WordPress renders some URLs differently, like showing the image of a JPEG/PNG/etc, and showing the Youtube video link and hiding the rest of a web page which contains a Youtube URL — like Kickstart funding pages.]

Windows Trusted Boot bypass

~ hucktech ~ Leave a comment

Microsoft: Trusted Boot Security Feature Bypass Vulnerability
CVE-2015-2552
Product: Windows NT series 8.0+
Affected versions: See “systems affected”.
Reported by: “Myria”

An attacker with administrative access to a Windows machine with UEFI Secure Boot enabled may bypass code signing policy checks by putting intentionally-malformed configuration options in the boot configuration database (BCD).

https://technet.microsoft.com/en-us/library/security/ms15-111.aspx

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-2552

http://seclists.org/bugtraq/2015/Oct/70

https://support.microsoft.com/en-us/kb/3096447

 

FreeScale, High Availability Boot, and U-Boot secure boot

~ hucktech ~ Leave a comment

Freescale Semiconductor, Inc. has a few Application Notes on their implementations of a U-Boot-based Secure Boot. One of these app notes is only a few days old. Excerpt:

Secure Boot on i.MX50, i.MX53, and i.MX 6 Series using HABv4

Executing trusted and authentic code on an applications processor starts with securely booting the device. The i.MX family of applications processors provides this capability with the High Availability Boot (HAB) component of the on-chip ROM. The ROM is responsible for loading the initial program image from the boot medium. HAB enables the ROM to authenticate the program image by using digital signatures. This initial program image is usually a bootloader. HAB provides a mechanism to establish a root of trust for the remaining software components and establishes a secure state on the i.MX IC’s secure state machine in hardware. The purpose of this application note is to provide a secure boot reference for i.MX applications processors that include HABv4. It demonstrates an example for generating a signed U-Boot image and configuring the IC to run securely. It is assumed that the reader is familiar with the basics of digital signatures and public key certificates.

This document covers secure boot using i.MX6. HABv4 is present on the following i.MX processors: i.MX50, i.MX53, and i.MX 6 Series. This document applies to all HABv4 processors. Secure boot features for other processors, such as i.MX25, i.MX35, and i.MX51, which use HABv3, are documented in Secure Boot on i.MX25, i.MX35, and i.MX51 using HAB3 application note (document AN4547). Secure boot features for i.MX28 are documented in Secure Boot with i.MX28 HAB v4 application note (document AN4555). i.MX28 supports HABv4, but its boot architecture is significantly different from other processors in the i.MX family.

More information:

Click to access AN4581.pdf

Click to access AN4547.pdf

Click to access AN4555.pdf

Clarification of Matthew Garrett’s Linux fork

~ hucktech ~ Leave a comment

Some irresponsible bloggers have been commenting about Matthew’s fork of Linux:

Matthew Garrett’s new Linux fork

MJG on Linux securelevel

ZDNet has a story with comments from Matthew explaining things:

“I wouldn’t say I’m forking. I’d say that I’m doing my own development work away from LKML. Right now it’s got the securelevel work in it because that’s the only code I have that I feel is ready for public use, but it’ll pick up other bits of code that I’m working on as they become mature.”

http://www.zdnet.com/article/matthew-garrett-is-not-forking-linux/

I guess I look at Matthew’s fork is like the GRSecurity patch for Linux kernel: Matthew’s got the patchset that enables UEFI Secure Boot to be secure on Linux. I hope Tails, Qubes, and other security-minded distros use Matthew’s kernel, at least in builds for UEFI-based systems.

[One of the causes of the above issue is Linus having to deal with Microsoft as a CA. UEFI Forum could also deal with this by putting in place a CA that is not an OSV/OEM. OEMs could be making Linux-friendly sytsems, not just Windows- or Chrome boxes, where Linux is an afterthought second install, which is a lot harder to do with UEFI/Windows Secure Boot — and even Chrome Verified Boot. Linux Foundation could also be helping, by working with OEMs.]

Firmware Summit results

~ hucktech ~ Leave a comment

Al Stone of Red Hat posted a summary of the recent Firmware Summit that took place at the recent Linaro Connect event.

There’s a discussion on the state of ACPI on ARMv8, and Linux support. “So, please tell Linaro if there is something needed from the ACPI spec.  Call, write or send carrier pigeons, just let us know.”

There is a discussion on ACPI’s _DSD and Device Properties. A new dsd@acpica.org mailing list has been setup to help. A new repo of information —  on how to submit, approve, and use device properties in a community approved manner:

https://github.com/ahs3/dsd/tree/v-next/documentation

https://lists.acpica.org/mailman/listinfo/dsd

Matthew Garret wrote a document on Secure Boot:
https://lists.linaro.org/pipermail/fw-summit/2015-September/000170.html

I omitted a few items from the workshop’s notes. Read the full status here:
https://lists.linaro.org/pipermail/fw-summit/2015-October/000173.html

libSboot: Secure Boot for U-Boot

~ hucktech ~ Leave a comment

Teddy Reed wrote libSboot 3 years ago, and I am just noticing it. 😦 This “Secure Boot” is different than the UEFI definition/implementation, and is U-Boot-specific. Excerpting the readme:


libSboot provides an example ‘Secured Boot’ for U-Boot and a U-Boot Second Phase Loader (SPL). libSboot attempts to define an example of how a platform can measure a pre-OS boot environment, thus providing a capability to ensure that a libSboot-enforced OS is only loaded in an owner-authorized  fashion. A ‘Secure Boot’ concept is a common means to ensure platform security and integrity; understand that there are many implementations of a ‘Secure Boot’.  libSboot uses a TPM v1.2 to implement a secure boot using a static root of trust measurement (SRTM). The static adjective implies a ‘read-only’  attribute, meaning libSboot expects its initialization to occur from ROM code.  During this initialization libSboot performs a TPM_Start, TPM_SelfTest and  checks that the TPM is neither deactivated nor disabled. The TPM must have its NVRAM locked, meaning access control is enforced. Initialization then checks  each PCR used to measure the pre-boot environment and verifies they are reset. Finally Physical Presence is asserted to satisfy NVRAM read/write permissions.

https://github.com/theopolis/sboot
https://github.com/theopolis/u-boot-sboot
http://www.trustedcomputinggroup.org/community/2013/03/securing_embedded_devices_with_the_tpm__a_schmoocon_talk
http://prosauce.org/blog/2013/2/11/embedded-trust-p2-u-boot-secured-boot.html

Linux kernel signing history

~ hucktech ~ Leave a comment

Rebecca Shapiro has posted an article, “A History of Linux Kernel Module Signing“, introductory paragraph excerpted below:

This article was originally written back in 2014 to accompany the talk I gave at Shmoocon called “The History of Linux Kernel Module Signing”. It is a discussion of various Linux kernel module signing implementations while highlighting some of the motivating factors behind various design decisions. I decided it was about time to publish this write up, so here it is. I have not found kernel module signing implementations outside of those created by Red Hat and by the mainstream Linux developers so there may be other flavors of Linux module signing that I do not mention here. The information I present here is based on Linux developer mailing lists and source code I have found. I do not have an insider perspective of the implementation decisions. If you want the ground truth, you should go talk to those developers who are a part of the narrative I present here.

Full article:

http://www.cs.dartmouth.edu/~bx/blog/2015/10/02/a-history-of-linux-kernel-module-signing.html

Looking just at UEFI Secure Boot issues with Linux driver signing, Linux distros do vary in their strength, I wish someone would gather data about this behavior for the mainstream distros.

Secure Boot strength varies by Linux implementation

Teddy Reed research on Minnow firmware

~ hucktech ~ Leave a comment

As found by ‘retweeted’ by the CHIPSEC team:

Teddy Reed has an EXCELLENT blog post — the first in a series! — going into detail about the firmware of Intel’s MinnowBoard.

Again, this is an EXCELLENT article, worth reading!

http://prosauce.org/blog/2015/9/13/minnowboard-max-quickstart-uefi-secure-boot

KVM Forum 2015 materials available

~ hucktech ~ Leave a comment

[[ UPDATE: WordPress mangles the below URL to Pauolo’s SMM talk. Download the PDF from the linux-kvm.org link below instead. ]]

The KVM Forum recently finished, and their post-conference materials are available, including videos of some of the presentations. There are multiple interesting talks on QEMU and KVM for security researchers. Two talks that jump out to me are:

Securing secure boot: system management mode in KVM and Tiano Core
by Paolo Bonzini

Click to access 03×06-Aspen-Paolo_Bonzini-Securing_secure_boot.pdf

Using IPMI in QEMU
by Corey Minyard

Click to access 03×08-Juniper-Corey_Minyard-UsingIPMIinQEMU.ods.pdf

More Information:
http://www.linux-kvm.org/page/KVM_Forum_2015

Linux Foundation IT Security Policies: firmware guidance

~ hucktech ~ Leave a comment

A  few days ago, the Linux Foundation released new guidance for securing Linux systems. Since the Linux Foundation has mostly remote workers, there are currently 2 documents: one on hardening Linux Workstations, and one for secure group communications, the latter something like a CryptoParty Handbook. Here’s an excerpt of the Hardware/Firmware/Pre-OS section from the Workstation document:

Choosing the right hardware

We do not mandate that our admins use a specific vendor or a specific model, so this section addresses core considerations when choosing a work system.

Checklist

    System supports SecureBoot (CRITICAL)
    System has no firewire, thunderbolt or ExpressCard ports (MODERATE)
    System has a TPM chip (LOW)

Considerations

SecureBoot

Despite its controversial nature, SecureBoot offers prevention against many attacks targeting workstations (Rootkits, “Evil Maid,” etc), without introducing too much extra hassle. It will not stop a truly dedicated attacker, plus there is a pretty high degree of certainty that state security agencies have ways to defeat it (probably by design), but having SecureBoot is better than having nothing at all. Alternatively, you may set up Anti Evil Maid which offers a more wholesome protection against the type of attacks that SecureBoot is supposed to prevent, but it will require more effort to set up and maintain.

Firewire, thunderbolt, and ExpressCard ports

Firewire is a standard that, by design, allows any connecting device full direct memory access to your system (see Wikipedia). Thunderbolt and ExpressCard are guilty of the same, though some later implementations of Thunderbolt attempt to limit the scope of memory access. It is best if the system you are getting has none of these ports, but it is not critical, as they usually can be turned off via UEFI or disabled in the kernel itself.

TPM Chip

Trusted Platform Module (TPM) is a crypto chip bundled with the motherboard separately from the core processor, which can be used for additional platform security (such as to store full-disk encryption keys), but is not normally used for day-to-day workstation operation. At best, this is a nice-to-have, unless you have a specific need to use TPM for your workstation security.

Pre-boot environment

This is a set of recommendations for your workstation before you even start with OS installation.

Checklist

    UEFI boot mode is used (not legacy BIOS) (CRITICAL)
    Password is required to enter UEFI configuration (CRITICAL)
    SecureBoot is enabled (CRITICAL)
    UEFI-level password is required to boot the system (LOW)

Considerations

UEFI and SecureBoot

UEFI, with all its warts, offers a lot of goodies that legacy BIOS doesn’t, such as SecureBoot. Most modern systems come with UEFI mode on by default.

Make sure a strong password is required to enter UEFI configuration mode. Pay attention, as many manufacturers quietly limit the length of the password you are allowed to use, so you may need to choose high-entropy short passwords vs. long passphrases (see below for more on passphrases).

Depending on the Linux distribution you decide to use, you may or may not have to jump through additional hoops in order to import your distribution’s SecureBoot key that would allow you to boot the distro. Many distributions have partnered with Microsoft to sign their released kernels with a key that is already recognized by most system manufacturers, therefore saving you the trouble of having to deal with key importing.

As an extra measure, before someone is allowed to even get to the boot partition and try some badness there, let’s make them enter a password. This password should be different from your UEFI management password, in order to prevent shoulder-surfing. If you shut down and start a lot, you may choose to not bother with this, as you will already have to enter a LUKS passphrase and this will save you a few extra keystrokes.

Full information:

https://github.com/lfit/itpol

https://github.com/lfit/itpol/blob/master/linux-workstation-security.md

http://linuxfoundation.org/

PS: The Linux Foundation also just started a Core Infrastructure Initiative, which has security implications, which I’ve got to find out more on, and will blog on later.

Firmware patents….

~ hucktech ~ Leave a comment

SPOILER ALERT: This post discusses patents. If you’re an employee at a company, ask your manager if you’re able to read this sort of information…..
.
.
.

I wonder how bad it’s going to get with firmware patents… Searching the patent databases, I find THOUSANDS with ‘firmware’, HUNDREDS with ‘UEFI’, and dozens with ‘coreboot’, and many for ACPI. For example, it appears that Microsoft has patented the ability to securely update firmware:

Microsoft: Secure Firmware Updates
US 20140068585 A1, CN 104603792 A, US 8898654 B2

This is just one example, all of the big OEMs, IHVs, and ISA vendors have patents left and right in this space. 😦

Are vendors able to build UEFI — or even coreboot — systems without lawyers from some of the big companies knocking on their door asking for royalties? Where is the firmware equivalent of the “Open Invention Network”, to help smaller vendors even use basic firmware functionality with lawyers looking to monetize everything? I wonder if the Maker movement or Open Hardware or Free Hardware is going to be able to survive this.

UEFI upstreaming OpenSSL patch

~ hucktech ~ Leave a comment

UEFI has an optional build directive to enable “Secure Boot”. Secure Boot’s crypto is backed by the Open Source library libOpenSSL. For a long time, Tianocore’s OpenSSL was based on 0.98x release of OpenSSL. It sucks for UEFI that every time OpenSSL issues a new release (which is often, these months), the UEFI patch sometimes has to get updates to reflect OpenSSL changes. Plus, it was scary to see UEFI using such an ancient 0.98x release of OpenSSL for so long. Recently, UEFI updated to 1.0x releases of OpenSSL, and have been doing a lot of patch churning, due to frequent OpenSSl releases. So, it’s nice to see that there’s a effort by David Woodhouse of Intel’s Open Source Technology Centre, to make an effort to upstream the UEFI patches to OpenSSL, for the first time filing an issue in the RT. (Previously, AFAICT, the only effort to upstream was brief email on the OpenSSL mailing list, no RT filed.) I don’ t think UEFI Forum is one of the members of the OpenSSL Foundation; it might be nice if they were, given their Secure Boot dependence on this library. (OEMs/IBVs can swap out OpenSSL with another crypto lib, unclear which do…)

I  hope the OpenSSL Foundation and it’s developers accept this patch, or work with UEFI Forum’s developers to come up with acceptable patch to upstream.  I may be biased, but UEFI Secure Boot might be one of OpenSSL’s most important uses. Having UEFI target code in main OpenSSL trunk will save UEFI developers time, but also help with OpenSSL developers to understand the UEFI codepath differences, and may help reduce UEFI-centric code issues later. Imagine if Windows or Linux target support for OpenSSL was a separate patch, yuck.

Even if OpenSSL Foundation doesn’t accept the patch, it is still a significant new OpenSSL patch for UEFI, worth a review.

http://rt.openssl.org/Search/Simple.html?q=UEFI

Below is David’s posting to the edk2-devel list at 01.org:

——– Forwarded Message ——–
Subject: [edk2] [PATCH v3 0/16] CryptoPkg: OpenSSL update
From: David Woodhouse

Not sure which version this is; let’s call it v3 despite the fact that I think it’s actually the first time all this lot has been posted together in a single coherent series.

All the OpenSSL fixes are filed in upstream RT and in my git tree at http://git.infradead.org/users/dwmw2/openssl.git/ and backported to OpenSSL 1.0.2 in the OpenSSL_1_0_2-stable branch of the same repo.

This series cleans up a number of our outstanding OpenSSL patches to match what’s been submitted upstream, including the use of OPENSSL_SYS_UEFI instead of abusing OPENSSL_SYSNAME_UWIN.

It also cleans up places in our code where we access OpenSSL “internal” structures which are going to be made opaque in OpenSSL 1.1 and accessor functions should be used instead.

The build infrastructure is fixed to be more consistent with the way that OpenSSL is usually built all the OPENSSL_NO_xxx definitions are moved into opensslconf.h, and the file list is properly synchronised with the result of ‘make files’ in the suitably-configured OpenSSL source.

A script is provided which allows the opensslconf.h file and the list of files in OpensslLib.inf to be automatically updated. This script is not required during a normal build; it’s only for when we update the OpenSSL which is used by the EDK II repository.

Finally, we remove CryptoPkg/include/openssl and instead use the real OpenSSL include directory. This Just Works on POSIX-compliant platforms, and has symlinks to the original files. In OpenSSL 1.1 it’ll work even on Windows, as those files have been *moved* to the include/openssl/ directory of the OpenSSL source tree. For the time being, Install.sh can die and Install.cmd is updated to copy the files to $(OPENSSL_PATH)/include/openssl to work around Windows’ lack of symlinks.

Both the final commit (using OpenSSL HEAD) and the penultimate (still using a patched 1.0.2d) have been build-tested for IA32 and X86 both using GCC on Linux and VS2008 under Windows. And also using MinGW32/MingGW64 under Linux, although the final link there fails due to calls to __chkstk_ms (see GCC PR#67169).

Git tree at http://git.infradead.org/users/dwmw2/edk2.git

David Woodhouse (16):
CryptoPkg/BaseCryptLib: Add missing OpenSSL includes
CryptoPkg/BaseCryptLib: Use i2d_X509_NAME() instead of abusing X509_NAME
CryptoPkg/BaseCryptLib: Use accessor functions for X509_ATTRIBUTE
CryptoPkg/BaseCryptLib: Use accessor functions for ASN1_OBJECT
CryptoPkg/BaseCryptLib: Clean up checking of PKCS#7 contents type
CryptoPkg/BaseCryptLib: Use X509_V_FLAG_PARTIAL_CHAIN
CryptoPkg/BaseCryptLib: Use X509_V_FLAG_NO_CHECK_TIME
CryptoPkg/OpensslLib: Undefine NO_BUILTIN_VA_FUNCS to fix varargs breakage
CryptoPkg: Fix OpenSSL BN wordsize and OPENSSL_SYS_UEFI handling
CryptoPkg/OpensslLib: Eliminate GETPID_IS_MEANINGLESS definition
CryptoPkg/OpensslLib: Move OPENSSL_NO_xxx defines into opensslconf.h
CryptoPkg: Use OpenSSL include directory directly
CryptoPkg/OpensslLib: Include complete copy of opensslconf.h
CryptoPkg/OpensslLib: Update OpenSSL patch
CryptoPkg/OpensslLib: Automatically configure OpenSSL and generate file list
CryptoPkg: Support building with OpenSSL HEAD (1.1.0-devel)

CryptoPkg/CryptoPkg.dec                                               |   2 +
CryptoPkg/Include/OpenSslSupport.h                                    |  26 ++
CryptoPkg/Include/openssl/README                                      |   1 –
CryptoPkg/Library/BaseCryptLib/InternalCryptLib.h                     |  10 +-
CryptoPkg/Library/BaseCryptLib/Pk/CryptAuthenticode.c                 |   7 +-
CryptoPkg/Library/BaseCryptLib/Pk/CryptDh.c                           |   1 +
CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Verify.c                  |  94 +—
CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaBasic.c                     |   1 +
CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaExt.c                       |   1 +
CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c                           | 102 +—
CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c                         |  18 +-
CryptoPkg/Library/BaseCryptLibRuntimeCryptProtocol/InternalCryptLib.h |   8 –
CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2d.patch               | 380 —————
CryptoPkg/Library/OpensslLib/Install.cmd                              |  77 —
CryptoPkg/Library/OpensslLib/Install.sh                               |  79 —-
CryptoPkg/Library/OpensslLib/OpenSSL-HOWTO.txt                        |  44 ++
CryptoPkg/Library/OpensslLib/OpensslLib.inf                           | 480 ++—————–
CryptoPkg/Library/OpensslLib/Patch-HOWTO.txt                          |  61 —
CryptoPkg/Library/OpensslLib/opensslconf.h                            | 488 ++++++++++++++++++++
CryptoPkg/Library/OpensslLib/process_files.sh                         |  38 ++
20 files changed, 691 insertions(+), 1227 deletions(-)