Parses AMI BIOS Guard (a.k.a. PFAT) images and extracts a proper SPI/BIOS image. You can either Drag & Drop or manually enter the full path of a folder containing AMI PFAT images.
[…]AFU still supports older SMM methodologies for older systems, but such methodologies cannot be used when the platform is equipped with modern BIOSes.[…]
AMI has rmade DuOS — which runs both Android and Windows simultaneously — available again:
PS: AMI: Please add Linux support to your feature list.
In a new blog post, AMI gives an introduction to their MegaRAC SPX-Service Processor, useful background if you’ve no idea about what it is.
[…]In our next post on MegaRAC SP-X, we will look more closely at some of the other specific features and benefits of MegaRAC SP-X mentioned earlier, including hardware and software inventory, power, BIOS and user management, along with more of the different interface protocols that SP-X supports.
I’m not sure, but I think AMI just updated AMIBIOS8 (I see a slew of new PDFs, but no press release or Tweet, so unclear):
AMI killed off this OS earlier in March:
I wonder how things would have turned out if AMI let DuOS try to live on as open source project, instead of just killing off the closed-source product?
AMI has announced support for TPM on Arm®-based systems running AMI’s flagship Aptio® V UEFI Firmware. […] Previously, AMI only provided TPM support for x86 platforms. With the growing need to extend TPM support for additional platforms, AMI has added TPM support for Arm-based systems currently running AMI’s Aptio® V UEFI firmware. The added TPM support for Arm-based systems includes features specifically for the Arm architecture such as TPM driver support within Arm® TrustZone® technology and Linux OS support. The Arm TrustZone TPM Firmware can be accessed by the BIOS and OS via the Command Response Buffer interface using Secure Monitor calls. Other generic features supported by TPM include cryptographic algorithms and measurement of SecureBoot variables.[…]
RU is closed-source freeware for MS-DOS and UEFI. Some UI changes and bugfixes. Changes include:
* Add PCI Express Capabilities Register.bit8 Slot implemented information to info block
* Fix device name was not cleared while changing PCI device
* F6 PCI list changes (PCI Express) to PCIe
* RU /D ACPI: Display the saving file information more clearly
* ALT-6 ACPI table list now list OEM ID, OEM Table ID and Creator ID.
* Fix wrong ACPI table checksum bad information if the length > 0xffff
Important notes: Every version of RU has it own bugs simply because I did not test it fully. Please leave comments here if you find any bug. RU.EXE are not tested at all.
The UEFI Forum likes to frame UEFI -vs- BIOS, and has a 3-5 Class heirarchy of those systems, including having to deal with UEFI systems that also provide BIOS via Compatibility Support Module (CSM), referring to BIOS as Legacy Mode. If you look at BIOS outside of the framing of the UEFI Forum, it is usually based security, and UEFI has some security where BIOS has none. But there’s another ‘class’: non-UEFI coreboot, optionally secured with Verified Boot, with a BIOS payload. UEFI Forum doesn’t include this in their Class heirarchy… AFAICT, the mainstream IBVs have given up on BIOS and migrated to UEFI. The only places where BIOS will probably remain are in Purism boxes, where they will use TPM+Heads to secure BIOS, or on Chrome boxes, where they will use coreboot Verified Boot to secure BIOS, or in SeaBIOS-based VMs. When Intel stops offering Intel’s implementation of BIOS, maybe this means that the remaining BIOS users will switch to the open source SeaBIOS project, which is great news. Getting rid of the complex class of dual UEFI/BIOS systems will be a joy. 🙂
As WiFi/NFC/Bluetooth become part of a modern firmware stack, AMI has a blog post on bluetooth security issues:
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.
“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)
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.
AMI has a new blog post with a nice collection of firmware splash screens seen in the wild.
American Megatrends Announces Full Support for Redfish™ 1.0 Specification in Aptio® V UEFI BIOS and MegaRAC® BMC Remote Management Firmware
Monday: October 2, 2017
AMI has announced its full support for the Redfish™ 1.0 specification from the Distributed Management Task Force (DMTF), in both its Aptio® V UEFI BIOS Firmware as well as several products within the MegaRAC® Manageability Framework – the most widely used solution in the market today. […] In addition to its industry-leading Aptio® V UEFI BIOS Firmware, known and trusted by Tier One OEMs and ODMs around the globe, products from AMI featuring support for Redfish 1.0 include the fully-integrated MegaRAC Pooled System Management Engine (PSME) firmware solutions, which enable efficient resource management for Network, Storage and Compute hardware throughout the data center, as well as MegaRAC Composer™ Pod Management Software.[…]
Lenovo says scope of AMI issue is “Industry-Wide”, which implies that other Intel/AMI-based OEMs may also have this issue, not just Lenovo.
BIOS SMI Handler Input Validation Failures
CVE Identifier: CVE-2017-3753
Lenovo Security Advisory: LEN-14695
Scope of Impact: Industry-Wide
Last Modified: 08/09/2017
Potential Impact: Execution of code in SMM by an attacker with local administrative access
A vulnerability has been identified in some Lenovo products that use UEFI code developed by AMI. With this vulnerability, conditions exist where an attacker with administrative privileges or physical access to a system may be able to run specially crafted code that can allow them to bypass system protections such as Device Guard and Hyper-V. AMI has supplied a fix for this vulnerability to Lenovo. Users should update the BIOS on affected systems to the latest available version to address this issue.
Security-conscious users should consider the following mitigation steps if an immediate BIOS update is not possible to protect themselves to the fullest extent with the understanding that they DO NOT fix or fully protect against an exploit of this vulnerability:
* Enable Secure Boot on your system
* Disable the boot to UEFI shell
* Disable boot from any source but the primary internal hard drive
* Set a BIOS setup password, so Secure Boot cannot be disabled and the boot to the UEFI shell cannot be re-enabled
* Operate as an unprivileged (non-administrator)
AFAICT nothing on the AMI site on this.
American Megatrends Provides Service for Developing NVMe UEFI Option ROMs for UEFI BIOS Firmware
AMI is pleased to announce new service for developing NVMe® UEFI Option ROMs. Recently, AMI added support for technologies such as NVMe metadata/data encryption and NVMe namespace management. Continuing its support for NVMe-related technologies, AMI has also developed UEFI NVMe Option ROMs. This service for developing UEFI NVMe Option ROMs enables OEMs and NVMe device manufacturers to ship NVMe devices with Option ROMs embedded in them. OEMs and NVMe device manufacturers will have the ability to add features that are traditionally unavailable with generic UEFI drivers and can implement vendor-specific commands and features within their devices. Some of the additional features that are available for NVMe Option ROMs include disk management for namespace management in BIOS setup, metadata/end-to-end data protection, NVMe firmware updates in BIOS setup and SMART data information. Interested OEMs and NVMe drive manufacturers should contact their AMI sales representative for more information.