Tim Lewis of Insyde resumes blogging on firmware

Tim Lewis has been blogging on UEFI for a long time. But took a break, now is resuming:

[…]After some gentle ribbing from colleagues at the UEFI plug-fest in Bellevue, WA, I’ve decided to try to keep track of recent trends in UEFI here again.

His current blog post covers a few topics, including replying to Vincent Zimmer’s recent claims of definitive ways to pronounce UEFI and ACPI:

[…]And for the record, it is U-E-F-I (not YOO-FI or micro-EFI) and A-C-P-I (not AK-PIE). On a side note about competing acronym pronunciations, in the early days of the EISA (Extended ISA) bus architecture, it was pointed out that while English speakers naturally pronounced EISA as EEE-SA and ISA as AY-SA, other European languages had would naturally pronounce it exactly opposite (EISA as AY-SA and ISA as EE-SA).[…]

https://uefi.blogspot.com/2018/04/uefi-notes-cs2ai-uefi-plugfest-and.html

New ACPI IDs for November: Nexstgo and Insyde

Here’s the list of new ACPI specs for 2017 (so far), 2 new entries in November, first update since Summer:

Company ACPI ID Approved on Date
VR Technology Holdings Limited 3GVR 01/19/2017
Exar Corporation EXAR 02/28/2017
Coreboot Project BOOT 02/28/2017
Marvell Technology Group Ltd. MRVL 05/25/2017
IHSE GmbH IHSE 06/22/2017
Insyde Software INSY 11/10/2017
Nexstgo Company Limited NXGO 11/13/2017

http://www.uefi.org/acpi_id_list

http://www.uefi.org/uefi-acpi-export (XLS download)

For the 2 new entries, I can’t find any data on what their ACPI tables do, nor where their specs are:

http://www.nexstgo.com/
http://www.catalog.update.microsoft.com/ScopedViewInline.aspx?updateid=1724ebc5-cbbf-407f-a4da-c3b769f88690

https://www.insyde.com/

It is a shame that the spreadsheet doesn’t have a column with more useful info, eg: URL to the vendor’s spec, perhaps which HW/OS it is valid for, which version of ACPI it requires, flag if table has FWTS test, license of vendor’s spec (eg, click-through EULA required for some ARM/MSFT/TCG docs), etc.

Insyde Software security updates for Windows 10

Hurray, UEFI vendors focusing on security! 🙂

Insyde® Software Highlights Strategies to Strengthen Firmware Security at the Fall UEFI Plugfest

Company’s Chief Technology Officer to Present at The UEFI Forum Plugfest in Taipei, Taiwan

[…]In related UEFI-security news, Insyde Software announced its full compliance with the latest firmware security updates needed by Microsoft’s upcoming Windows® release. The Windows 10 Fall Creators Update adds new requirements that include improved support for TPMs (Trusted Platform Modules) and new functionality for Secure Boot BIOS update, all of which is fully supported by InsydeH2O® UEFI BIOS.[…]

https://www.insyde.com/press_news/press-releases/insyde%C2%AE-software-highlights-strategies-strengthen-firmware-security-fall

Fall UEFI Plugfest agenda

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.

Insider_BIOS_Tools: BIOS tools from Insyde Software

Cool, Insyde  Software is releasing some of their tools. It appears they’re older tools, see the readme about restrictions and newer versions of the tools.

Insider_BIOS_Tools

BIOS tools for Insyde Insiders! (release approved by the management of Insyde Software Japan)

We believe that the commercial value of our outdated BIOS developer tools is quite low. As a gesture of good will towards the BIOS modding community and IT community in general, we have decided to release some of our outdated BIOS developer tools – which are a part of this GitHub repository.[…]

Includes:
* H20EZE: Easy BIOS Editor that helps edit binaries in the BIOS, including Option ROMs, driver binaries, logos, and Setup values.
* H20FFT: Firmware Flash Tool assists in quickly and easily updates flash devices with new BIOS firmware.
* H20SDE: SMBIOS Data Editor that facilitates easy modification of any SMBIOS (DMI) field by GUI and Command Line, with support for a wide variety of OS environments.
* H20UVE: UEFI Variable Editor

https://github.com/s-sosnitskiy80/Insider_BIOS_Tools

 

 

UEFI Plugfest slides uploaded

https://uefi.blogspot.com/2017/03/uefi-plugfest-2017-in-nanjing.html

Tim Lewis of Insyde has a blog post with an update for the UEFI plugfest. *Multiple* presentations on security!!

 State of UEFI – Mark Doran (Intel)
 Keynote: China Information Technology Ecosystem – Guangnan Ni (Chinese Academy of Engineering).
 The Role of UEFI Technologies Play in ARM Platform Architecture – Dong Wei (ARM)
 ARM Server’s Firmware Security – Zhixiong (Jonathan) Zhang, Cavium
 SMM Protection in EDK II – Jiewen Yao (Intel)
 Server RAS and UEFI CPER – Mao Lucia and Spike Yuan (Intel)
 A More Secure and Better User Experience for OS-based Firmware Update – David Liu (Phoenix)
 UEFI and IoT: Best Practices in Developing IoT Firmware Solutions – Hawk Chen (Byosoft)
 Establishing and Protecting a Chain of Trust with UEFI – David Chen (Insyde)
 Implementation of Hypervisor in UEFI Firmware – Kangkang Shen (Huawei)
 Lessons Learned from Implementing a Wi-Fi and BT Stack – Tony Lo (AMI)
  UEFI Development Anti-Patterns – Chris Stewart (HP)

http://www.uefi.org/learning_center/presentationsandvideos

List of UEFI vendors who care about security

Which UEFI vendors care — or at least may care — about security? The list (alphabetically) is shorter than you might expect:

AMD
AMI
Apple
Dell
Hewlett Packard Enterprises
HP Inc.
Insyde Software
Intel Corp.
Lenovo
Microsoft
Phoenix Technologies

Nobody else. If your vendor is not listed above, ask them why you should purchase a UEFI-based system from them.

The above list is from the list of vendors who have feedback mechanisms listed on the UEFI Forum’s security contact page.

http://uefi.org/security

Who created the ACPI ASPT spec?

Re: https://firmwaresecurity.com/2015/12/08/fwts-adds-test-for-undocumented-aspt-acpi/

Earlier, the FWTS team thought this ACPI ASPT (ACPI System Performance Tuning) spec was from AMD.  AMD looked into it, and thinks it is probably from Intel, as does Insyde Software. Intel/anyone: Do you know who wrote the spec? If so, please leave a comment or send email. Thanks.

AMD comment:
Well, as far as I can tell, nobody at AMD knows about the ASPT table. First I asked the relevant specialists, then I asked everybody associated with BIOS. Nobody recognizes it as an AMD thing.
Then we found an IBV .txt file that listed a bunch of Intel-sounding platforms associated with ASPT. So, could you double check whether this is really being seen on AMD platforms, please?
Even if you do find it on some AMD platforms, I’m now pretty sure it’s not an AMD thing. It might be a proprietary ACPI table added by an OEM or and IBV. I believe proprietary tables are allowed by the ACPI spec.

and a later comment:
It’s actually a definition from another silicon vendor for their overclocking information. Since the table only shows up on systems that support overclocking, it only shows up on systems with fast graphics controllers. That’s might be why “AMD”Âť is referenced.

Another comment from a firmware vendor (IFV):
I believe you would be better served by contacting any of your contacts at Intel Client.  I’m not saying they will document this table, but it’s clear to me by looking at our code, this is Intel’s table. Maybe the AMD false pointer is probably because most overclocking systems have non-integrated graphics?

LinuxCon Europe UEFI Mini-Summit presentations available

Earlier this month, the UEFI Forum recently had a “Mini-Summit” at LinuxCon Europe. The presentations are now available online (so far just the slides, unclear if A/V will show up on Youtube later):

UEFI Mini-Summit at LinuxCon Europe: October 7, 2015

* UEFI Forum Update and Open Source Community Benefits – Mark Doran (Intel)
* What Linux Developers Need to Know About Recent UEFI Spec Advances – Jeff Bobzin (Insyde Software)
* LUV Shack: An Automated Linux Kernel and UEFI Firmware Testing Infrastructure – Matt Fleming (Intel)
* Goodbye PXE, Hello HTTP Boot – Dong Wei (HP)
* UEFI Development in an Open Source Ecosystem – Michael Krau (Intel)

More information (about halfway down the page, past the Youtube section):

http://www.uefi.org/learning_center/presentationsandvideos

 

Insyde updates InsydeH2O and Supervyse

This week at Intel Developer Forum (IDF), Insyde Software announced support of Intel’s new “Innovation Engine”. Insyde has a Supervyse Systems Management product, as well as their InsydeH2O UEFI BIOS. Insyde announced that both of these products will fully-leverage Intel’s Innovation Engine, a newly-announced new processor and IO subsystem targeting data center platforms. Excerpting their press release:

“The Innovation Engine gives us tremendous opportunity to extend our BIOS and BMC product offerings,” said Stephen Gentile, Sr. Vice President, Strategy at Insyde Software. “More importantly, this powerful and open resource gives us a new framework for products targeted at next-generation data center servers,” added Gentile.

“The Innovation Engine is a new way that developers can tap Intel technology to improve the capabilities of data center solutions,” said Lisa Spelman, General Manager of Data Center Marketing at Intel. “Through working with our ecosystem partners like Insyde, our data center customers will have comprehensive hardware and software solutions that will drive new innovations and platform differentiation,” added Spelman.

More information:

http://www.insydesw.com/press_news/press-releases/insyde%C2%AE-software-helps-drive-innovation-future-intel%C2%AE-data-center-platform

AMD AGESA

I’m learning about AMD firmware solutions, and AGESA is first acronym on the list. According to Wikipedia:

“AMD Generic Encapsulated Software Architecture (AGESA), is a bootstrap protocol by which system devices on AMD64-architecture mainboards are initialized. The AGESA software in the BIOS of such mainboards is responsible for the initialization of the processor cores, memory, and the HyperTransport controller. AGESA documentation was previously available only to AMD partners that had signed an NDA. AGESA source code was open sourced in early 2011 to gain track in coreboot.”

There are two firmware ecosystems, coreboot and UEFI, where the former has a lot of Chrome OEMs, and the latter has a lot of Windows OEMs. UEFI and coreboot work on Intel and AMD (and ARM) systems. AMD makes both x86 and ARM systems, but I’m focusing on their x86 systems here.

For coreboot, Sage Engineering is main coreboot IBVs (Independent BIOS Vendors), AFAICT. Sage currently supports AMD systems, offering coreboot with AGESA.

https://www.se-eng.com/products/sagebios-bsp-for-amd-processors/

Sage supports many modern x86 platforms from AMD. In early BSP releases,our source code license allowed us to directly modify and include AGESA source code. Later versions include the AGESA binary PI from AMD to initialize the CPU. SageBIOS(TM) Custom BSPs deliver full-featured firmware designed for AMD platforms.

https://www.se-eng.com/firmware-solutions-for-intel-and-amd-x86-processor-systems/

AMD was the first […] to support an open source boot solution with its support of the One Laptop Per Child program, which was immersed in the Linux open source community, and the Linux firmware boot solutions that would ultimately become coreboot. Sage Electronic Engineering founder Scott Hoot was heavily involved in that the children’s laptop project, as a firmware designer for AMD, and would soon embrace open source firmware solution as a foundation for his startup company. Sage would have distinct advantages over other open source firmware development companies in that Hoot already had a insight into AMD’s proprietary architecture, which he would cement with a agreements with AMD to help forge the way into expanded open source BIOS and firmware coding. Sage would continue to forge a trail in the community with its support of the coreboot(R) solution and the proprietary hybrid that Sage developed for more rapid deployment, SageBIOS. Open source development as a whole continue to progress with AMD’s AGESA  and Intel’s Firmware Support Package, essentially giving open source firmware designers a better look at the architecture than was previously allowed.

Over in the UEFI Forum ecosystem, it appears that most of the ‘mainstream’ IBVs also support ARM via AGESA in their products as well. I see support from Insyde Software and AMI, at least.

http://www.insyde.com/press_news/press-releases/insyde-software-provides-framework-support-amd-processors

http://www.ami.com/news/press-releases/?PressReleaseID=135&/American%20Megatrends%20Extends%20Aptio%C2%AE%20Firmware%20Support%20for%20AMD%20AGESA%E2%84%A2/

I’m still not clear if TianoCore can use AGESA directly, or if an IBV is still needed to integrate the two.

More Information:

http://review.coreboot.org/gitweb?p=coreboot.git;a=tree;f=src/vendorcode/amd
https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/a46a712610c130cdadfe1ebf6bec9ad22e474dac/src/cpu/amd/agesa
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/AGESA_Interface_specification_for_Arch2008.pdf

[I just realized that I’ve not written a blog on Intel Firmware Support Package (FSP) yet…. I’ll do one in a few days.]

Spring Plugfest presentations uploaded

The PDFs of the presentations from last months’ UEFI Forum plugfest have been uploaded to uefi.org.

http://www.uefi.org/learning_center/presentationsandvideos
(scroll about half-way through the page, after the Youtube videos…)

* System Prep Applications – Powerful New Feature in UEFI 2.5 – Kevin Davis (Insyde Software)
* Filling UEFI/FW Gaps in the Cloud – Mallik Bulusu (Microsoft) and Vincent Zimmer (Intel)
* PreBoot Provisioning Solutions with UEFI – Zachary Bobroff (AMI)
* An Overview of ACPICA Userspace Tools – David Box (Intel)
* UEFI Firmware – Securing SMM – Dick Wilkins (Phoenix Technologies)
* Overview of Windows 10 Requirements for TPM, HVCI and SecureBoot – Gabe Stocco, Scott Anderson and Suhas Manangi (Microsoft)
* Porting a PCI Driver to ARM AArch64 Platforms – Olivier Martin (ARM)
* Firmware in the Data Center: Goodbye PXE and IPMI. Welcome HTTP Boot and Redfish! – Samer El-Haj-Mahmoud (Hewlett Packard)
* A Common Platforms Tree – Leif Lindholm (Linaro)

This’ll be a very short blog, as I’m busy reading 9 new PDFs… 🙂 I’ll do blogs on some these specific presentations in the coming days.