Tag: ACPI

BITS: new network-enabled release (and new mailing list)

~ hucktech ~ Leave a comment

Burt Triplett of Intel has announced the version 2070 release of BITS (BIOS Implementation Test Suite). The main new feature is network support, but also includes new UEFI and ACPI and Python features, better command line features, and other new features. I’ve just excerpted the first paragraph of the networking-centric portion of the announcement below, there are a lot of implementation caveats to read. See the full announcement for the list of features and bugfixes.

Note that there is also a new BITS mailing list, see below URL for ‘first post’ message in the archives:

BITS on EFI now supports TCP networking, using the Python socket module and various modules built atop it.  On EFI systems that provide `EFI_IP4_CONFIG_PROTOCOL` and `EFI_TCP4_SERVICE_BINDING_PROTOCOL`, we implement a `_socket` module in Python with support for TCP sockets over IPv4.  We then include Python’s higher-level socket module that runs on top of `_socket`.

https://lists.01.org/mailman/listinfo/bits
https://lists.01.org/pipermail/bits/2016-January/000000.html
http://biosbits.org/news/bits-2070/
http://biosbits.org/downloads/bits-2070.zip
https://github.com/biosbits/bits

FWTS adds test for undocumented ASPT ACPI

~ hucktech ~ Leave a comment

[[
UPDATE: see-also: https://firmwaresecurity.com/2016/01/22/who-created-the-acpi-aspt-spec/
]]

Colin  King of Canonical has added a new ACPI test to the FirmWare Test Suit (FWTS). The new test is for ASPT (ACPI System Performance Tuning). The problem is that ASPT is an undocumented ACPI table. As Colin says:

This table is not well described anywhere, however it is a frequently used table on AMD machines and the format is relatively simple set of 4 32 bit addresses.  This table has been discussed on the ACPICA devel mailing list:

https://lists.acpica.org/pipermail/devel/2015-November/000850.html

and this description matches the various acpi dumps of this table on AMD machines that I have access too. I believe the table refers to an AMD performance monitoring feature.

Here are some scary comments from the new test code to clarify the problem:

/* ASPT Table (reverse engineered, table is common on AMD machines) */

/* Without a specification to work with there is very little we can do to validate this apart from the
implest sanity check */
 
/* ACPI ASPT: determined by reverse engineering */

For more information see the fwts-devel list or the fwts source code:
https://lists.ubuntu.com/archives/fwts-devel/2015-December/007107.html
http://www.uefi.org/acpi
IMO, the UEFI Forum, who has recently taken over ownership of ACPI, should be working with this vendor to provide a proper public spec, if the table is being used in modern hardware.

FWTS 15.11.00 released

~ hucktech ~ Leave a comment

Alex Hung of Canonlical has announced the release of FWTS (FirmWare Test Suite) version 15.11.00, the November 2015 quarterly release, with multiple changes to the UEFI and ACPI tools.

= Significant Updates =
 * Update ACPICA to version 20150930

= New Features =
  * Add in the notion of ACPI compliance tests.
  * MADT subtables: Local SAPIC structure has 3 reserved bytes, not 1
  * ACPI: MADT: update GICC flag checks for ACPI 6.0
  * ACPI: MADT: further update to GICC flag checks for 6.0
  * acpi: method: skip scope names in method_evaluate_method
  * acpi: method: add _GPE test
  * acpi: method: add _TSN test
  * acpi: method: add _TFP test
  * acpi: method: add _EC test
  * acpi: method: add _CWS test
  * acpi: method: add _BTH test
  * auto-packager: mkpackage.sh: add xenial
  * acpi: tpm2: add check for zero control area address (LP: #1506442)
  * securebootcert: change fail to warning when MS UEFI CA not found in DB
  * lib: fwts_uefi: add BMC device path define
  * uefidump: add dumping the BMC device path
  * uefibootpath: add test for the BMC device path
  * lib: fwts_uefi: add the URI device path define
  * uefibootpath: add test for the URI device path
  * uefidump: add dumping for the URI device path
  * lib: fwts_uefi: add the UFS device path define
  * uefidump: add dumping for the UFS device path
  * uefibootpath: add test for the UFS device path

= Fixed Bugs =
  * dmi: dmicheck: fix SMBIOS issues on aarch64 systems
  * acpidump: add missing reserved fields to MADT structures
  * cpufreq: the calibration is taking a long time, make it faster
  * acpi: tcpa: replace tab with spaces to fix formatting alignment

More Information:

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

 

new Linux kernel NVDIMM IOCTL pass thru patch

~ hucktech ~ Leave a comment

Jerry Hoemann of HP (now HPE) posted a message to the linux-nvdimm@lists.01.org, linux-acpi, and linux-kernel lists with new patch to the Linux 4.3 kernel with a new ioctl inteface for NVDIMM DSMs:

nvdimm: Add an IOCTL pass thru for DSM calls

The NVDIMM code in the kernel supports an IOCTL interface to user space based upon the Intel Example DSM:
http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf

This interface cannot be used by other NVDIMM DSMs that support incompatible functions. This patch set adds a generic “passthru” IOCTL interface which is not tied to a particular DSM. A new IOCTL type “P” is added for the pass thru call. The new data structure ndn_pkg serves as a wrapper for the passthru calls.  This wrapper supplies the data that the kernel needs to make the _DSM call. Unlike the definitions of the _DSM functions themselves, the ndn_pkg provides the calling information (input/output sizes) in an uniform manner making the kernel marshaling of the arguments straight forward. This shifts the marshaling burden from the kernel to the user space application while still permitting the kernel to internally calling _DSM functions. To make the resultant kernel code easier to understand the existing functions acpi_nfit_ctl and __nd_ioctl were renamed to .*_intel to denote calling mechanism as in 4.2 tailored to the Intel Example DSM. New functions acpi_nfit_ctl_passthru and __nd_ioctl_passthru were created to supply the pass thru interface.

 drivers/acpi/nfit.c        |  91 ++++++++++++++++++++++++++++++++–
 drivers/nvdimm/bus.c       | 118 +++++++++++++++++++++++++++++++++++++++++—-
 drivers/nvdimm/dimm_devs.c |   6 +–
 include/linux/libnvdimm.h  |   3 +-
 include/uapi/linux/ndctl.h |  20 +++++++-
 5 files changed, 220 insertions(+), 18 deletions(-)

For more information, see the posting on the linux-nvdimm@lists.01.org mailing list archives.

http://pmem.io/documents/

ACPI debugger for Linux kernel

~ hucktech ~ Leave a comment

Last Friday, Lv Zheng of Intel sent a 5-part patch to the linux-acpi and linux-kernel mailing lists. Below is documentation excerpt from initial patch:

ACPICA / debugger: Add in-kernel AML debugger support

This patchset enables ACPICA debugger for Linux kernel and implements a userspace utility to access it.

A. Build the AML debugger
In order to build the kernel support of AML debugger, the following kconfig items should be enabled:
 CONFIG_ACPI_DEBUG=y
 CONFIG_ACPI_DEBUGGER=y
 CONFIG_DEBUG_FS=y
 CONFIG_ACPI_DEBUGGER_USER=m
The userspace tool can be found at tools/power/acpi/tools/acpidbg. To build this utility, staying in tools folder and type “make acpi”.

B. Load the AML debugger during runtime
In order to use the in-kernel AML debugger, the following command should be executed using root user:
 # modprobe acpi_dbg
 # mount -t debugfs none /sys/kernel/debug
 # acpidbg

C. Batch mode
In order to support scripts, the userspace utility also supports single command batch mode:
 # acpidbg -b “help”
 # acpidbg -b “tables”
 # acpidbg -b “find _LID”
 # acpidbg -b “execute \_SB.LID0._LID”
You can find the documentation about the ACPICA debugger commands in:
 https://acpica.org/sites/acpica/files/acpica-reference_17.pdf
 (The latest document can be found at https://acpica.org/documentation)
And refer to the chapter – ACPICA debugger reference to obtain the full description of the debugger commands. Note that not all commands are supported by an in-kernel AML debugger.

D. Unload the AML debugger during runtime
After terminating all acpidbg instances, the following command can be executed to remove the AML debugger from kernel:
 # rmmod acpi_dbg

The following tasks are not completed:
1. .flush() support in the kernel debugger IO driver.
2. multi-commands batch mode.
3. upstream the userspace acpidbg to the ACPICA upstream.

For more information, see the threads on the linux-kernel and linux-acpi mailing lists, run at vger.kernel.org.

Firmware Summit results

~ hucktech ~ Leave a comment

Al Stone of Red Hat posted a summary of the recent Firmware Summit that took place at the recent Linaro Connect event.

There’s a discussion on the state of ACPI on ARMv8, and Linux support. “So, please tell Linaro if there is something needed from the ACPI spec.  Call, write or send carrier pigeons, just let us know.”

There is a discussion on ACPI’s _DSD and Device Properties. A new dsd@acpica.org mailing list has been setup to help. A new repo of information —  on how to submit, approve, and use device properties in a community approved manner:

https://github.com/ahs3/dsd/tree/v-next/documentation

https://lists.acpica.org/mailman/listinfo/dsd

Matthew Garret wrote a document on Secure Boot:
https://lists.linaro.org/pipermail/fw-summit/2015-September/000170.html

I omitted a few items from the workshop’s notes. Read the full status here:
https://lists.linaro.org/pipermail/fw-summit/2015-October/000173.html

UDK2015 expected mid-October

~ hucktech ~ Leave a comment

The UDK github wiki has been updated to give information about upcoming UDK 2015 release next month. It appears to include most UEFI 2.5 features, plus a few new ones. Excerpt of changes:

 

Support UEFI 2.5 Updates:
 + Smart Card Reader & Smart card edge protocol (H file only)
 + Inline Cryptographic Interface Protocol (H file only)
 + UEFI USB Function I/O Protocol (H file only)
 + Add NVM Express Pass Thru Protocol
 + Add UFS stack
 + Add SD Device Path (H file only)
 + Add reconnect Browser Action
 + Ability to refresh the entire form
 + The default/options for the Ordered List question
 + Keyword Strings support
 + New CPER Memory Section (H file only)
 + New EFI_HASH2_PROTOCOL
 + Adding support for No executable data areas
 + Persistent Memory Type support
 + Add the Support for new PKCS7 Verification Services
 + System Prep Applications
 + Add SMBIOS3_TABLE_GUID in configuration table.
 + Exposing Memory Redundancy to OSPM
 + ESRT: EFI System Resource Table and component firmware updates
 + IPV6 support from UNDI
 + UEFI “Next” Feature –
    * IP_CONFIG2 Protocol
    * Boot from HTTP (Excluding IPV6)
    * DNSv4 and DNSv6

Support PI 1.4 Updates:
 + PI SMM GPI
 + New MP Service PPI
 + Multiple CPU health info
 + PEI SetBootMode Service() clarification
 + GetMemoryMap Update for ReservedMemory
 + New Graphics PPI
 + New Capsule PPI
 + SIO PEI and UEFI-Driver Model Architecture
 + Extended File Size Errata
 + Add Reset2 PPI

Excluded from UEFI 2.5 Updates:
 + Match2 Opcode and EFI_REGULAR_EXPRESSION_PROTOCOL
 + Bluetooth Support (H file only)
 + Errata Boot Manager Policy & SATA Device Path Node
 + RamDisk Device Path
 + UEFI “Next” Feature –
    * Boot from HTTP (Excluding IPV6)
    * WIFI support (H file only)
    * EAP2 Protocol (H file only)
    * UEFI TLS API
    * REST Protocol
    * Platform recovery
    * Customized Deployment of Secure Boot
    * BMC/Service Processor Device Path

Other features:
 + Add ACPI 6.0 definitions.
 + Add SMBIOS 3.0 definitions.
 + Support OpenSSL version 1.0.2d.

Looking forward to the upcoming checkins to Tianocore’s EDK2 trunk!

Full roadmap article:
https://github.com/tianocore/tianocore.github.io/wiki/RoadMap2015

RehabMan’s ACPI tools for OSX

~ hucktech ~ Leave a comment

I just noticed the project Laptop-DSDT-Patch, by RehabMan. It contains “Common DSDT patches for Ivy/Sandy/Haswell laptops for running OS X“, so it’s for ‘hackintosh’ hackers using non-Apple hardware to run Apple’s OS, OS X, and have to deal with non-Apple hardware/firmware, particularly ACPI’s DSDT table, a nice example of how the modding community generates some interesting firmware tools, if nothing else.

Quoting from from the beginning of RehabMan’s HP-ProBook-4x30s wiki on How to patch your DSDT (useful background even if you don’t this HP model):

Although there are pre-patched DSDTs available as downloads from the tonymacx86.com forums and in installer packages such as the HP ProBook Installer, there can be differences in individual DSDTs that can cause delays in booting and perhaps other problems. Perhaps there are slight differences in BIOS settings, memory installed, etc, that is causing these differences. It is best, therefore, to patch your own DSDT and install it into /Extra/dsdt.aml (Chameleon) or EFI/Clover/ACPI/patched (Clover). I have included five different methods for extracting your native DSDT. Just pick the method that seems easiest for you. The easiest one will depend on whether you still have Windows installed, whether you already have a Linux USB stick prepared, and just how familiar you are with both systems.

Quoting from the OSx86 wiki, for the Mac OSX-perspective on it, ACPI’s DSDT is:

The Differentiated System Description Table is the main table in the ACPI part of a computer’s BIOS. The Advanced Configuration and Power Interface (ACPI) defines a large number of tables that provide the interface between an ACPI-compliant operating system and system firmware. These allow description of system hardware in a platform-independent manner in ACPI Machine Language (AML). The problem is that OS X has an incomplete ACPI implementation which supports only a subset of DSDT. Modifying the DSDT allows the user to better support their hardware. For example, fixing Time Machine and the UUID 35 error is possible after modifying the DSDT. To patch your DSDT, you must either use a new table file that someone else has provided, or extract and modify your own. Then tell your bootloader to use the new DSDT file instead of the BIOS. On a few motherboards it is also possible to replace the BIOS with an updated BIOS with a patched DSDT. One of the simplest ways to extract your DSDT from your BIOS is by using DSDT Editor. Once you have downloaded DSDT Editor, open it and press File –> Extract DSDT. After 2-15 seconds, your DSDT should appear on the screen.

Look at the various ACPI-centric projects RepoMan has, there’re many! Also, the Ubuntu wiki and SmackerelOfOpinion blog are both excellent for ACPI diagnostic tips.

These ‘modding community’-based ACPI changes for OS X are educational, to see how people can extend their purchases for use cases beyond those that the vendor could imagine. As systems get more tamper-proof, it seems likely that users will have less and less ability to change things. [There also exists a HUGE modding community by photographers and their smartcameras (embedded devices). They add amazing new features. The other day I saw one talk about how they update the system to be able to take pictures of lighting better. Nice example of how owners can add features to their purchases, if able to update their firmware. 🙂 And of course there is custom ‘firmware’ for smartphones, entire distros.]

Personal modding hobbies aside, how much time, if any, do enterprise sysadmins currently spend fixing OEM ACPI tables and other firmware features, to make their systems work properly?

More Info:
https://github.com/RehabMan/Laptop-DSDT-Patch
https://github.com/RehabMan/HP-ProBook-4x30s-DSDT-Patch/wiki/How-to-patch-your-DSDT
https://bitbucket.org/RehabMan/os-x-maciasl-patchmatic
http://www.insanelymac.com/forum/topic/223205-dsdt-editor-and-patcher/
https://github.com/RehabMan?tab=repositories
http://uefi.org/acpi
http://smackerelofopinion.blogspot.com/2009/10/dumping-acpi-tables-using-acpidump-and.html
http://acpi.sourceforge.net/dsdt/
https://01.org/linux-acpi/documentation/overriding-dsdt
http://www.tldp.org/HOWTO/ACPI-HOWTO/dsdt.html
http://wiki.osdev.org/DSDT
http://wiki.osx86project.org/wiki/index.php/DSDT
https://msdn.microsoft.com/en-us/library/windows/hardware/dn495660%28v=vs.85%29.aspx#dsdt
https://wiki.debian.org/OverridingDSDT
http://www.insanelymac.com/forum/topic/278170-dsdt-%E2%80%94-what-is-it-and-how-do-i-get-it/
https://wiki.ubuntu.com/Kernel/Reference/ACPITricksAndTips
https://www.kernel.org/doc/Documentation/acpi/dsdt-override.txt
http://smackerelofopinion.blogspot.com/search/label/ACPI
http://clover-wiki.zetam.org/Configuration/ACPI#DSDT

FWTS updated

~ hucktech ~ Leave a comment

Ivan Hu of Canonical has announced the release of FWTS (FirmWare TestSuite), to 5.09.00. FWTS is a set of command line tools for Ubuntu-based and related Linux systems. It also includes a curses-based interface frontend, which is also the default UI to FWTS-live. FWTS is also included in LUV, the Linux UEFI Validation distribution, but it may be a few days until this latest release has been updated in LUV-live. The release features many bugfixes, as well as some new updates/features, including:

* Update ACPICA to version 20150717
* SMBios 3.0.0 tests supported
* acpi: add _CR3 test
* acpi: add _MTL test
* acpi: add _RST test
* acpi: add _PRR test
* dmicheck: SMBIOS 3.0.0 test

For more information, see the full announcement on the fwts-announce mailling list, and see the full changelog, /usr/share/doc/fwts/changelog.Debian.gz in the source tarball.

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

ACPI _DSD update

~ hucktech ~ Leave a comment

Early last month, the UEFI Forum updated this spec:

_DSD (Device Specific Data) Implementation Guide, v1.1
http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_1.htm

The main thing added to the above HTML document was a pointer to this spec:

Click to access _DSD-hierarchical-data-extension-UUID-v1.pdf

It describes a new Hierarchical Properties Extension UUID. I don’t know much about _DSD, it has been around for a while, so not sure if this 1.1 change is interesting or not.

I wish UEFI Forum would announce updates to ACPI specs. There web site has multiple press/news pages and RSS feeds, only a few of them are operational.

More Information:

http://uefi.org/acpi
https://lkml.org/lkml/2015/8/27/746

ACPI testing with BITS Python

~ hucktech ~ Leave a comment

Recently, Josh Triplett of Intel gave a talk on using BIOS Interface Test Suite (BITS) at LinuxCon North America.
http://events.linuxfoundation.org/events/linuxcon-north-america/program/slides

Demystifying ACPI and EFI via Python and BITS

Click to access bits-with-demo.pdf

BTW, Josh also gave this talk at LinuxConNA’15 as well:

Everything’s a File Descriptor

Click to access fd_0.pdf

I think I’ve mentioned BITS in this blog before. But just in case I’ve not, BITS is a powerful, strange set of BIOS diagnostic tools. BITS started as a BIOS-centric tool, but now includes some UEFI support as well. BITS uses the GRUB boot manager as it’s UI, using GRUB menus for different features, see the screenshots page for a better understanding:
http://biosbits.org/screenshots/

BITS also includes a Python interpreter, so you can do interactive Python, or write scripts to test firmware. BITS has interfaces for BIOS, UEFI, and ACPI data.
http://biosbits.org/scripting/

Jake Edge wrote an excellent follow-up to Josh’s LinuxCON talk, with an article in LWN.net, discussing BITS’s Python for UEFI and ACPI investigations.

In a talk that could easily be seen as a follow-on to his PyCon 2015 talk, Josh Triplett presented at LinuxCon North America on using Python to explore the low-level firmware of today’s systems. The BIOS Implementation Test Suite (BITS) provides an environment that hearkens back to the days of BASIC, PEEK, and POKE, as he demonstrated at PyCon in Montréal in April, but it is much more than that. In Seattle at LinuxCon, he showed that it can also be used to look at and use the EFI and ACPI code in a system—all from Python.

The article is part of LWN.net subscriber-only content, and has been ‘leaked’ (see next URL below), and as the link on the page mentions, an occasional leak isn’t too bad, and helps with subscriptions. If you don’t have a LWN subscription, please think about it, they are probably the best news source for low-level Linux technologies. They have a 1-month free trial.

After reading this article, Laszlo Ersek of Red Hat started up a thread with Josh on the QEMU and UEFI dev mailing lists, with some new ways of thinking about using BITS Python for ACPI testing. Lots of good ideas on this thread, if you care about QEMU, ACPI, AML, or ACPICA tools please read the thread: sorry, I’m too lazy to summarize all of the ACPI nuances in the thread, it’s only a few messages.

Using Python to investigate EFI and ACPI
Newsgroups: gmane.comp.emulators.qemu, gmane.comp.bios.edk2.devel
http://thread.gmane.org/gmane.comp.emulators.qemu/358997

I hope some of the ACPI/AML testing ideas in this thread happen!

More Information:

https://github.com/biosbits/bits

Linaro Firmware mini-Summit next month

~ hucktech ~ Leave a comment

Today on the Linaro Firmware Summit mailing list, Al Stone of Red Hat just announced the next Firmware Summit

What: Linaro Firmware mini-Sumit (at Linaro Connect)
When: Tuesday, September 22th, 2015, 2-6pm
Where: Hyatt Regency San Francisco Airport Hotel, Burlingame, CA

Initial agenda topics include:

1) Current state of ACPI on ARM
2) Support/backing for a longer term organization (i.e., mailing lists, web sites, further meetings…)
3) Use of _DSD device properties
4) Follow-up on others items from the last meeting (mostly promised documents)

Other topics are being solicited. See the full posting on the fw-summit list archives.

https://lists.linaro.org/mailman/listinfo/fw-summit
http://sanfranciscoairport.hyatt.com/en/hotel/home.html
http://connect.linaro.org

ACPICA releases Version 20150818

~ hucktech ~ Leave a comment

Last week ACPICA.org released a new version of their ACPI code. Version 20150818, released 2015-08-18, has various bugfixes, cleanups and simplifications to the ACPI Disassembler and Debugger, including making the Debugger a fully standalone component. Various new command-line options in the AcpiNames, AcpiExec, iASL/Disassembler, Debugger tools.

Two specific new Disassembler and Debugger commands:

iASL/Disassembler: Implemented a prototype “listing” mode that emits AML that corresponds to each disassembled ASL statement, to simplify debugging.

Debugger: Add option to the “objects” command to display a summary of the current namespace objects (Object type and count). This is displayed if the command is entered with no arguments.

Besides this release, the trunk has some even fresher updates. For full details, see the readme in the source distribution and trunk history.

https://acpica.org/downloads/version-20150717
https://github.com/acpica/acpica/commits/master
https://acpica.org/source
https://github.com/acpica/acpica/

AArch64 support for ACPI BERT in Linux

~ hucktech ~ Leave a comment

ACPI is not only in the firmware of Intel-based systems, but it’s also now inside ARM-based systems. Today on the Linaro-ACPI mailing list, there was a patch for ACPI BERT support for AArch64. I think support had already been in for Intel already, unclear how long.

APEI Boot Error Record Table (BERT) support

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. Once error log is printed out clear error status so it would not be print during next boot again.

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. The following log is a BERT record after system reboot because of hitting a fatal error.

BERT: Obtained BERT iomem region <00000000fe801000-00000000fe802000> for BERT.
[Hardware Error]: Error record from previous boot:
[Hardware Error]: event severity: fatal
[Hardware Error]:  Error 0, type: fatal
[Hardware Error]:   section_type: memory error
[Hardware Error]:   physical_address: 0x00000000fe800000
[Hardware Error]:   physical_address_mask: 0x0000000000000fff
[Hardware Error]:   card: 0 module: 1 bank: 0 device: 1 row: 1 column: 1 bit_pos

For more information about BERT, please refer to ACPI Specification version 6.0, section 18.3.1.

For more information about this patch, see this thread:
https://lists.linaro.org/pipermail/linaro-acpi/2015-August/005611.html

For more on BERT, also see /src/acpi/bert/bert.c in the FirmWareTestSuite (FWTS).

Click to access ACPI_6.0.pdf

http://www.spinics.net/lists/linux-acpi/msg57384.html
https://lists.linaro.org/mailman/listinfo/linaro-acpi

WPBT attacks from the past: Alex at SyScan12

~ hucktech ~ 1 Comment

The recent Lenovo LSE blunder made most of the world aware of Windows WBPT ACPI table and how the firmware injects an executable into the OS, a feature of Windows that all OEMs are likely using. While the media is wondering about WBPT and why it’s not prominently displayed on many web sites, Xeno of LegbaCore pointed out that Alex Ionescu gave a talk at SyScan 2012 on this specific topic:

ACPI 5.0 Rootkit Attacks Againts Windows 8
Alex Ionescu
This talk will disclose certain new features of the ACPI 5.0 Specification which is now public and was primarily designed to support ACPI on ARM Embedded SoCs for the upcoming release of Windows 8. Some of these new features have important security considerations which have not been traditionally monitored by security products and/or users, specifically in the areas of covert code execution at Ring 0 privileges.

https://www.syscan.org/index.php/download/get/a722b1acb9396d82323da3a78235fdc0/SyScan12Slides.zip
https://www.syscan.org/index.php/archive/view/year/2012/city/sg/pg/program
https://www.syscan.org/index.php/archive/view/year/2012/city/sg/pg/speakers#004
https://www.syscan.org/index.php/download/previous
http://www.alex-ionescu.com/

Thanks for reminding us, Xeno!

What’s the next built-in ACPI attack?

~ hucktech ~ Leave a comment

[UPDATE: just confirmed that ACPI.info’s links page had the WPBT link since 2011. After posting below article, I wondered if the ACPI.info webmaster updated their links page in the last few days…)
https://web.archive.org/web/20111208014141/http://www.acpi.info/links.htm

While the media is currently blaming Lenovo for sloppy Windows QA, they’re also waking up to the reality that Windows has been using for the last few years. Initial Ars Technica and YCombinator posts on the topic quoted the abstract to the spec on a web page that was no longer available, so it sounds conspiratorial.  But the doc has been online since 2011. Besides microsoft.com-based links, the ACPI.info web site maintains a good set of links, including a pointer to the WPBT spec, and other ACPI-related table specs.

http://www.acpi.info/links.htm

The ACPI specs — at least some of them? — are maintained by the UEFI Forum. The UEFI Forum’s web site does NOT have a link to the WPBT spec.

http://www.uefi.org/acpi

I’ll bet there’re a few other existing ‘unknown’ ACPI features hidden on the ACPI.info links page that’ll be ‘discovered’ in the next few months, due to another sloppy OEM or sharp security researcher… From above links URL, here’ s a partial list (I omitted multiple entries which’re specs for other hardware, and some of those might also include ACPI tables) of ACPI tables to attack:

Core System Resources Table, CSRT
Debug Port Table, DBGP
Debug Port Table 2, DBG2
DMA Remapping Table, DMAR
IA-PC High Precision Event Timer Table, HPET
I/O Virtualization Reporting Structure, IVRS
iSCSI Boot Firmware Table, IBFT
Management Controller Host Interface Table, MCHI
Microsoft Software Licensing Tables, MSDM, SLIC
Multiprocessor Startup for ARM Platforms
PCI SIG’s MCFG
Serial Port Console Redirection Table, SPCR
Server Platform Management Interface Table, SPMI
Simple Boot Flag Table, BOOT
Smart Battery System Components and SMBus Spec
Trusted Platform Module 2 Table, TPM2
Trusted Computing Platform Alliance Capabilities Table, TCPA
Watchdog Action Table, WDAT
Watchdog Timer Resource Table, WDRT
Windows ACPI Emulated Devices Table, WAET
Windows Platform Binary Table, WPBT

Quoting Wikipedia on ACPI security risks:

“Ubuntu Linux founder Mark Shuttleworth has likened ACPI to Trojan horses. He has described proprietary firmware (ACPI-related or any other firmware) as a security risk, saying that “firmware on your device is the NSA’s best friend” and calling firmware (ACPI or non-ACPI) “a Trojan horse of monumental proportions”. He has pointed out that low quality, closed source firmware is a major threat to system security: “Your biggest mistake is to assume that the NSA is the only institution abusing this position of trust — in fact, it’s reasonable to assume that all firmware is a cesspool of insecurity, courtesy of incompetence of the highest degree from manufacturers, and competence of the highest degree from a very wide range of such agencies”. As a solution to this problem, he has called for declarative firmware (ACPI or non-ACPI). Firmware should be open-source so that the code can be checked and verified. Firmware should be declarative, meaning that it should describe “hardware linkage and dependencies” and should not include executable code.”

Vendors need to be disclosing a LOT MORE information about what they’ve included in their firmware, now that people are aware of this, thanks to Lenovo. It is easy to fix OEM’s mistakes at OS level, by reinstalling an open source OS, or installing vanilla Windows and then getting the drivers from the OEM/IHVs. But you can’t update your system’s firmware, and ACPI is the new dumping ground for OEM bloat. Well, not new, just newly-realized by some of us. I want a system with absolute minimail ACPI table bloat, and I want to KNOW what tables are shipped on the firmware. Linux OEMs: don’t ship COTS firmware that has Windows-centric ACPI blobs in them. If you look on #UEFI on G+ and Twitter, you’ll find more and more people demanding Open Hardware and fully-open source firmware, which is refreshing. 🙂

tool mini-review: RWEverything

~ hucktech ~ Leave a comment

RW, aka RWEverything (Read and Write Everything) is a GUI Windows-based firmware utility, written by Jeff.

“This utility access almost all the computer hardware, including PCI (PCI Express), PCI Index/Data, Memory, Memory Index/Data, I/O Space, I/O Index/Data, Super I/O, Clock Generator, DIMM SPD, SMBus Device, CPU MSR Registers, ATA/ATAPI Identify Data, Disk Read Write, ACPI Tables Dump (include AML decode), Embedded Controller, USB Information, SMBIOS Structures, PCI Option ROMs, MP Configuration Table, E820, EDID and Remote Access. And also a Command Window is provided to access hardware manually. Powerful utility for hardware engineers, firmware (BIOS) engineers, driver developers, QA engineers, performance test engineers, diagnostic engineers, etc.”

“This utility comes with ABSOLUTELY NO WARRANTY, it allows you to modify hardware settings, this may damage your system if something goes wrong. Author will not take any responsibility about that, you are on your own risk. This utility should not be used in commercial products.”

RW supports multiple Super I/O devices (Winbond (18), ITE (12), SMSC (8), FinTek (4), Nuvoton (6)) and SMBus Controllers (Intel (9), SiS (6), VIA (4), ULi (4), ATI (3), nVidia (13)).

It is Windows-centric utility, shipping with Win32 or Win64 binaries. It has an extensive ChangeLog, spanning v1.6.8 from 8/6/2015 to v0.1 back around 2005, but does not ship with any documentation, just EXEs. If you use Windows, you might want to check this out. If you find the tool useful, the author has a Donate button on his home page, please consider donating to the program’s author. I wish the tool was open source, and supported multiple operating systems, …but I’ll take what I can get. Thanks Jeff!

Home

Supported Hardware

Download

Absolute Joins the RSA Ready Technology Partnership Program

~ hucktech ~ Leave a comment

Yesterday, Absolute announced that they’ve joined the RSA Ready Technology Partnership Program.

“Absolute announced today a new collaboration with RSA to offer enhanced endpoint data collection and remediation. As part of the RSA Ready Technology Partnership program, this effort is designed to deliver seamless interoperability between Absolute and RSA Security Analytics, an industry leading advanced threat detection and forensics platform. Using the Absolute SIEM connector, mutual customers can now get deeper visibility into their endpoint deployments by feeding vital Absolute endpoint data directly into the RSA Security Analytics monitoring platform.  If an endpoint security alert is triggered, customers will be able to promptly investigate and respond to potential threats within the broader context of the RSA Security Analytics environment. Customers will also be able to correlate logs, packets, NetFlow, and endpoint data, all within the same platform.”

“Absolute’s Persistence(R) technology is embedded into the core of most devices at the factory. Once activated, it provides organizations with comprehensive visibility into all of their devices so they can confidently manage mobility, investigate potential threats, and take action if a security incident occurs. Most importantly, they can apply remote security measures to protect each device and the data it contains.”

See the full announcement for more details:

http://blogs.absolute.com/blog/absolute-joins-the-rsa-ready-technology-partnership-program/

Absolute’s CompuTrace is a unique security tool for firmware, it’s device is embedded into many (most?) modern systems, and the device checks if software support is disabled in the firmware, and re-enables it.

“Absolute Data & Device Security (DDS), formerly Absolute Computrace, is an adaptive endpoint security solution. It provides you with a persistent connection to all of your endpoints and the data they contain.”

“Our OEM partners embed Persistence technology into the BIOS or firmware of computers, netbooks, tablets, and smartphones during the manufacturing process. Once activated, customers who purchase these devices benefit from an extra level of security, persistence, and support.”

“Persistence technology from Absolute provides you with visibility and control over all of your devices, regardless of user or location. If an Absolute software client is removed from an endpoint, it will automatically reinstall so you can secure each device and the sensitive data it contains. No other technology can do this. Persistence technology is built into tens of millions of devices around the world and provides organizations with a trusted lifeline to each device in their deployment, regardless of user or location.”

You can use UEFITool to see if Absolute is in your firmware by searching for “computrace” Unicode string.

http://www.absolute.com/en/partners/compatibility
http://www.absolute.com/en/products/dds
https://lojack.absolute.com/en-gb/corporate/bios-compatibility
http://www.absolute.com/en/products/dds/requirements

Lenovo Service Engine

~ hucktech ~ Leave a comment

A bit more on this topic from yesterday:

Lenovo LSE, WPBT and wpbbin.exe


Lenovo has a response:

Lenovo Statement on Lenovo Service Engine (LSE) BIOS
http://news.lenovo.com/article_display.cfm?article_id=2013

There are more news agencies reporting on this story:
http://thetechportal.in/2015/08/12/lenovo-in-a-soup-for-secretly-downloading-update-and-software-even-after-system-wipe/
http://gadgets.ndtv.com/laptops/news/lenovo-covertly-downloading-installing-software-on-its-windows-pcs-reports-727109

Lenovo once again in hot waters over Lenovo Service Engine BIOS


http://thenextweb.com/insider/2015/08/12/lenovo-used-a-hidden-windows-feature-to-ensure-its-software-could-not-be-deleted/

Yuck, is each OS vendor using UEFI as a crutch? I wish the Linux Foundation (or some other group) has advise for chip vendors, IBVs, IHVs, and pre-OS ISVs on how to use Linux properly on UEFI systems. It should require that this Windows-centric BIOS code to NOT be present on a Linux system. What other OS-specific crud is in my closed-source BIOS?!

FWTS 15.08.00 released

~ hucktech ~ Leave a comment

Today Canonical has released version 15.08.00 of FWTS (FirmWare Test Suite), a set of firmware-related tests for Linux-based systems. The tests can be run via command line, or via a curses front-end, the latter of which is used by the FWS-live distribution. FWTS is also included in Intel’s LUV-live (Linux UEFI Validation) distribution, but it’ll take LUV a bit of time to update to new FWTS release. FWTS is also available as packages on Ubuntu-based distributions.

It appears that most new features are ACPI-related. New ACPI TPM2 and IORT tests, new tables for: FPDT, MCHI, STAO, ASF!, WDAT, and a few other things. There were a lot of bugfixes as well. For more information, see the full announcement, the changelog, and sources:

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

I wish ALL Linux/FreeBSD distributions would ship FWTS, not just Ubuntu-based ones: FTWS is very useful to detect if system has anomalies which’ll make it difficult to install/use the OS. Granted, those distro uses can just use FWTS-live, but they have to reboot into FWTS-live to use FWTS, with no native packaging.