AMI spins-off AmZetta

About AmZetta: Founded in 2019, the AmZetta team has an average of 22 years of experience in leading technologies such as BIOS, Drivers, Firmware, Linux, Networking, RAID, Remote Management, Storage and Virtualization. AmZetta is a spinoff from American Megatrends (better known as AMI) and is focused on Storage, VDI, IoT and Healthcare technologies for the data center. Headquartered in Norcross, Georgia, AmZetta has locations in the U.S. and India to better serve its customers. For more information on AmZetta, its products or services, visit AmZetta.com.

Hmm, the supplied HTTPS link to the new company did not work for me, but it worked without TLS:

Home

Home

 

 

AMI BIOS Guard Extractor: Parses AMI BIOS Guard (a.k.a. PFAT) images and extracts a proper SPI/BIOS image

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.

https://github.com/platomav/BIOSUtilities#ami-bios-guard-extractor

AMI releases Unrestricted (Free) Version of AMIDuOS

Re: https://firmwaresecurity.com/2018/06/01/ami-retires-duos/

AMI has rmade DuOS — which runs both Android and Windows simultaneously — available again:

https://ami.com/en/amiduos/?amiduos=activation

PS: AMI: Please add Linux support to your feature list.

AMI on their MegaRAC SP-X Service Processor BMC product

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.

https://ami.com/en/tech-blog/megarac-spx-the-foundation-for-powerful-server-management–part-i/

https://ami.com/en/products/remote-management/service-processor/

MegaRAC SPX Logo

 

AMI Adds TPM Support on Arm-based Systems Running Aptio® V UEFI Firmware

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

https://ami.com/en/news/press-releases/american-megatrends-adds-tpm-support-on-armbased-systems-running-aptio-v-uefi-firmware/

 

AMI statement for Meltdown/Spectre for MegaRAC BMC

https://ami.com/en/tech-blog/ami-statement-in-response-to-meltdown-and-spectre-security-vulnerabilities-for-megarac-bmc-firmware-on-aspeed-armbased-platforms/

https://www.nikktech.com/main/news/8940-american-megatrends-statement-in-response-to-meltdown-and-spectre-security-vulnerabilities-for-megarac-bmc-firmware-on-aspeed-arm-based-platforms

MORF – AMI’s open source Redfish Framework in OpenBMC

https://github.com/ami-megarac/

https://lists.ozlabs.org/pipermail/openbmc/2018-March/011255.html

Click to access MegaRAC%20Open%20Redfish%20Framework%20(MORF).pdf

 

RU 5.20.0328 beta released

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.

Password: 174105371023

http://ruexe.blogspot.com/2017/12/ru-5200328-beta.html

https://github.com/JamesAmiTw/ru-uefi/

AMI on Intel’s BIOS end-of-life announcement

 

https://ami.com/en/tech-blog/intel-says-bye-to-bios-by-2020/

Click to access Brian_Richardson_Intel_Final.pdf

 

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

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.

AMI blog post with ‘firmware BSOD-like’ photos

AMI has a new blog post with a nice collection of firmware splash screens seen in the wild.

 

https://ami.com/en/tech-blog/aptio-and-amibios-in-interesting-places/

See-also: https://twitter.com/samkottler/status/757571758606147584

AMI announces full Redfish 1.0 support

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

https://ami.com/en/products/remote-management/rack-scale-design-solutions/.

https://ami.com/en/news/press-releases/american-megatrends-announces-full-support-for-redfish-10-specification-in-aptio-v-uefi-bios-and-megarac-bmc-remote-management-firmware/

http://redfish.dmtf.org/

CVE-2017-3753: AMI Lenovo UEFI SMM vulnerability

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
Severity: High
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)

https://nvd.nist.gov/vuln/detail/CVE-2017-3753
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-3753
https://support.lenovo.com/us/en/product_security/len-14695
AFAICT nothing on the AMI site on this.