Guidance on using ACPI _DSD with Linux

Al Stone of Red Hat submitted a 4-part patch to the Linux-ACPI list. Excerpt from comments from the first patch:

How to Use the ACPI _DSD Device Properties UUIDs

In the three documents that follow, we lay out a process for defining the use cases of device properties returned by the ACPI _DSD (Device Specific Data) object in Data Structures associated with the Device Properties UUID [0] and the Hierarchical Properties Extension UUID. The term “_DSD device properties” below refers to the data formats associated with those two UUIDs only.  All other UUIDs used with _DSD are outside the scope of what is described here. The goal of these documents is to: (1) make clear to OS vendors which of the use cases of _DSD device properties need to be supported; (2) be clear on what those use cases should mean to the OS; and, (3) have all OSs use the same definitions for those use cases. The first document describes basic context and essential terminology for the process of submitting a use case for the _DSD device properties to a central location so that it can be reviewed and tracked. The next document describes a database for storing the use cases of _DSD device properties that have been reviewed and agreed upon.  The idea is to make this database publicly available so that OS developers and firmware creators can easily see what is already defined, what is in use, and what is not defined. The final document provides a formal language for describing the use cases of _DSD device properties.  The goal is to make it relatively easy to define new use cases of the _DSD device properties, by stating clearly what those definitions must look like.  This also makes building automated tools easier, allowing us to keep the process simpler, permit validation of the content, assist with documentation, and perform basic record keeping. […]

See full post and the github project:

https://github.com/ahs3/dsd/tree/master/documentation
https://marc.info/?l=linux-acpi&m=146955102920815&w=2
https://marc.info/?l=linux-acpi&m=146955096920780&w=2
https://marc.info/?l=linux-acpi&m=146955089620763&w=2
https://marc.info/?l=linux-acpi&m=146955077420741&w=2
https://marc.info/?l=linux-acpi&m=146955067620727&w=2

Also, there’s a Python-based _DSD command line tool in the same DSD github project!

https://github.com/ahs3/dsd

ACPI/APEI BERT support for Linux

Tony Luck of Intel submitted a patch to the Linux (Kernel,ACPI) lists, to add ACPI BERT (Boot Error Record Table) support to the Linux kernel. The original patch appears to be from Huang Ying of Intel, I think.

New Linux kernel parameter:
bert_disable: Disable BERT OS support on buggy BIOSes.

Excerpting comments from the patch:

ACPI/APEI is designed to verifiy/report H/W errors, like Corrected Error(CE) and Uncorrected Error(UC). It contains four tables: HEST, ERST, EINJ and BERT. The first three tables have been merged for a long time, but because of lacking BIOS support for BERT, the support for BERT is pending until now. Recently on ARM 64 platform it is has been supported. So here we come. Under normal circumstances, when a hardware error occurs, kernel will be notified via NMI, MCE or some other method, then kernel will process the error condition, report it, and recover it if possible. But sometime, the situation is so bad, so that firmware may choose to reset directly without notifying Linux kernel. Linux kernel can use the Boot Error Record Table (BERT) to get the un-notified hardware errors that occurred in a previous boot. In this patch, the error information is reported via printk. For more information about BERT, please refer to ACPI Specification version 6.0, section 18.3.1:
http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf

The following log is a BERT record after system reboot because of hitting a fatal memory error:
BERT: Error records from previous boot:
[Hardware Error]: It has been corrected by h/w and requires no further action
[Hardware Error]: event severity: corrected
[Hardware Error]:  Error 0, type: recoverable
[Hardware Error]:   section_type: memory error
[Hardware Error]:   error_status: 0x0000000000000400
[Hardware Error]:   physical_address: 0xffffffffffffffff
[Hardware Error]:   card: 1 module: 2 bank: 3 row: 1 column: 2 bit_position: 5
[Hardware Error]:   error_type: 2, single-bit ECC

For more information, see the patch message thread on the Linux-kernel list:
http://vger.kernel.org/majordomo-info.html

FWTS 16.06.00 released, new ACPI features

Ivan Hu of Canonical.com announced the 16.06.00 release of Firmware Test Suite (FWTS).

New Features in this release include ACPI-related functionality:
  * acpi: method: acpi 6.0 adds USB-C Connection to _UPC
  * acpi: method: add _WPP method test (introduced in ACPI 6.1)
  * acpi: method: add _WPC method test (introduced in ACPI 6.1)
  * ACPICA: Update to version 20160527
  * acpi: hest: Add GHESv2 checking (LP: #1587624)
  * lib: acpi: Add support for HEST GHESv2

http://fwts.ubuntu.com/release/fwts-V16.06.00.tar.gz
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/16.06.00
https://launchpad.net/ubuntu/+source/fwts

There were some bugfixes, in ACPI, IPMI, UEFI, and some other technology areas, see the release notes — or the post on the FWTS list — for the list of bugfixes.

Intel ACPI IGD OpRegion Spec, and IntelSiliconPkg added to Tianocore

Jiewen Yao of Intel added a new module to the public Tianocore source project.

[PATCH 1/2] IntelSiliconPkg: Add initial version.
This package will include open source common Intel silicon related modules.
This series patch adds the initial version of IntelSiliconPkg and an include file.
We will use IntelSiliconPkg for open source common Intel silicon related modules.

I hope Intel transitions some of it’s binary-only releases from it’s Intel Firmware Support Package (FSP) into this source-only-based package!

It appears the first candidate for this new IntelSiliconPkg is the Intel IGD (Integrated Graphics Device).

[PATCH 2/2] IntelSiliconPkg/IgdOpRegion: Add definition for Intel IGD OpRegion.
IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h
Add IGD OpRegion definition from Intel Integrated Graphics Device OpRegion Specification.

OpRegion structures: Sub-structures define the different parts of the OpRegion followed by the main structure representing the entire OpRegion. Sub-structures:
INTEL_IGD_OPREGION_MBOX1  MBox1; // Mailbox 1: Public ACPI Methods
INTEL_IGD_OPREGION_MBOX2  MBox2; // Mailbox 2: Software SCI Inteface
INTEL_IGD_OPREGION_MBOX3  MBox3; // Mailbox 3: BIOS/Driver Communication
INTEL_IGD_OPREGION_VBT    VBT;   // Video BIOS Table (OEM customizable data)

Click to access acpi_igd_opregion_spec_0.pdf

Hmm, I don’t see IGD mentioned in the list of ACPI specs:
http://uefi.org/acpi

I am pretty sure that one of Intel’s Beyond BIOS whitepapers mentions IGD/ACPI/UEFI interactions, sorry I forget which one it is, it may have been the one on BIOS memory maps:
https://firmware.intel.com/share

It appears Intel first released this spec in 2008. Besides UEFI, Intel IGD OpRegion support is in coreboot as well. And in the Linux kernel.
https://lwn.net/Articles/301879/
https://lwn.net/Articles/292839/
https://lwn.net/Articles/429319/

For more information, see the patch on the EDK2-devel list:
https://lists.01.org/mailman/listinfo/edk2-devel

SeaBIOS ACPI patch fixing Ubuntu/Windows installs

Bin Meng posted an 18-part patch to the SeaBIOS list, fixing multiple issues that may impact the installation of Ubuntu (only Ubuntu and no other Linux distros??) and Windows:

[PATCH v2 00/18] x86: acpi: Support installation of Ubuntu/Windows and boot Windows

SeaBIOS can be loaded by U-Boot to aid the installation of Ubuntu and Windows to a SATA drive and boot from there. But till now this is broken. The installation either hangs forever or just crashes. This series fixed a bunch of issues that affect the installation of Ubuntu and Windows, and booting Windows.

Testing was performed on MinnowMax by:
– Install Ubuntu 14.04 and boot
– Install Windows 8.1 and boot
– Install Windows 10 and boot

This series is available at u-boot-x86/acpi2-working.

Changes in v2:
– New patch to remove the unnecessary checksum calculation of DSDT
– New patch to remove header length check when writing tables
– New patch to enable SeaBIOS on all boards
– New patch to add GPIO ASL description

Bin Meng (18):
  x86: minnowmax: Adjust U-Boot environment address in SPI flash
  x86: Call board_final_cleanup() in last_stage_init()
  x86: Fix up PIRQ routing table checksum earlier
  x86: Compile coreboot_table.c only for SeaBIOS
  x86: Prepare configuration tables in dedicated high memory region
  x86: Unify reserve_arch() for all x86 boards
  x86: Reserve configuration tables in high memory
  x86: Use high_table_malloc() for tables passing to SeaBIOS
  x86: acpi: Switch to ACPI mode by ourselves instead of requested by OSPM
  x86: acpi: Remove the unnecessary checksum calculation of DSDT
  x86: acpi: Remove header length check when writing tables
  x86: doc: Update information about IGD with SeaBIOS
  x86: baytrail: Enable SeaBIOS on all boards
  x86: doc: Mention Ubuntu/Windows installation and boot support
  acpi: Quieten IASL output when ‘make -s’ is used
  x86: baytrail: Add internal UART ASL description
  x86: baytrail: Add GPIO ASL description
  x86: doc: Add porting hints for ACPI with Windows

For more information, see the U-Boot list:
http://lists.denx.de/mailman/listinfo/u-boot

FWTS 16.05.01 released

Alex Hung of Canonical has announced the 16.05.01 release of FWTS, the FirmWare Test Suite.

There are new ACPI and IPMI and TCG OVAL and Linux device-tree tests. In addition to new features, there’s an even larger list of bugfixes for most classes (UEFI, BIOS, ACPI, etc.) of tools, not excerpted below, see the full announcement for those.

New Features:
  * acpi: add MSCT table sanity check
  * acpi: add EINJ table sanity check
  * ACPICA: Update to version 20160318 (LP: #1559312)
  * Introduce olog scan, to check OPAL msglog.
  * Introduce IPMI BMC Info
  * devicetree: add infrastructure for device-tree tests
  * devicetree/dt_sysinfo: Add device tree system information tests
  * devicetree/dt_base: Add base device-tree validity checks
  * debian/control: change depends on libjson0-dev to libjson-c-dev
  * auto-packager: mkpackage.sh: add yakkety and remove vivid
  * debian/control: add back libjson0-dev for precise

http://fwts.ubuntu.com/release/fwts-V16.05.01.tar.gz
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/16.05.01
https://launchpad.net/ubuntu/+source/fwts

AMD’s IVRS ACPI table

I just noticed this March-era update to the UEFI list of ACPI specs. It is a large, well-written spec, compared to some of the recent ACPI specs I’ve looked at.

I/O Virtualization Reporting Structure (IVRS)

This document describes AMD I/O Virtualization Technology. AMD I/O Virtualization Technology is embodied in the system-level function called the I/O Memory Management Unit (IOMMU). This document provides the IOMMU behavioral definition and associated design notes. It is intended for the use of system designers, chipset designers, and programmers involved in the development of low-level BIOS (basic input/output system) functions, drivers, operating system kernel modules, and virtual machine monitor (VMM) software. The intended user should have prior experience in personal computer design, microprocessor programming, and legacy x86 and AMD64 microprocessor architecture.

Click to access 48882_IOMMU.pdf

http://uefi.org/acpi

new Microsoft ACPI table: WSMT

As mentioned earlier this week, Microsoft just released a spec for their new ACPI table WSMT (Windows SMM Security Mitigations Table):

Windows SMM Security Mitigations Table

The Windows SMM Security Mitigations Table specification contains details of an ACPI table that was created for use with Windows operating systems that support Windows virtualization-based security (VBS) features. This information applies for Windows Server Technical Preview 2016, and Windows 10, version 1607. […]

Full spec:
http://download.microsoft.com/download/1/8/A/18A21244-EB67-4538-BAA2-1A54E0E490B6/WSMT.docx

The UEFI Forum maintains ACPI specs. AFAICT, their ACPI spec list does not yet list this new WSMT table.
http://www.uefi.org/acpi

Also, there’s a strange copyright in this spec:

Portions of this software may be based on NCSA Mosaic. NCSA Mosaic was developed by the National Center for Supercomputing Applications at the University of Illinois at Urbana-Champaign. Distributed under a licensing agreement with Spyglass, Inc.

Maybe I am just noticing this paragraph, and Microsoft always uses that on copyright pages, and does not mention other old software, only NCSA Mosaic. But why NCSA Mosaic-centric copyrights in an WSMT ACPI table?? Microsoft IE 1.0 was based on NCSA Mosaic source code, via Spyglass purchase, but that was long before EFI or ACPI. I didn’t notice anything Win9x/BIOS/ISA-PNP-centric about WSMT. :-).

In related news, Jiewen Yao of Intel has submitted the WSMT definition into the tianocore EDK-II project:

MdePkg: Add WSMT definition. This patch adds Windows SMM Security Mitigation Table @ http://download.microsoft.com/download/1/8/A/18A21244-EB67-4538-BAA2-1A54E0E490B6/WSMT.docx

 …/WindowsSmmSecurityMitigationTable.h            | 39 ++++++++++++++++++++++
 1 file changed, 39 insertions(+)

+#define EFI_ACPI_WINDOWS_SMM_SECURITY_MITIGATION_TABLE_SIGNATURE  SIGNATURE_32(‘W’, ‘S’, ‘M’, ‘T’)

Jiewen also submitted a 12-part patch, enhancing SMM to deal with this new table:

[PATCH 00/12] Enhance SMM Communication by using fixed comm buffer. This series patches are generate to meet Microsoft WSMT table definition on FIXED_COMM_BUFFERS requirement. Before this series patches, the DXE or OS module can use any non-SMM memory as communication buffer to exchange data with SMM agent. Microsoft WSMT table has requirement to support fixed communication buffer – so that SMM agent can only support communication buffer with type EfiReservedMemoryType/EfiRuntimeServicesCode/EfiRuntimeServicesData/EfiACPIMemoryNVS, which will not be used by OS during runtime. So we clean up all SMM handler to only use these memory regions for SMM communication, and enhance check in SmmMemLib to catch the violation. This series patches are validated on real platforms with SMM enabled. This series patches are validated on OVMF ia32-x64 with SMM enabled.

For full patch, see list archives:
https://lists.01.org/mailman/listinfo/edk2-devel

TPM2 ACPI table

Finnbarr P. Murphy has a new blog post about viewing the TPM2 ACPI table:

[…] Why two definitions for the same header? The current ACPI standard defines the table description header as follows: […]
I believe that the second definition is closer to the intent of the ACPI. For a more detailed look at the actual TPM2 support in the EDK2, read the Intel white paper entitled A Tour Beyond BIOS with the UEFI TPM2 Support in EDKII by Jiewen Yao and Vincent J. Zimmer. […]

http://blog.fpmurphy.com/2016/03/examining-tpm2-acpi-table.html

Intel patch to Linux kernel for ACPI overlays

Octavian Purdila of Intel has posted a 10-part patch to the Linux-(ACPI,EFI,I2C,SPI,Kernel) lists, adding “ACPI Overlays” to the Linux kernel:

This patch set enables custom ACPI board configuration by adding mechanisms in the Linux kernel for loading user defined SSDTs. In order to support ACPI open-ended hardware configurations we need a way to augment the ACPI configuration provided by the firmware image. A common example is connecting sensors on I2C / SPI buses on development boards. Although this can be accomplished by creating a kernel platform driver or recompiling the firmware image with updated ACPI tables, neither is practical: the former proliferates board specific kernel code while the latter requires access to firmware tools which are often not publicly available. Because ACPI supports external references in AML code a more practical way to augment firmware ACPI configuration is by dynamically loading user defined SSDT tables that contain the board specific information.

This patch sets provides three methods for loading custom SSDTs:
1) From an EFI variable: This is the preferred method, when EFI is supported on the platform, because it allows a persistent, OS independent way of storing and updating the user defined SSDTs. There is also work underway to implement EFI support for loading user defined SSDTs and using this method will make it easier to convert to the EFI loading mechanism when that will arrive.
2) From the first uncompressed initrd (similar with the override functionality): This is useful when EFI is not supported on the platform and when it is not possible to defer the loading to userspace.
3) From userspace via configfs: This is useful when we want to defer the operation to userspace for platform detection, loading the SSDTs from a custom partition, etc.

Octavian Purdila (10):
  kernel: add TAINT_OVERLAY_ACPI_TABLE
  acpi: install SSDT tables from initrd
  acpi: add support for ACPI reconfiguration notifiers
  acpi: fix enumeration (visited) flags for bus rescans
  i2c: add support for ACPI reconfigure notifications
  spi: add support for ACPI reconfigure notifications
  efi: load SSTDs from EFI variables
  configfs: fix CONFIGFS_BIN_ATTR_[RW]O definitions
  acpi: add support for configfs
  acpi: add support for loading SSDTs via configfs

 Documentation/ABI/testing/configfs-acpi |  23 +++++
 Documentation/acpi/ssdt-overlays.txt    | 174 ++++++++++++++++++++++++++++++++
 Documentation/kernel-parameters.txt     |   7 ++
 Documentation/oops-tracing.txt          |   2 +
 Documentation/sysctl/kernel.txt         |   1 +
 MAINTAINERS                             |   1 +
 drivers/acpi/Kconfig                    |   9 ++
 drivers/acpi/Makefile                   |   1 +
 drivers/acpi/bus.c                      |  72 +++++++++++++
 drivers/acpi/configfs.c                 | 143 ++++++++++++++++++++++++++
 drivers/acpi/internal.h                 |   3 +
 drivers/acpi/scan.c                     |  73 +++++++++++++-
 drivers/acpi/sysfs.c                    |   6 +-
 drivers/firmware/efi/efi.c              | 107 ++++++++++++++++++++
 drivers/i2c/i2c-core.c                  |  38 ++++++-
 drivers/spi/spi.c                       |  36 ++++++-
 include/acpi/acpi_bus.h                 |   8 ++
 include/linux/configfs.h                |   4 +-
 include/linux/kernel.h                  |   1 +
 kernel/panic.c                          |   2 +
 20 files changed, 699 insertions(+), 12 deletions(-)
 create mode 100644 Documentation/ABI/testing/configfs-acpi
 create mode 100644 Documentation/acpi/ssdt-overlays.txt
 create mode 100644 drivers/acpi/configfs.c

For more information, see the full patch on the above-listed mailing lists.

UEFI 2.6 and ACPI 6.1 specs announced

The UEFI Forum has announced the availability of the UEFI v2.6 and ACPI v6.1 specifications.

ACPI v6.1 includes:
 * Interrupt-signaled events for expanded hardware-reduced platform support and improved system-on-chip designs.
 * Standardized ARMv8-A processor support for “firmware-first” hardware error handling and reporting, including SEA and SEI notification types in the Hardware Error Source Table (HEST).

UEFI v2.6 includes:
 * Enriched ability for agents in the system to provide better user interface support prior to launching of the OS through additional Image and Font information.
 * Formal API definition for RAM Disk Protocol.
 * New Wireless MAC Connection Protocol interface simplifies wireless network support and future radio technology versions.
 * ARM error reporting extensions for the Common Platform Error Record (CPER), allowing ARMv8-A systems to implement “firmware-first” hardware error handling and reporting.

More info:

ACPI 6.1 released

UEFI 2.6 spec changes

UEFI 2.6 released


http://uefi.org/specifications
http://www.businesswire.com/news/home/20160309005302/en/UEFI-Forum%C2%A0Announces-Availability-Updated-Specifications-UEFI-v2.6

Firmware Test Suite 16.02.00 is released

Ivan Hu of Canonical has announced the release of FirmWare Test Suite (FWTS) version 16.02.00.

New Features:
  * ACPICA: Update to version 20160212 (LP: #1545099)
  * Full ACPI compliance testing for the FADT
   * FADT: enable compiling on non-x86 architectures
   * FADT: non-x86 machines need an FADT but x86 can survive without one
   * FADT: disable SCI_EN and RESET_REG tests when in reduced hardware mode
   * FADT: add in code to log basic info about the various FADT flag fields
   * Add in bit masks for FACS flags.
   * FADT: move log info out of test2, will provide it elsewhere
   * ACPI: Add hypervisor ID field to FADT.
   * FADT: minor cleanup and initial compliance tests
   * FADT: expand the compliance test for FIRMWARE_CTRL fields
   * FADT: expand compliance checks for DSDT and X_DSDT fields
   * FADT: add compliance tests for reserved fields, PM profile, reduced hardware
   * FADT: restructure test sequence around reduced hardware mode
   * FADT: expand compliance tests for the SMI_CMD field
   * FADT: add compliance tests for the ACPI_ENABLE and ACPI_DISABLE fields
   * FADT: add compliance tests for S4BIOS_REQ and PSTATE_CNT fields
   * FADT: extend and add PM address block compliance tests
   * FADT: enhance compliance tests for GPE blocks
   * FADT: add compliance test for the CST_CNT field
   * FADT: add in compliance tests for C2/C3 latency fields
   * FADT: add in SLEEP_CONTROL_REG and SLEEP_STATUS_REG compliance tests
   * FADT: remove no longer useful variables from test1
   * FADT: add safety checks for older versions of FADT
  * acpi: method: add _PMC test
  * acpi: method: add _PRT test
  * acpi: method: add _RDI test
  * acpi: method: add _LPI test
  * data: klog.json: update to sync with 4.6 kernel changes

See the changelog or full announcement for the list of fixed bug:

https://launchpad.net/ubuntu/+source/fwts
http://fwts.ubuntu.com/release/fwts-V16.02.00.tar.gz
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/16.02.00
http://wiki.osdev.org/FADT

Matthew Chapman on Lenovo laptop internals

Matthew Chapman has a nice set of blog posts that go into detail about Lenovo internals, including some firmware and ACPI details, all because of a new battery:

Unlocking my Lenovo laptop, parts 1-3

Two months ago, I bought a new battery for my Lenovo laptop (a ThinkPad X230T). I was about to go away on holidays and wanted a battery that could last me through a plane flight; the original battery was by then barely lasting ten minutes. Little did I know that I was about to […]

In part 1, we looked at the communication between a Lenovo Thinkpad X230T laptop and battery, and discovered that there a challenge-response protocol used to authenticate ‘genuine’ Lenovo batteries. On the laptop side, this – and battery communication in general – is implemented in a component known as the embedded controller (EC). […]

In part 2, we discovered that a embedded controller update is performed by uploading a small ‘flasher’ program to the EC. This flasher program is then responsible for programming a new firmware image to the EC’s internal flash memory. However, both the flasher program and part of the firmware image are encrypted: the old (currently running) EC firmware decrypts the flasher program, and the flasher program then decrypts the new firmware update. This creates a bit of a chicken-and-egg problem that prevents discovering the encryption algorithm from firmware update files alone. […]

Blog series:

Unlocking my Lenovo laptop, part 1

Unlocking my Lenovo laptop, part 2

Unlocking my Lenovo laptop, part 3

Linux ACPI to IBM and Lenovo: help!

If you know someone at IBM or Lenovo, the Linux-ACPI community needs more involvement from you, please help.

 

——– Forwarded Message ——–
Subject:     ibm-acpi developers not responding despite serious bugs and debuggers
Date:     Sat, 30 Jan 2016 13:22:27 +0000
From:     jono <lejono@gmail.com>
To:     Rafael J. Wysocki <rafael@kernel.org>
CC:     ACPI Devel Maling List <linux-acpi@vger.kernel.org>, ibm-acpi-devel@lists.sourceforge.net

Dear Rafael,
Sorry to trouble you, but a number of us are having lots of grief
getting a response from ibm/lenovo regarding acpi bugs in newer models
like the Helix 2. The bugs make these machines difficult to use, and
there are various reports of this on the internet, along with people
willing to debug patches. But it’s impossible to contact anyone on the
ibm-acpi team to help with this. Do you know who we can contact to
help sort these bugs out? Myself and others are polite, fairly tech
savy, and willing to help, so I’m a bit puzzled by the silence from
this team.

The example is the Helix 2, see:
https://bugzilla.kernel.org/show_bug.cgi?id=100171

and various repetitions of this…
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1424088
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1520965?comments=all

For more information, see the Linux-ACPI mailing list archives on kernel.org

http://vger.kernel.org/majordomo-info.html

ACPI 6.1 released

ACPI v6.1 spec has been released, apparently. I have yet to read it, so not sure what has changed yet.

http://uefi.org/acpi

The UEFI Forum has already started doing EDK-II trunk checkins for 6.1 support for UEFI.

[edk2] [patch] MdePkg: Add ACPI6.1 definition.
Add ACPI 6.1 definitions from the ACPI
Specification Revision 6.1 January, 2016.

MdePkg/Include/IndustryStandard/Acpi61.h | 2375 ++++++++++++++++++++++++++++++
1 file changed, 2375 insertions(+)
create mode 100644 MdePkg/Include/IndustryStandard/Acpi61.h

diff –git a/MdePkg/Include/IndustryStandard/Acpi61.h b/MdePkg/Include/IndustryStandard/Acpi61.h
new file mode 100644

More info:

https://lists.01.org/mailman/listinfo/edk2-devel
.

AArch64 Xen gets Dom0 ACPI support

Shannon Zhao of Huawei submitted a 17-part patch to the Linux-ARM-kernel, Linux-EFI, Linux-Kernel, and Xen-devel lists, which adds ACPI support for Xen Dom0 on AArch64 systems.

This patch set adds ACPI support for Xen Dom0 on ARM64. The relevant Xen ACPI on ARM64 design document could be found from [1]. The corresponding Xen patches can be fetched from [2].

  Xen: ACPI: Hide UART used by Xen
  xen/grant-table: Move xlated_setup_gnttab_pages to common place
  Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
  arm/xen: Use xen_xlate_map_ballooned_pages to setup grant table
  xen: memory : Add new XENMAPSPACE type XENMAPSPACE_dev_mmio
  Xen: ARM: Add support for mapping platform device mmio
  Xen: ARM: Add support for mapping AMBA device mmio
  Xen: public/hvm: sync changes of HVM_PARAM_CALLBACK_VIA ABI from Xen
  xen/hvm/params: Add a new delivery type for event-channel in HVM_PARAM_CALLBACK_IRQ
  arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI
  ARM: XEN: Move xen_early_init() before efi_init()
  ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
  ARM: Xen: Document UEFI support on Xen ARM virtual platforms
  XEN: EFI: Move x86 specific codes to architecture directory
  ARM64: XEN: Add a function to initialize Xen specific UEFI runtime services
  FDT: Add a helper to get specified name subnode
  Xen: EFI: Parse DT parameters for Xen specific UEFI

[1] http://lists.xen.org/archives/html/xen-devel/2015-11/msg00488.html
[2] http://git.linaro.org/people/shannon.zhao/xen.git  ACPI_XEN_ARM_V3
http://vger.kernel.org/majordomo-info.html

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?

ACPI 5.1a/6.0 GIC structure inconsistency

Mark Doron of Intel posted a message to the Linux-ACPI and Linux-Kernel lists, clarifying some spec deltas between ACPI 5.1a and 6.0, specificaly for the GIC structure. Most of Mark’s message is quoted verbatim below, see the Linux-ACPI list archives for the full post.

Watch this site for any 2016-dated specs, for an update: http://uefi.org/acpi

GIC version inconsistency in ACPI 5.1a versus 6.0 documents

Hi Everyone:

I have been asked to post here on behalf of the UEFI Forum’s ACPI Spec Work Group (ASWG) to provide some clarification regarding the ACPI Specification versions 5.1a and 6.0.  For those who may not know me, I am the Chair of this work group.

In particular it turns out that there are different definitions contained in the these two versions of the document for the GIC version field contained in the GIC Distributor Structure.  This structure is located in Table 5-63 in both versions of the document.  I am told this inconsistency is causing some problems for implementation work.

The inconsistency arises purely from an administrative error on our part as keepers of the ACPI Specification.  I want to apologize to anyone who has been inconvenienced by this issue.

The sharp-eyed may notice that the dates on the covers of the two versions are the same.  The Forum’s normal practice when making a new revision is to re-publish the prior version with all known errata included so that the content that is common between the existing and new documents matches.  This accounts for the two documents having the same date; in fact they were published on the exact same day at the same time.

In the case of this one particular structure definition, as shown in Table 5-63, the content was corrected to match what it should say in the 6.0 version of the document.  Unfortunately we messed up and the same fix was not properly retrofitted to the ACPI 5.1 spec to be included with the 5.1a (latest errata included version of 5.1 that was released at the same time as 6.0).

Now this inconsistency has been pointed out, the UEFI Forum will publish a revised version 5.1b that will incorporate a fix for this problem.  This will however take a little time to organize so it may be some days before that updated document appears on the Forum’s public web site.

Since it was felt that this issue is causing friction for implementation work going on right now, the Work Group asked that I post the above explanation and mitigation as well as the following recommendation to help move implementation work ahead without delay.

The recommendation from the UEFI Forum in this case then is:

– For implementation purposes, the definition in the ACPI 5.1a for the GIC version field that is part of the GIC Distributor Structure (Table 5-63) is incorrect and instead implementers should refer to the corresponding sections of the ACPI 6.0 Specification (the Table to refer to is numbered the same in both documents).  The inconsistency will be corrected shortly with the release of a revised ACPI Spec 5.1b update.

For the avoidance of doubt, this means that implementers seeking to conform to the ACPI 5.1 specification should implement to the ACPI 5.1a in every particular except for the above referenced GIC version field which should follow the definition contained in the ACPI 6.0 version of the specification.  This advice holds true until a revised ACPI 5.1b is published at which time there will be no inconsistency.

 

SeaBIOS gets TPM2 security

BIOS was designed in the era of the initial IBM PC, running IBM PC-DOS — when DOS meant Disk Operating System not Denial of Service — back when there was no security in any hardware, firmware, or software designs. 🙂 As  UEFI documentation likes to mention, BIOS has no security, unlike UEFI (well, at least v2, EFI v1 had much less security). But SeaBIOS, the open source BIOS implementation, has had TPMv1 support for BIOS (and ACPI) since 2011, and today it just got TPMv2 support! It appears that initial TPMv1 support was added to SeaBIOS in 2011 by Stefan Berger of IBM, including TPM support for ACPI; excerpt from his patch email:


The following set of patches add TPM and Trusted Computing support to SeaBIOS. In particular the patches add:

– a TPM driver for the Qemu’s TPM TIS emulation (not yet in Qemu git)
– ACPI support for the TPM device (SSDT table)
– ACPI support for measurement logging (TCPA table)
– Support for initialzation of the TPM
– Support for the TCG BIOS extensions (1ah handler [ah = 0xbb]) (used by trusted grub; http://trousers.sourceforge.net/grub.html)
– Static Root of Trusted for Measurement (SRTM) support
– Support for S3 resume (sends command to TPM upon resume)
– TPM-specific menu for controlling aspects of the TPM
– [An optional test suite for the TIS interface]

All implementations necessarily follow specifications.

When all patches are applied the following services are available
– SSDT ACPI table for TPM support
– initialization of the TPM upon VM start and S3 resume
– Static root of trust for measurements (SRTM) that measures (some) data of SeaBIOS in TCPA ACPI table
– 1ah interrupt handler offering APIs for measuring and sending commands to the TPM (trusted grub uses them)
– User menu for controlling aspects of the state of the TPM

Full message:
http://www.seabios.org/pipermail/seabios/2011-April/001609.html
https://lists.gnu.org/archive/html/qemu-devel/2011-08/msg03835.html

Steven has an article on the QEMU wiki on SeaBIOS TPMv1 support. And Stephan has a SeaBIOS-TPM project on Github, I’m unclear how this relates to SeaBIOS source tree:
http://wiki.qemu.org/Features/TPM
https://github.com/stefanberger/seabios-tpm

So, that was the old 2011 TPMv1 news, that I am catching up to…. Today, Stephan has a new TPM2 patch for SeaBIOS, excerpt of announcement:

This series of patches adds TPM 2 support to SeaBIOS in the way previously proposed. TPM 2 support also changes the log entry format, which I have not addressed at all so far, and would append to the end of the series.

  tpm: Extend TPM TIS with TPM 2 support.
  tpm: Factor out tpm_extend
  tpm: Prepare code for TPM 2 functions
  tpm: Implement tpm2_startup and tpm2_s3_resume
  tpm: Implement tpm2_set_timeouts
  tpm: Implement tpm2_prepboot
  tpm: Implement tpm2_extend
  tpm: Implement tpm2_menu
  tpm: Implement TPM 2’s set_failure

Full message:
http://www.seabios.org/mailman/listinfo/seabios

Also search the recent checkins for other interesting TPM checkins, eg, Physical Presence API, etc.

I asked on the SeaBIOS list if there was a security roadmap for me to point to, and what consumer devices have TPM support; Kevin O’Connor replied, mentioning the addition of TPMv2, and:

I’m not aware of any new consumer devices shipping with the support, and I understand that KVM/QEMU have had TPM support for some time already.

I think some Google Chromebooks come with coreboot-based TPM-enabled SeaBIOS, and TPM is used to store developer mode state instead of CMOS. I haven’t found canon spec in ChromeOS site, but there are a few online references such as this:
https://news.ycombinator.com/item?id=9185719

I’m not aware of any new consumer devices shipping with the support. If you have a new system, check with the vendor to see if it supports TPM or not. If your BIOS is not SeaBIOS-based, check if it has TPM support; if not, ask the vendor why not.

It would be interesting for a security researcher to compare the BIOS security measures in currently-available consumer devices, SeaBIOS-based and other BIOS codebases. I am not sure how many different BIOS codebases there are, these days. Perhaps AMI and Phoenix have one, and some OEMs? I should research that more. Ralph Brown: help! 🙂

http://www.seabios.org/

FWTS 10.01.00 released

Ivan Hu of Canonical announced the 10.01.00 release of FWTS, the FirmWare Test Suite, which uses a fresh ACPIC, and includes with some new ACPI and UEFI test features, including supporting some new UEFI 2.5 variables.

Significant Updates:
* ACPICA: Update to version 20160108 (LP: #1532268)

New Features:
* acpi: method: add _PTC test
* sync with uefi 2.5 global variables
* uefidump: add dumping global variabl AuditMode
* uefidump: add dumping global variabl DeployedMode
* uefidump: add dumping global variable OsRecoveryOrder
* uefidump: add dumping global variable PlatformRecovery####
* uefidump: add dumping global variable SysPrepOrder
* uefidump: add dumping global variable SysPrep####
* ACPICA: Update to version 20151218 (LP: #1527733)
* esrtdump: add dumping for esrt table (LP: #1532103)

See full changelog for list of bugs fixed.

http://fwts.ubuntu.com/release/fwts-V16.01.00.tar.gz
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/16.01.00
https://launchpad.net/ubuntu/+source/fwts
https://lists.01.org/pipermail/luv/2016-January/000777.html