Lenovo ThinkPad X1 6en: Enabling S3 Sleep for Linux after Firmware Update

https://brauner.github.io/2018/09/08/thinkpad-6en-s3.html

CHIPSEC gets support for Nine more ACPI tables

Lots of news are filled with news about the latest  version of CHIPSEC released. I don’t see that, but there are some interesting new checkins w/r/t ACPI support:

ACPI_TABLE_SIG_BGRT = ‘BGRT’
ACPI_TABLE_SIG_LPIT = ‘LPIT’
ACPI_TABLE_SIG_ASPT = ‘ASPT’
+ACPI_TABLE_SIG_FIDT = ‘FIDT’
+ACPI_TABLE_SIG_HEST = ‘HEST’
+ACPI_TABLE_SIG_BERT = ‘BERT’
+ACPI_TABLE_SIG_ERST = ‘ERST’
+ACPI_TABLE_SIG_EINJ = ‘EINJ’
+ACPI_TABLE_SIG_TPM2 = ‘TPM2’
+ACPI_TABLE_SIG_WSMT = ‘WSMT’
+ACPI_TABLE_SIG_DBG2 = ‘DBG2’
+ACPI_TABLE_SIG_NHLT = ‘NHLT’
+ACPI_TABLE_SIG_MSCT = ‘MSCT’
+ACPI_TABLE_SIG_RASF = ‘RASF’
+ACPI_TABLE_SIG_SPMI = ‘SPMI’
+ACPI_TABLE_SIG_OEM1 = ‘OEM1’
+ACPI_TABLE_SIG_OEM2 = ‘OEM2’
+ACPI_TABLE_SIG_OEM3 = ‘OEM3’
+ACPI_TABLE_SIG_OEM4 = ‘OEM4’
+ACPI_TABLE_SIG_NFIT = ‘NFIT’

as well as some new SGX support… Fun!

https://github.com/chipsec/chipsec/commits/master

Lenovo ACPI bug – affects X1C6, X1Y3, X280, T480s, T480, T580, P52s, possibly more. ‎

“This bug deserves more attention than it is currently receiving. It should be pinned in every forum with an affected machine, so that owners of those machines will be aware that it exists. It is currently squirreled away in the T series forum, under the outdated title “T480s – ACPI bug”. I have asked that the title be updated and received no response, which is why I’m posting this here.[…]

There’s a bug in the ACPI tables that affects all of the machines listed in the title. The bug causes heavy CPU usage on one thread due to frequent ACPI interrupts. The symptoms are a slow system, and high CPU temperatures (idles around 65 degrees Celsius). Some operating systems may mitigate the symptoms, but the bug is present regardless.

The following circumstances trigger it:
-powering on the laptop
-waking from suspend (and possibly hibernate – untested)

The following actions prevent it:
-reboot the laptop (temporary fix)
-disable thunderbolt in the UEFI settings (permanent fix – with latest UEFI updates)

The official UEFI update changelogs for all of these machines make explicit mention of this issue: “-(Fix) Fix an issue where system may become hot by system interrupts when Thundrebolt is disabled in ThinkPad Setup – Security – I/O Port Access.”[…]

https://forums.lenovo.com/t5/ThinkPad-X-Series-Laptops/ACPI-bug-affects-X1C6-X1Y3-X280-T480s-T480-T580-P52s-possibly/td-p/4084521

https://forums.lenovo.com/t5/ThinkPad-T400-T500-and-newer-T/T480s-ACPI-bug/m-p/4064963#M124889

https://forums.lenovo.com/t5/ThinkPad-T400-T500-and-newer-T/T480s-ACPI-bug/m-p/4067181#M124936

https://download.lenovo.com/pccbbs/mobiles/n22ur05w.txt

 

ACPI Debugging: ACPI AML Debugger in Ubuntu 18.04

Alex Hung of Canonical — and one of the FirmWare Test Suite developers — has a new blog post, showing how to debug ACPI on recent builds of Ubuntu:

ACPICA is a project that provides an operating system (OS)-independent reference implementation. It also contains a list of utilities such as ASL compiler (iasl), acpiexec (an AML emulator) and so on. However, debugging AML on Linux in real time wasn’t provided in ACPICA … until Linux Kernel 4.13. The aml-debugger.txt the instruction of how to enable AML debugger, is available at Documentation/acpi/ in Linux kernel source code. In short, two things are required to run AML debugging. […] While compiling a custom-build kernel with the above two config is nothing new to kernel developers, it is often inconvenient for firmware developers who need to verify ACPI implementation in their firmware. Fortunately, Ubuntu 18.04 (x64) enables these two config by default, and one can run acpidbg on Ubuntu 18.04 – even on Ubuntu Live from USB too! Executing acpidbg on Ubuntu 18.04 is very straight-forward[…]

http://alexhungdmz.blogspot.ca/2018/05/acpi-debugging-1-acpi-aml-debugger-in.html

See also:

https://raw.githubusercontent.com/torvalds/linux/master/Documentation/acpi/aml-debugger.txt
https://www.kernel.org/doc/Documentation/acpi/debug.txt
https://wiki.ubuntu.com/DebuggingACPI
https://wiki.ubuntu.com/Kernel/Reference/ACPITricksAndTips
https://01.org/linux-acpi/documentation/debug-how-isolate-linux-acpi-issues
https://lwn.net/Articles/237085/

 

Lai (Lux ACPI Implementation): AML for Lux, a Unix-like OS

Lux is a new Unix-like operating written for the PC, aiming for high performance with minimal requirements. Lai, the Lux ACPI Implementation, is an implementation of ACPI’s Machine Language (AML) written for use with lux, but with portability in mind. As such, lai is portable and OS-independent. It depends on a few OS-specific functions, and so a small layer is written for each OS lai is to be used with, and this requires no changes to the core code of lai.

https://github.com/omarrx024/lux
https://omarrx024.github.io/

https://github.com/omarrx024/lai
https://omarrx024.github.io/docs/lai.html

AHCI BIOS Security Extension

This software is useful if:
* you have a (probably self-encrypting) hard disk / solid state drive that supports the (S)ATA SECURITY command set

* you want to boot from this drive.
* your motherboard’s BIOS does not support asking the user for a hard disk password at startup
* you don’t want to buy a new motherboard.
* the hard disk controller of your motherboard supports AHCI.

http://www.tb-kaiser.de/ahci_sbe/

https://github.com/TobiasKaiser/ahci_sbe

Linux ACPI Time and Alarm Device (TAD) driver

Rafael J. Wysocki of Intel submitted a patch to Linux ACPI for a ACPI Time and Alarm Device (TAD) driver:

Introduce a driver for the ACPI Time and Alarm Device (TAD) based on Section 9.18 of ACPI 6.2. This driver only supports the system wakeup capabilities of the TAD which are mandatory. Support for the RTC capabilities of the TAD will be added to it in the future. This driver is entirely sysfs-based. It provides attributes (under the TAD platform device) to allow user space to manage the AC and DC wakeup timers of the TAD: set and read their values, set and check their expire timer wake policies, check and clear their status and check the capabilities of the TAD reported by AML. The DC timer attributes are only present if the TAD supports a separate DC alarm timer. The wakeup events handling and power management of the TAD is expected to be taken care of by the ACPI PM domain attached to its platform device.

The ACPI Time and Alarm (TAD) device is an alternative to the Real Time Clock (RTC). Its wake timers allow the system to transition from the S3 (or optionally S4/S5) state to S0 state after a time period elapses. In comparison with the RTC Alarm, the TAD provides a larger scale of flexibility in the wake timers. The time capabilities of the TAD maintain the time of day information across platform power transitions, and keep track of time even when the platform is turned off.

More info: linux-acpi list archives, http://vger.kernel.org/majordomo-info.html

https://patchwork.kernel.org/patch/10287043/

Documentation/ABI/testing/sysfs-devices-platform-ACPI-TAD

ARM Dynamic Tables Framework

ARM has submitted a patch to UEFI’s Tianocore which adds a “Dynamic Tables” framework that abstracts ACPI amongst other things…  Readme excerpt of patch below:

This patch introduces a branch for implementing Dynamic Tables Framework.

To reduce the amount of effort required in porting firmware to new platforms, we propose this “Dynamic Tables” framework. The aim is to provide an example implementation capable of generating the firmware tables from an external source. This is potentially a management node, either local or remote, or, where suitable, a file that might be generated from the system construction. This initial “proof of concept” release does not fully implement that – the configuration is held in local UEFI modules.

The dynamic tables framework is designed to generate standardised firmware tables that describe the hardware information at run-time. A goal of standardised firmware is to have a common firmware for a platform capable of booting both Windows and Linux operating systems.

Traditionally the firmware tables are handcrafted using ACPI Source Language (ASL), Table Definition Language (TDL) and C-code. This approach can be error prone and involves time consuming debugging. In addition, it may be desirable to configure platform hardware at runtime such as: configuring the number of cores available for use by the OS, or turning SoC features ON or OFF.

The dynamic tables framework simplifies this by providing a set of standard table generators, that are implemented as libraries. These generators query a platform specific component, the ‘Configuration Manager’, to collate the information required for generating the tables at run-time.

The framework also provides the ability to implement custom/OEM generators; thereby facilitating support for custom tables. The custom generators can also utilize the existing standard generators and override any functionality if needed.

The framework currently implements a set of standard ACPI table generators for ARM architecture, that can generate Server Base Boot Requirement (SBBR) compliant tables. Although, the set of standard generators implement the functionality required for ARM architecture; the framework is extensible, and support for other architectures can be added easily.

The framework currently supports the following table generators for ARM:
* DBG2 – Debug Port Table 2
* DSDT – Differentiated system description table. This is essentially a RAW table generator.
* FADT – Fixed ACPI Description Table
* GTDT – Generic Timer Description Table
* IORT – IO Remapping Table
* MADT – Multiple APIC Description Table
* MCFG – PCI Express memory mapped configuration space base address Description Table
* SPCR – Serial Port Console Redirection Table
* SSDT – Secondary System Description Table. This is essentially a RAW table generator.

[…]Please create a branch called ‘dynamictables’ in edk2-staging.[…]

More info: see the “[PATCH] Branch to implement Dynamic Tables Framework” thread on the edk2-devel list by Sami Mujawar. And look for above branch to be created.

Hmm, it appears the links to the archives on the URL provided in the mailing list posts is not valid:
https://lists.01.org/mailman/listinfo/edk2-devel

V1 from Oct2017:

https://github.com/EvanLloyd/tianocore/tree/139_dynamic_tables_v1/MdeModulePkg/Universal/DynamicTables

Firmware Test Suite 18.02.00 is released

New Features:
* ACPICA: Update to version 20180209
* uefirtvariable: add test for EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS attribute

See full announcement for list of bugfixes.

In related news, LUV has picked up the latest FWTS.

http://fwts.ubuntu.com/release/fwts-V18.02.00.tar.gz
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/18.02.00
https://launchpad.net/ubuntu/+source/fwts
https://lists.ubuntu.com/mailman/listinfo/fwts-announce

DPTFExtract – Linux DPTF Extract Utility

This is a companion tool to Linux Thermal Daemon (thermald). This tool tries to reuse some of the tables used by “Intel ® Dynamic Platform and Thermal Framework (Intel® DPTF)” by converting to the thermal_conf.xml format used by thermald.

https://github.com/intel/dptfxtract

 

 

LUV 2.2-rc2 released

Megha Dey of Intel announced the v2.2-rc2 release of LUV, Linux UEFI Validation. Excerpts of announcement below, for full announcement, see LUV mailing list post.

Two main new features:

Dump list of Device-Specific Methods:
DSM (Device Specific Method) as defined in ACPI spec is a control method that enables devices to provide device specific control functions that are consumed by the device driver. DSM’s are optional on a platform and they are optional to be consumed by OS. Both these points mean that a kernel developer might be unaware of these DSM’s and hence might never use them in their device driver. By adding this feature, LUV could be used as a vehicle to educate kernel developers about these DSM’s. A device driver developer, from the list of DSM’s provided by LUV, could then evaluate the usefulness of a DSM and then decide if it needs to be used or left as an option.

Add tests in bits to detect Machine Check Errors:
Machine Check Error (MCE) test is a way to find the errors generated by the hardware or any specific subsystem(s). The value of these tests is that it detects any MCEs that might have occurred before Linux starts to boot. Hence, if detected, they were caused by hardware or possibly BIOS.

https://01.org/linux-uefi-validation/v2.2

https://lists.01.org/mailman/listinfo/luv

ARM adds ACPIView tool to UEFI Shell: dump ACPI tables

For UEFI Shell uers, there is another ACPI diagnostic tool, in addition to CHIPSEC and acpidump. Excerpts of edk2-devel mailing list post and tool manpage below, see full list posting for source code and more info.

ShellPkg: Add acpiview tool to dump ACPI tables
This program is provided to allow examination of ACPI table contents from the UEFI Shell. This can help with investigations, especially at that stage where the tables are not enabling an OS to boot. The program is not exhaustive, and only encapsulates detailed knowledge of a limited number of table types. Default behaviour is to display the content of all tables installed. ‘Known’ table types will be parsed and displayed with descriptions and field values. Where appropriate a degree of consistency checking is done and errors may be reported in the output. Other table types will be displayed as an array of Hexadecimal bytes. To facilitate debugging, the -t and -b options can be used to generate a binary file image of a table that can be copied elsewhere for investigation using tools such as those provided by acpica.org. This is especially relevant for AML type tables like DSDT and SSDT. The inspiration for this is the existing smbiosview Debug1 Shell command. Many tables are not explicitly handled, in part because no examples are available for our testing. The program is designed to be extended to new tables with minimal effort, and contributions are invited.

acpiview
Display ACPI Table information.

ACPIVIEW [[-?] | [[-l] | [-s AcpiTable [-d]]] [-c] [-v] [-h Highlight]]
-l – Display list of installed ACPI Tables.
-s – Display only the specified AcpiTable type.
AcpiTable : The required ACPI Table type.
-d – Generate a binary file dump of the specified AcpiTable.
-c – Consistency checking (enabled by default).
-v – Display verbose data (enabled by default).
-h – Enable/Disable Colour Highlighting.
Highlight : TRUE/ON enables highlighting;
FALSE/OFF (default) disables highlighting.
-? – Show help.

Formatted display and checking is provided for these signature types:
APIC – Multiple APIC Description Table (MADT)
BGRT – Boot Graphics Resource Table
DBG2 – Debug Port Table 2
FACP – Fixed ACPI Description Table (FADT)
GTDT – Generic Timer Description Table
IORT – IO Remapping Table
MCFG – Memory Mapped Config Space Base Address Description Table
RSDP – Root System Description Pointer
SLIT – System Locality Information Table
SPCR – Serial Port Console Redirection Table
SRAT – System Resource Affinity Table
XSDT – Extended System Description Table

EXAMPLES:

To display a list of the installed table types:
fs0:\> acpiview -l

To parse and display a specific table type:
fs0:\> acpiview -s GTDT

To save a binary dump of the contents of a table to a file in the current working directory:
fs0:\> acpiview -s DSDT -d

To display contents of all ACPI tables:
fs0:\> acpiview

Linaro releases Enterprise Reference Platform 17.12

ERP 17.12 has been released!

The goal of the Linaro Enterprise Reference Platform is to provide a fully tested, end to end, documented, open source implementation for ARM based Enterprise servers. The Reference Platform includes kernel, a community supported userspace and additional relevant open source projects, and is validated against existing firmware releases. The Linaro Enterprise Reference Platform is built and tested on Linaro Enterprise Group members hardware and the Linaro Developer Cloud. It is intended to be a reference example for use as a foundation for members and partners for their products based on open source technologies. The members and partners to include distribution, hyperscaler or OEM/ODM vendors, can leverage the reference for ARM in the datacenter.
[…]
– Focused on ACPI and UEFI use-cases.
[…]

http://releases.linaro.org/reference-platform/enterprise/17.12/
https://platforms.linaro.org/documentation/Reference-Platform/Platforms/Enterprise/ReleaseNotes-17.12.md/

More info: linaro-announce@lists.linaro.org list archives:
https://lists.linaro.org/mailman/listinfo/linaro-announce

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.

FWTS 17.11.00 released (and added to LUV)

The November 2017 release of FirmWare Test Suite is out, with many ACPI changes, and a few UEFI changes.

New Features:
* acpi: devices: add a new test for acpi ec device
* acpi: devices: add a new test for ACPI AC adapter device
* acpi: devices: add a new test for ACPI battery device
* acpi: devices: add a new test for smart battery device
* acpi: devices: add new tests for power and sleep button devices
* acpi: madt: check GICD’s system vector according to mantis 1819 (ACPI 6.2a)
* acp: nfit: add platform capability according to manit 1831 (ACPI 6.2a)
* lib: add new large resource data type for _CRS methods
* acpi: sdev: add ACPI SDEV test (mantis 1632)
* acpi: dppt: add ACPI PDTT test (mantis 1576)
* acpi: devices: add new tests for lid device
* acpi: devices: add new tests for ambient light sensor device
* acpi: devices: add new tests for time and alarm device
* acpi: devices: add new tests for wireless power calibration device
* acpi: add tests for _SRT control method
* auto-packager: mkpackage.sh: add bionic
* fwts: add bash command-line completion
* Add ACPI 1.0 RSDP test to make sure RSDT field isn’t null
* ACPICA: Update to version 20171110
* uefi: uefidump: add dumping for BluetoothLE device path
* uefi: uefidump: add dumping for DNS device path
* uefi: uefibootpath: add test for BluetoothLE device path
* uefi: uefibootpath: add test for DNS device path

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

See full announcement for list of few-dozen bugfixes.

Full announcement:
https://lists.ubuntu.com/archives/fwts-announce

In related news,  Gayatri Kammela has added this updated FWTS to LUV.

Update FWTS to version v17.11.00

Full patch:
https://lists.01.org/mailman/listinfo/luv

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.

“Linux/Acpi.A!tr”: Linux ACPI malware?

I noticed this on an AV vendor’s site, about some Linux-centric (?) ACPI malware. Wish there was more info on it. If you have more details, please leave a Comment on this blog, thanks!

Linux/Acpi.A!tr
ID 7546097
Released Oct 26, 2017

Linux/Acpi.A!tr is classified as a trojan.

A trojan is a type of malware that performs activites without the user’s knowledge. These activities commonly include establishing remote access connections, capturing keyboard input, collecting system information, downloading/uploading files, dropping other malware into the infected system, performing denial-of-service (DoS) attacks, and running/terminating processes. The Fortinet Antivirus Analyst Team is constantly updating our descriptions. Please check the FortiGuard Encyclopedia regularly for updates.

https://www.fortiguard.com/encyclopedia/virus/7546097