Tag: UEFI

Tianocore for OpenPOWER

~ hucktech ~ 8 Comments

Andrei Warkentin has ported UEFI to OpenPOWER! Excerpt from readme:

TianoCore UEFI for OPAL/PowerNV (PPC64/PowerPC64 Little-Endian)

This is “UEFI” on top of OPAL firmware. “UEFI” because the specification doesn’t include PowerPC yet (ever?). At some point this experiment will implement reduced-hardware “ACPI” support, mapping the OPAL-based FDT into “ACPI” structures. “ACPI” because it’s also not specced out for PowerPC. It’s getting prototyped on top of QEMU and Skiboot (OPAL firmware).

Why? It’s thought experiment gone too far. In short, there’s IMO value in presenting a common firmware environment shared with other servers (X64, AARCH64). UEFI+ACPI keep the OEMs and IHVs in their comfort zone, and reduce pointless platform boot and configuration variance across different architectures. It also allows plug-in cards to work (assuming EBC ROMs). Petitboot is a nice idea in theory, but in practice it’s probably more suitable to embedded environments rather than whitebox servers that can compete with Intel boxes. UEFI gets us a bootloader environment and device drivers for I/O and booting via storage and networking. OPAL is the abstraction layer for the machine.
[…]

https://github.com/andreiw/ppc64le-edk2
http://osdevnotes.blogspot.com/

Running OPAL in qemu – the powernv platform


http://github.com/andreiw/ppc64le_hello

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.]

Intel on UDK2015

~ hucktech ~ Leave a comment

UDK2015 was released the other day. There is a new blog post from Briand Richardson of Intel on usage of the UDK, and the main download page on the wiki has been updated to support it:

https://twitter.com/Intel_UEFI/status/652253984225394688

https://twitter.com/Intel_UEFI/status/652212808961138688

http://blogs.intel.com/evangelists/2015/10/08/using-udk2015-for-uefi-2-5-development/

http://www.tianocore.org/udk/udk2015/

http://sourceforge.net/projects/edk2/files/UDK2015_Releases/UDK2015/UDK2015-ReleaseNotes-MyWorkSpace.txt/download

iPXE adds UEFI HTTP Boot support

~ hucktech ~ 1 Comment

Samer El-Haj-Mahmoud of HP posted a message to the EFI development list, with an update on iPXE, supporting UEFI HTTP Boot:

It looks like iPXE has been updated to work with UEFI 2.5 HTTP Boot, and tested with OVMF. Their page also includes instructions for configuring the DHCP server to enable HTTP Boot, and building OVMF with HTTP_BOOT enabled. It would be interesting to see if iPXE EFI version will directly use EFI_HTTP_PROTOCOL or carry its own TCP/IP HTTP code.

Excerpt from iPXE site:

Version 2.5 of the UEFI specification introduces the UEFI HTTP Boot feature. You can use the basic UEFI HTTP Boot client to chainload iPXE from an HTTP server, eliminating the need for a separate TFTP server in your boot infrastructure. The simple UEFI HTTP Boot client will download and boot iPXE. You can then use any of iPXE’s more advanced features such as HTTPS, Digest authentication, POST requests, scripts, menus, customisable code signing etc. to download and boot your operating system. UEFI HTTP chainloading provides a way to load iPXE on systems which do not have iPXE present as part of the UEFI firmware. If your system already provides iPXE as part of the UEFI firmware, then you do not need to use UEFI HTTP chainloading.

More information:
http://ipxe.org/appnote/uefihttp
http://article.gmane.org/gmane.comp.bios.edk2.devel/2756

EFI Mixed Mode patchset for Android-IA

~ hucktech ~ Leave a comment

Christopher Price posted availability of a patchset to restore EFI Mixed Mode to the latest Android-IA release. Excerpt of announcement:

Enclosed you will find 19 patches that restore EFI Mixed Mode to the latest Android-IA release. We are still running through a BFD linker bug in KernelFlinger that is preventing activation – but it has tested well with GMIN64 and does not appear to block the kernel. Testing and review appreciated. We’d like it committed upstream because it would be very difficult without trunk access to maintain these patches going forward. While we’d like to take credit, Mark Gross and Intel UK really did an excellent job reviving this work – we’ve been incubating and testing for the past few months. This will allow Android-IA to run on the millions of BayTrail-T production tablets that depend on EFI Mixed Mode. Without these patches, Android-IA cannot run on virtually any Bay Trail tablet today, except for maybe IRDA, which isn’t available in many countries currently. These patches should no longer be necessary once Kernel 3.15 is integrated, at which point Mixed Mode will hit mainline… or at least, should hit mainline.

http://console.com.co/wp-content/uploads/mixed-mode.zip

https://lists.01.org/pipermail/android-ia/2015-October/001003.html
http://www.phoronix.com/scan.php?page=news_item&px=MTY0OTI
https://lwn.net/Articles/589193/

 

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

UEFI HTTP Boot whitepaper available

~ hucktech ~ Leave a comment

A few weeks ago the Tianocore project added a whitepaper on UEFI 2.5’s HTTP Boot:

http://www.tianocore.org/news/2015/09/17/HTTP-BOOT.html
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-white-papers
http://sourceforge.net/projects/edk2/files/General%20Documentation/
http://www.tianocore.org/news/feed.xml

If you were looking for instructions on how to setup Tianocore’s HTTP boot feature, on Windows-based systems, this document is for you!

I could be wrong, but I don’t think the TLS API has been added to Tianocore yet, so there is no HTTPS, only HTTP.

(Looking at the above SourceForge URL, it appears the Packaging Tool document was also recently updated, but not sure of the details.)

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

new efi_capsule_loader Linux kernel interface from Intel

~ hucktech ~ Leave a comment

Hock Leong Kweh of Intel posted a patch to the Linux kernel which exposes a new UEFI capsule update interface. Some excerpts from the patch:

efi: a misc char interface for user to update efi firmware

Introducing a kernel module to expose capsule loader interface (misc char device file note) for user to upload capsule binaries. This option exposes a loader interface “/dev/efi_capsule_loader” for user to load EFI capsule binary and update the EFI firmware through system reboot. It expose a misc char interface for user to upload the capsule binary and calling efi_capsule_update() API to pass the binary to EFI firmware. The steps to update efi firmware are:

1) cat firmware.cap > /dev/efi_capsule_loader
2) reboot

Any failed upload error message will be returned while doing “cat” through Write() function call. Tested the code with Intel Quark Galileo platform. This patchset is created on top of Matt’s patchset:
1.)https://lkml.org/lkml/2014/10/7/390 “[PATCH 1/2] efi: Move efi_status_to_err() to efi.h”
2.)https://lkml.org/lkml/2014/10/7/391 “[PATCH 2/2] efi: Capsule update support”

See the linux-kernel/linux-efi/linux-fsdevel list archives for the patch (gmane.org is down for me currently, hope it returns…):
http://dir.gmane.org/gmane.linux.kernel.efi
http://vger.kernel.org/majordomo-info.html

UEFItool 0.21.2 released

~ hucktech ~ Leave a comment

UT 0.21.2 (18 additions and 8 deletions)
– fixed a bug with tailed files extraction and replacing (#35)
– fixed a bug with wrong source of padding after all Intel image regions (#34)

https://github.com/LongSoft/UEFITool

https://github.com/LongSoft/UEFITool/commit/388dd2509358997e81f36f5fea6e406ce202cf1b

UDK 2015 available

~ hucktech ~ Leave a comment

UDK2015 has been released.

Intel(R) UEFI Development Kit (UDK) 2015

UDK2015.Complete.MyWorkSpace.zip
https://svn.code.sf.net/p/edk2/code/branches/UDK2015: r18552
https://svn.code.sf.net/p/edk2-fatdriver2/code/trunk/FatPkg: r96

NEW FEATURES AND CHANGES :
1.  Support UEFI specification 2.5, except for EXCEPTION_LIST are not implemented.
2.  Support Platform Initialization(PI) specification 1.4.
3.  Add ACPI 6.0 definitions.
4.  Add SMBIOS 3.0 definitions.
5.  Support OpenSSL version 1.0.2d.

EXCEPTION_LIST*:
1)  1220 UEFI.Next feature – Bluetooth
2)  1212 UEFI.Next feature – HTTP API (HTTP 1.1 IPv6)
3)  1214 UEFI.Next feature – Boot from HTTP (IPv6)
4)  1217 UEFI.Next feature – WIFI support
5)  1218 UEFI.Next feature – EAP2 Protocol
6)  1219 UEFI.Next Feature – UEFI TLS API
7)  1221 UEFI.Next feature – REST Protocol
8)  1222 UEFI.Next feature – BMC/Service Processor Device Path
9)  1263 UEFI.Next feature – Customized Deployment of Secure Boot
10) 1268 RAM Disk UEFI Device Path Node
11) 1251 EFI_REGULAR_EXPRESSION_PROTOCOL
12) 1227 UEFI.Next feature – Platform recovery
13) 1347 Boot Manager Policy Errata
14) 1352 Errata for 1263 and 1227
15) 1353 SATA Device Path Node Errata

http://sourceforge.net/projects/edk2/files/UDK2015_Releases/UDK2015/
http://www.tianocore.org/news/2015/09/29/UDK2015_Preview.html

There’s a lot of UEFI 2.5 NOT in this UDK release, I guess we have to wait for future UDK releases for full UEFI 2.5 support.

UDK2015 expected mid-October

~ hucktech ~ Leave a comment

The UDK github wiki has been updated to give information about upcoming UDK 2015 release next month. It appears to include most UEFI 2.5 features, plus a few new ones. Excerpt of changes:

 

Support UEFI 2.5 Updates:
 + Smart Card Reader & Smart card edge protocol (H file only)
 + Inline Cryptographic Interface Protocol (H file only)
 + UEFI USB Function I/O Protocol (H file only)
 + Add NVM Express Pass Thru Protocol
 + Add UFS stack
 + Add SD Device Path (H file only)
 + Add reconnect Browser Action
 + Ability to refresh the entire form
 + The default/options for the Ordered List question
 + Keyword Strings support
 + New CPER Memory Section (H file only)
 + New EFI_HASH2_PROTOCOL
 + Adding support for No executable data areas
 + Persistent Memory Type support
 + Add the Support for new PKCS7 Verification Services
 + System Prep Applications
 + Add SMBIOS3_TABLE_GUID in configuration table.
 + Exposing Memory Redundancy to OSPM
 + ESRT: EFI System Resource Table and component firmware updates
 + IPV6 support from UNDI
 + UEFI “Next” Feature –
    * IP_CONFIG2 Protocol
    * Boot from HTTP (Excluding IPV6)
    * DNSv4 and DNSv6

Support PI 1.4 Updates:
 + PI SMM GPI
 + New MP Service PPI
 + Multiple CPU health info
 + PEI SetBootMode Service() clarification
 + GetMemoryMap Update for ReservedMemory
 + New Graphics PPI
 + New Capsule PPI
 + SIO PEI and UEFI-Driver Model Architecture
 + Extended File Size Errata
 + Add Reset2 PPI

Excluded from UEFI 2.5 Updates:
 + Match2 Opcode and EFI_REGULAR_EXPRESSION_PROTOCOL
 + Bluetooth Support (H file only)
 + Errata Boot Manager Policy & SATA Device Path Node
 + RamDisk Device Path
 + UEFI “Next” Feature –
    * Boot from HTTP (Excluding IPV6)
    * WIFI support (H file only)
    * EAP2 Protocol (H file only)
    * UEFI TLS API
    * REST Protocol
    * Platform recovery
    * Customized Deployment of Secure Boot
    * BMC/Service Processor Device Path

Other features:
 + Add ACPI 6.0 definitions.
 + Add SMBIOS 3.0 definitions.
 + Support OpenSSL version 1.0.2d.

Looking forward to the upcoming checkins to Tianocore’s EDK2 trunk!

Full roadmap article:
https://github.com/tianocore/tianocore.github.io/wiki/RoadMap2015

Nikolaj on UEFI security, part 5

~ hucktech ~ Leave a comment

Nikolaj’s part 5 of his series on UEFI security. Google Translation of first paragraph:

On safety UEFI, Part Five

After a short break, we continue to talk about the safety of UEFI. This time we will focus on technology SecureBoot, its pros and cons, about the attacks on her and protect them. For the first time we are talking about SecureBoot standard UEFI 2.2 in 2011, but finally all the aspects have been implemented in version 2.3.1C in early 2012. The main developer of the technology has been Microsoft, which once said that to obtain a certificate of Windows 8 Ready for his not yet released the new operating system requires the implementation and integration SecureBoot by default on all new PCs. This announcement sparked a wave of sharp criticism from the supporters of the free software, which is successfully sunk, and until Habra. If you’re wondering what exactly ended confrontation MS and the community as SecureBoot looks after almost 4 years of growing up, and the attacks on him are still possible – welcome under the cut.

http://habrahabr.ru/post/267953/

 

http://translate.google.com/translate?hl=en&sl=ru&tl=en&u=http%3A%2F%2Fhabrahabr.ru%2Fpost%2F267953%2F&sandbox=1

 

Intel EFI Disk Utilities

~ hucktech ~ Leave a comment

Intel has a set of disk utilities, for creating/checking GPT partitions and FAT file systems. They aren’t included in TianoCore’s EDK2 with the other BSD-licensed UEFI Shell commands. These tools ship separately, with a separate license, presumably due to the tool’s knowledge of FAT file system format. Here’s a brief description of the tools, as excerpted from the download license:

Microsoft EFI Utilities: The term “Microsoft EFI Utilities” shall mean the Guided Partition Table utilities Diskpart (Disk partitioning utility), Efifmt (EFI Format utility) and Efichk (EFI Check Disk utility) stored in a file named GPT_UTIL.zip.

To get the tools, you have to agree to the license on this page, if so you get to download a zip. Then you have to read the readme in that zip, to get the password for the other included zip, which contain the actual tools. Lawyer-designed.

http://www.intel.com/technology/efi/agree_diskutil.htm

The tools come with source, not just binary. They didn’t compile for me, this morning: I think they require a much older EDK2 environment to build. But at least they ship with source, though it is not BSD-licensed Open Source. The tools are old enough that they still use “EFI”, not the newer “UEFI” term.

I wish Intel could donate these tools to the UEFI Forum, so that Intel- *AND* ARM-based users could benefit. TianoCore already has a FAT license, for it’s file system driver. Adding these tools to that package would eliminate one FAT-centric license, and bundle FAT-centric tools along with the FAT-centric file system driver. It would be nice for TianoCore to be able to fix/create ESPs, not just run from ESPs created elsewhere. Perhaps use the Disk Util common code for some other UEFI-based file system diagnostic tools for file systems that UEFI ships, eg UFS, maybe UDF.

Nikolaj Schlej series on UEFI security!

~ hucktech ~ Leave a comment

Nikolaj Schlej, of UEFITool fame, has a series of articles on UEFI security; so far there are 4 parts to this series. It is written in Russian. If you can’t use translation tools effectively — like me — this series is a good time to start to learn. Here’s the excerpted output of Google Translate of the first paragraph of part 1:

In this article, we will focus on models of threats and attack vectors on UEFI, as well as protection against overwriting the contents of the chip BIOS – the most devastating of the possible consequences of an attack. If you are curious about how to protect UEFI and which vulnerabilities in it and remain uncorrected in most modern systems – welcome under the cut.

http://habrahabr.ru/users/CodeRush/topics/

part 1:
http://habrahabr.ru/post/266935/

part 2:
http://habrahabr.ru/post/267197/

part 3:
http://habrahabr.ru/post/267237/

part 4:
http://habrahabr.ru/post/267491/