Canonical Voices

Colin Ian King

Firmware Test Suite New Features in Ubuntu Raring 13.04

April 26, 2013

by Colin Ian King

Under acpi , firmware , fwts , tools , uefi

The Firmware Test Suite (fwts) is a tool containing a large set of tests to exercise and diagnose firmware related bugs in x86 PC firmware. So what new shiny features have appeared in the new Ubuntu Raring 13.04 release?

UEFI specific tests to exercise and stress test various UEFI run time services:

* Stress test for miscellaneous run time service interfaces.
* Test get/set time interfaces.
* Test get/set wakeup time interfaces.
* Test get variable interface.
* Test get next variable name interface.
* Test set variable interface.
* Test query variable info interface.
* Set variable interface stress test.
* Query variable info interface stress test.
* Test Miscellaneous runtime service interfaces.

These use a new kernel driver to allow fwts to access the kernel UEFI run time interfaces. The driver is built and installed using DKMS.

ACPI specific improvements:

* Improved ACPI 5.0 support
* Annotated ACPI _CRS (Current Resource Settings) dumping.

Kernel log scanning (finds and diagnoses errors as reported by the kernel):

* Improved kernel log scanning with an additional 450 tests.

This release also includes many small bug fixes as well as minor improvements to the layout of the output of some of the tests.

Many thanks to Alex Hung, Ivan Hu, Keng-Yu Lin and Matt Fleming for all the improvements to fwts for this release.

sbkeysync & maintaing uefi key databases

August 24, 2012

Under kernel , secure-boot , ubuntu , uefi

Over the last couple of weeks I've been working on a set of secure-boot tools. Originally, this project was intended as a quick implementation of an EFI-image-signing utility, but it has since grown a little. I've now added code to help maintain the UEFI signature databases from within a running OS.

A new utility, sbkeysync, reads the current EFI signature databases from firmware, and reads a set of keys from a standard location in the filesystem - for example, /etc/secureboot/keys. It then updates the firmware key databases with any keys that are not already present.

A filesystem keystore will look something like this:

/etc/secureboot/keys/PK/<pk-file>
/etc/secureboot/keys/KEK/<kek-file-1>
/etc/secureboot/keys/KEK/<kek-file-2>
/etc/secureboot/keys/KEK/…
/etc/secureboot/keys/db/<db-file-1>
/etc/secureboot/keys/db/<db-file-2>
/etc/secureboot/keys/db/…
/etc/secureboot/keys/dbx/<dbx-file-1>
/etc/secureboot/keys/dbx/<dbx-file-2>
/etc/secureboot/keys/dbx/…

These files need to be in a certain format: signed EFI_SIGNATURE_LIST data. There's two other utilities in the sbtools tree to help to create the key files: sbsiglist and sbvarsign. The following example shows how you'd use these tools to do a basic secure boot key configuration.

An example key setup

If you're interested in trying sbkeysync, the following guide should get you set up. To start, you'll need:

A build of the secure boot tools (git repository information below);
A kernel with the efivars filesystem. Either build your own kernel with efivars-1f087c6.patch (from Matthew Garrett, with some minor changes), or use linux-image-3.5.0-13-generic_3.5.0-13.14~efivars1_amd64.deb, which should work on Ubuntu 12.04 or 12.10; and
A machine with firmware that implements UEFI secure boot, configured to be in setup mode (ie, no PK installed).

Be warned that you're playing with three different layers of development code here: the secure boot tools are new, the efivars implementation hasn't had a lot of review yet, and firmware secure boot implementations are still fairly recent too. I'd recommend against doing this testing on a production machine.

generating keys

We'll generate a test key, and a self-signed certificate:

[jk@pecola ~]$ openssl genrsa -out test-key.rsa 2048
[jk@pecola ~]$ openssl req -new -x509 -sha256 \
        -subj '/CN=test-key' -key test-key.rsa -out test-cert.pem
[jk@pecola ~]$ openssl x509 -in test-cert.pem -inform PEM \
        -out test-cert.der -outform DER

We'll also need a GUID to represent the "key owner". Just generate one with uuidgen.

[jk@pecola ~]$ guid=$(uuidgen)
[jk@pecola ~]$ echo $guid

generating key updates

In order to install this key into the firmware signature databases, we need to create an EFI_SIGNATURE_LIST container for the key, and provide an EFI_VARIABLE_AUTHENTICATION_2 descriptor. The update data will be self-signed, to keep things simple.

First, we create the EFI_SIGNATURE_LIST containing the certificate:

[jk@pecola ~]$ sbsiglist --owner $guid --type x509 --output test-cert.der.siglist test-cert.der

Next, we create a signed update for the EFI signature databases. The signed update consists of the certificate, prefixed with an EFI_VARIABLE_AUTHENTICATION_2 descriptor. The authentication descriptor signs the key data, plus the variable name and attributes. Becuase the variable name is included, we need to generate a separate signed update for each variable (PK, KEK and db):

[jk@pecola ~]$ for n in PK KEK db
> do
>   sbvarsign --key test-key.rsa --cert test-cert.pem \
>     --output test-cert.der.siglist.$n.signed \
>     $n test-cert.der.siglist
> done

creating a keystore

Next up, we'll put our keys into standard locations for sbkeysync to find:

[jk@pecola ~]$ sudo mkdir -p /etc/secureboot/keys/{PK,KEK,db,dbx}
[jk@pecola ~]$ sudo cp *.PK.signed /etc/secureboot/keys/PK/
[jk@pecola ~]$ sudo cp *.KEK.signed /etc/secureboot/keys/KEK/
[jk@pecola ~]$ sudo cp *.db.signed /etc/secureboot/keys/db/

If you'd rather use a different location for the keystore, just use the --keystore and/or --no-default-keystores arguments to the sbkeysync commands that follow.

using `sbkeysync`

We can now use sbkeysync to synchronise the firmware key databases with the keystore we just created. Do a dry-run first to make sure all is OK:

[jk@pecola ~]$ sbkeysync --verbose --pk --dry-run
Filesystem keystore:
  /etc/secureboot/keys/db/test-cert.der.siglist.db.signed [2116 bytes]
  /etc/secureboot/keys/KEK/test-cert.der.siglist.KEK.signed [2116 bytes]
  /etc/secureboot/keys/PK/test-cert.der.siglist.PK.signed [2116 bytes]
firmware keys:
  PK:
  KEK:
  db:
  dbx:
filesystem keys:
  PK:
    /CN=test-key
     from /etc/secureboot/keys/PK/test-cert.der.siglist.PK.signed
  KEK:
    /CN=test-key
     from /etc/secureboot/keys/KEK/test-cert.der.siglist.KEK.signed
  db:
    /CN=test-key
     from /etc/secureboot/keys/db/test-cert.der.siglist.db.signed
  dbx:
New keys in filesystem:
 /etc/secureboot/keys/db/test-cert.der.siglist.db.signed
 /etc/secureboot/keys/KEK/test-cert.der.siglist.KEK.signed
 /etc/secureboot/keys/PK/test-cert.der.siglist.PK.signed

The output will list the keys were found in the EFI key databases, keys found in the filesystem keystore, and which keys should be inserted to the EFI key databases to bring them in sync with the keystore.

If all looks good, we can remove the --dry-run argument to actually update the firmware key databases. However, be careful here - once a PK is enrolled, the machine is no longer in setup mode, and secure boot is enforced. At the very least, ensure that your firmware setup screens have a facility for returning your machine to setup mode, and/or removing the PK.

Note that some firmware implementations may require a reboot for the changes to take effect in the EFI variables. Before you do this though, you'll probably want to sign your bootloader, so that you can actually boot something!

signing a bootloader

Now that secure boot is enabled, it'd be nice if we actually had something to boot. Although it isn't recommended for production systems, we'll just sign the GRUB2 binary that's already there:

[jk@pecola ~]$ sbsign --key test-key.rsa --cert test-cert.pem \
        --output grubx64.efi /boot/efi/efi/ubuntu/grubx64.efi
[jk@pecola ~]$ sudo cp /boot/efi/efi/ubuntu/grubx64.efi{,.bak}
[jk@pecola ~]$ sudo cp grubx64.efi /boot/efi/efi/ubuntu/

reverting to setup mode

Theoretically, since we have the private-key component of PK, we can revert the machine from user-mode to setup mode. This requires writing an empty signed update to the PK variable:

[jk@pecola ~]$ : > empty
[jk@pecola ~]$ sbvarsign --key test-key.rsa --cert test-cert.pem \
        --attrs NON_VOLATILE,BOOTSERVICE_ACCESS,RUNTIME_ACCESS \
        --include-attrs --output empty.PK.signed PK empty
[jk@pecola ~]$ sudo dd bs=4k if=empty.PK.signed \
        of=/sys/firmware/efi/vars/PK-8be4df61-93ca-11d2-aa0d-00e098032b8c

However, I have not been able to reset the PK on all firmware implementations so far; there may be bugs in the signing tools (or firmware) that prevent the update from being properly verified. Because of this, I strongly suggest checking for the facility to clear the PK through your firmware setup screens before attempting to set the PK.

secure boot tools resources

If you'd like to check out the code, the following links may be useful:

The git repository, at git://kernel.ubuntu.com/jk/sbsigntool
sbtools on Launchpad

Colin Ian King

Ubuntu ODM portal

June 19, 2012

by Colin Ian King

Under bios , debugging , firmware , fwts , hotkeys , kernel , uefi

A new Ubuntu portal http://odm.ubuntu.com is a jump-start page containing links to pages and documents useful for Original Design Manufactures (ODMs), Original Equipment Manufacturers (OEMs) and Independent BIOS vendors.

Some of the highlights include:

A BIOS/UEFI requirements document that containing recommendations to ensure firmware is compatible with the Linux kernel.

Getting started links describing how to download, install, configure and debug Ubuntu.

Links to certified hardware, debugging tools, SystemTap guides, packaging guides, kernel building notes.

Debugging tips, covering: hotkeys, suspend/resume, sound, X and wireless and an A5 sized Ubuntu Debugging booklet.

Link to fwts-live, the Firmware Test Suite live image.

..so lots of useful technical resources to call upon.

Kudos to Chris Van Hoof for organizing this useful portal.

shallow monkey

YAHTNG

May 29, 2012

by shallow monkey

Under canonical , gpt , ubuntu , uefi

Yet Another Helping The Next Guy

I bought my son a shiny new Ivy Bridge based Asus laptop from dealnews for high school graduation. Of course, he only runs Ubuntu, but I wanted to keep the Win 7 64 around for flashing BIOS and related reasons (and someday he may need to run some Windows program....)

It's pretty straight-forward to install Ubuntu alongside windows in a dual-boot fashion as the Live installer knows how to do this. But apparently not on some UEFI based systems--or that's what I thought. It turns out, the installer knows how to work with UEFI systems as well. It just doesn't know how to do it on a system with a broken/corrupt/obscured GUID Partition Table (gpt).

I've used gpt for years as I used to work in HP's Itanium Linux lab. And I've seen some GPT tables corrupted before. The ASUS (at least this one) ships with the secondary GPT corrupted. The last partition (I think 5th) somehow extends INTO the secondary GPT. (Think of the secondary as a backup table in case the primary gets corrupted--a failsafe.) This corrupt secondary table makes the partition table unreadable or possibly unusable to Ubuntu (and moreover, to the underlying libparted and the parted utility.) The installer just "determined" that the disk was unformatted so it kindly offered to just install Ubuntu to this blank disk (destroying all the existing partitions in the process.) Not so good.

I downloaded gdisk (from Universe) as it seems to be designed from the ground up for GPT tables and it was able to read the partition table and show me the partitions. These matched up with what /proc/partitions was showing me (which seemed to be right all along.) It also matched up with what I was seeing in Windows 7. ASUS ships with a C drive, a D drive, and a recovery drive along with the normal EFI system partition (ESP) and a Microsoft Reserved Partition (MSR). So the layout looked something like this:

Number Start (sector) End (sector) Size Code Name 1 2048 411647 200.0 MiB EF00 EFI system partition 2 411648 673791 128.0 MiB 0C01 Microsoft reserved part 3 673792 339511295 161.6 GiB 0700 Basic data partition 4 339511296 925575167 279.5 GiB 0700 Basic data partition 5 925575168 976773167 24.4 GiB 2700 Basic data partition

Where 3 is C (OS) drive, 4 is D (DATA) drive, and 5 is the ASUS Recovery partition. It is partition 5 that seemed to be the source of the error:

Warning! Secondary partition table overlaps the last partition by
33 blocks!
You will need to delete this partition or resize it in another utility.

To resolve this issue, I simply deleted partition 4 and recreated it from the same start point but smaller and ending sooner. Then I dd'd partition 5 to another disk, deleted it and recreated it (same size) but now it ended before the end of the disk. I then restored it via dd. (The partition Warning! went away as soon as 5 was deleted and did not reappear when it was recreated at a new start sector.)

I failed to grab a snapshot of the final partition table entries but I basically shortened 4 by a couple GiB (and didn't try to "nail" it to exactly 33 blocks shorter.)

Once the GPT table had a functioning secondary GPT, the Ubuntu installer was able to find it without problems. I just used gdisk to make the D partition into a Linux format partition (8300). (There was nothing on the D drive.) The installer did create a GRUB entry for the Win 7 but that doesn't really work. However, using ESC, I can select the Windows partition from the UEFI boot menu and it dual boots just fine. After the installation was done, I upgraded from the Precise install release bits to the latest bits (including newer kernel) and the grub update worked fine as well--so it seems to be a rock solid dual boot machine now.

Holler if this helps you or if you know more about why ASUS formats the disk this way--there could be an underlying reasons. Oh, and one more thing, I actually did make the Win 7 recovery disks PRIOR to doing any Ubuntu at all and I've not tried to do anything since with the recovery partition.

You can reach me via the comments below or email me at asus DOT dowdberry AT medberry DOT net.

And some final words: Ubuntu Live Installer makes an awesome detective kit and this Ivy Bridge notebook truly rocks.

Colin Ian King

Does your UEFI firmware have CSM support or not?

November 7, 2011

by Colin Ian King

Under bios , csm , tools , uefi

UEFI Compatibility Support Module (CSM) provides compatibility support for traditional legacy BIOS. This allows allows the booting an operating system that requires a traditional option ROM support, such as BIOS Int 10h video calls.

While looking at boot and runtime misbehaviour on UEFI systems I would like to know if CSM is enabled or not, but the question is how does one detect CSM support? Well, making the assumption that CSM is generally enabled to support Int 10h video calls, we look for any video option ROMs and see if the real mode Int 10h vector is set to jump to a handler in one of the ROMs.

Option ROMs are found in the region 0xc0000 to 0xe0000 and normally the video option ROM is found at 0xc0000. Option ROMs are found on 512 byte boundaries with a header bytes containing 0x55, 0xaa and ROM length (divided by 512) so we just mmap in 0xc0000..xe0000 and then scan the memory for headers to locate option ROM images.

My assumption for CSM being enabled is that Int 10h vectors into one of these option ROMs, and we can assume it is a video option ROM if it contains the string "VGA" somewhere in the ROM image. Yes, it is a hack, but it seems to work on the range of UEFI enabled systems I've so far used.

For reference, I've put the code in my debug-code git repository and available for anyone to use.

Colin Ian King

UEFI Secure Boot and Linux

October 28, 2011

by Colin Ian King

Under uefi

There has been a lot of (heated) discussion in the past weeks concerning UEFI Secure Boot and how this can impact on the ability of a user to install their operating system of choice.

To address this, today has seen no less than two papers published to address this hot topic. Canonical along with Red Hat have published a white paper that describes how UEFI Secure Boot will impact users and manufactures. The paper also provides recommendations on the implementation of UEFI Secure Boot in way that allows users to be in control of their own PC hardware.

Meanwhile the Linux Foundation has also published a paper giving technical guidance on how to implement UEFI Secure Boot to allow operating systems other than Windows 8 to operate on new Windows 8 PCs.

So lots to read and good technical guidance all round. Let's hope that these constructive set of papers will push the argument into a positive outcome.

Colin Ian King

UEFI EDK II Revisited

October 20, 2011

by Colin Ian King

Under fwts , qemu , uefi

My colleague Manoj Iyer has written up a guide on how to download EDK II and build the UEFI firmware for QEMU. This requires older versions of gcc found in Natty (since the newer Oneiric version is more pedantic and uses -Werror=unused-but-set-variable by default).

With a chroot I was able get it downloaded, built and tested in less than 40 minutes. Here is a sample UEFI helloworld application running in QEMU using the firmware using Manoj's instructions.

Now I can rig up some tests to exercise Ubuntu and the Firmware Test Suite without the need for any real UEFI hardware..

Colin Ian King

Dumping UEFI variables

August 31, 2011

by Colin Ian King

Under firmware , fwts , tools , uefi

UEFI variables in Linux can be found in /sys/firmware/efi/vars on UEFI firmware based machine, however, the raw variable data is in a binary format and hence not in a human readable form. The Ubuntu Natty firmware test suite contains the uefidump tool to extract and decode the binary data into a more human readable form.

To run, use:

sudo fwts uefidump -

and you will see something similar to the following:

Name: AuthVarKeyDatabase.
GUID: aaf32c78-947b-439a-a180-2e144ec37792
Attr: 0x17 (NonVolatile,BootServ,RunTime).
Size: 1 bytes of data.
Data: 0000: 00 .

Name: Boot0000.
GUID: 8be4df61-93ca-11d2-aa0d-00e098032b8c
Attr: 0x7 (NonVolatile,BootServ,RunTime).
Active: Yes
Info: Primary Master Harddisk
Path: \BIOS(2,0,Primary Master Harddisk).

Name: Boot0001.
GUID: 8be4df61-93ca-11d2-aa0d-00e098032b8c
Attr: 0x7 (NonVolatile,BootServ,RunTime).
Active: Yes
Info: EFI Internal Shell
Path: \Unknown-MEDIA-DEV-PATH(0x7)\Unknown-MEDIA-DEV-PATH(0x6).

Name: Boot0003.
GUID: 8be4df61-93ca-11d2-aa0d-00e098032b8c
Attr: 0x7 (NonVolatile,BootServ,RunTime).
Active: Yes
Info: ubuntu
Path: \HARDDRIVE(1,22,9897,0f52a6e132775546,ab,f6)\FILE('\EFI\ubuntu\grubx64.efi').

Name: Boot0004.
GUID: 8be4df61-93ca-11d2-aa0d-00e098032b8c
Attr: 0x7 (NonVolatile,BootServ,RunTime).
Active: Yes
Info: EFI DVD/CDROM
Path: \ACPI(0xa0341d0,0x0)\PCI(0x2,0x1f)\ATAPI(0x0,0x1,0x0).

Name: BootOptionSupport.
GUID: 8be4df61-93ca-11d2-aa0d-00e098032b8c
Attr: 0x6 (BootServ,RunTime).
BootOptionSupport: 0x0303.

Name: BootOrder.
GUID: 8be4df61-93ca-11d2-aa0d-00e098032b8c
Attr: 0x7 (NonVolatile,BootServ,RunTime).
Boot Order: 0x0003,0x0000,0x0001,0x0004,0x0005,0x0006.

Name: ConIn.
GUID: 8be4df61-93ca-11d2-aa0d-00e098032b8c
Attr: 0x7 (NonVolatile,BootServ,RunTime).
Device Path: \ACPI(0xa0341d0,0x0)\PCI(0x0,0x1f)\ACPI(0x50141d0,0x0)\UART(115200 baud,8,1,1)\VENDOR(11d2f9be-0c9a-9000-273f-c14d7f010400)\USBCLASS(0xffff,0xffff,0x3,0x1,0x1).

Name: ConInDev.
GUID: 8be4df61-93ca-11d2-aa0d-00e098032b8c
Attr: 0x6 (BootServ,RunTime).
Device Path: \ACPI(0xa0341d0,0x0)\PCI(0x0,0x1f)\ACPI(0x50141d0,0x0)\UART(115200 baud,8,1,1)\VENDOR(11d2f9be-0c9a-9000-273f-c14d7fff0400).

Name: Setup.
GUID: 038bcef0-21e2-49d1-a47c-b7257296b980
Attr: 0x7 (NonVolatile,BootServ,RunTime).
Size: 114 bytes of data.
Data: 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Data: 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Data: 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Data: 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Data: 0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Data: 0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Data: 0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Data: 0070: 01 00
..

The tool will try to decode the binary data, however, if it cannot identify the variable type it will resort to doing a hex dump of the data instead.

Colin Ian King

GNU EFI lib and Hello World

June 6, 2011

by Colin Ian King

Under firmware , testing , uefi

Writing UEFI applications takes a little bit of effort to get started, fortunately the GNU EFI library provides enough infrastructure to make it far less painful. The crunch points are:

1. Understanding which UEFI protocols to use, fortunately these are well documented in the UEFI specification. Unfortunately the specification is a couple of thousand pages long, so be prepared to spend some time working out how it all hangs together.

2. Figuring out how to call the protocols using the GNU EFI wrapper shim.

3. Generating a UEFI PE COFF image using some objcopy runes.

So, the best way to start was to write a "Hello World" program and to work up from there. First, I installed the gnu-efi development library using:

sudo apt-get install gnu-efi

Next I hacked up the classic "Hello World", this can be found here. Then considerable amount of Googling was required to figure out how to use objcopy to help create the desired executable image. The Makefile containing these runes can be found here.

So what next? Well, this little adventure is my first step in a quest to write a bunch of tests so ensure UEFI firmware has functional protocols to allow grub to load a kernel. I was hoping to re-use the firmware test suite framework but it may take some effort since I don't have any POSIX support on UEFI, so I'm going to have to scope out how much effort is required to port the framework to UEFI.

Anyhow, it's a start.

Colin Ian King

Firmware Test Suite for Ubuntu 11.04

February 26, 2011

by Colin Ian King

Under acpi , bios , firmware , uefi

The Firmware Test Suite (fwts) is a tool I've been working on over the past few months that does automated testing of PC firmware. The main aim is to check for errors in BIOS code and ACPI tables. I have put most effort into ACPI testing as my analysis shows that it constitutes over 90% of firmware related errors reported against the kernel in LaunchPad.

Most of the key features for Ubuntu 11.04 are now in the Firmware Test Suite, so now seems an appropriate time to mention them.

Automated ACPI Method Testing.

The ACPI DSDT and SSDT tables contain ACPI Machine Language (AML) bytecode. This code is executed by the Linux kernel by the ACPI driver and is an abstract interface between the operating system and the underlying machine hardware, such as the embedded controller, the closed proprietary BIOS and various hardware registers. The AML can describe hardware layout and contains methods that operate in a manner that should conform to the ACPI specification. For example, there are methods to handle power management, thermal control, battery status and much more besides. The main problem we face is when these implementations are buggy and may not conform to the specification. The kernel can execute the AML code and so if the AML is broken you may get a machine that does not work correctly.

I've added a method test to fwts that will extract the AML byte code from the DSDT and then using the ACPICA execution engine run these in user space and check methods are returning the expected return types and in some cases (where appropriate) check expected return values. Over 70 standard methods described in version 4.0a of the ACPI specification are sanity checked. The code also checks mutex acquire/release counts to see if methods are incorrectly not releasing locks.

To run these test using 11.04 fwts, use:

sudo fwts method

..and the results are appended to the file results.log. (One has to use sudo to be able to read the ACPI tables).

Another way to sanity check the AML code is to extract it, dis-assemble and then re-assemble it using the ACPICA iasl compiler. A lot of AML is compiled using the Microsoft AML compiler and this appears to be less strict. Hence, recompiling with a more strict compiler can pick up errors. The syntaxcheck test existed in fwts for Ubuntu 10.10, but I've re-worked this by integrating in the ACPICA core into the tool and then enhancing the error reporting. For most error messages produced by the compiler fwts now also outputs 8 lines of disassembled code around the error (to provide context) and also outputs extra feedback advice. This advice is based on looking at all the reasons why this error can be emitted by the compiler and explaining these with more context.

To run this test, use:

sudo fwts syntaxcheck

..again, output is appended to results.log

Since the ACPICA core is integrated in, we can also use this to easily dump out the disassembled AML byte code from all the ACPI tables. To do so use:

sudo fwts --disassemble-aml

and the AML code for each table is dumped into files DSDT.dsl and SSDTn.dsl (where n is the Nth SSDT). This is much easier than running acpixtract, acpidump and the iasl -d on the DSDT and SSDT tables.

The final ACPI table test added to fwts in Ubuntu 11.04 performs about 40 sanity checks on configuration data in common ACPI tables. To run this test use:

sudo fwts acpitables

..and this checks various configurations, e.g. of HPET, SCI interrupt, GPE blocks, reset register + reset values, APIC flags, etc.

Although it's strictly not a test, fwts now includes a tool that will dump out the ACPI tables in an annotated form so that one can examine the configuration settings in a more human readable form than just looking at the raw data in a hex editor. To do use:

sudo fwts acpidump

UEFI

The Firmware Test Suite also needs to work on UEFI firmware based machines which are now becoming far more common. I've re-worked some of the underlying code in fwts to work with UEFI and standard BIOS. My next step is to extend fwts to add in more UEFI only tests, but this is still "work-in-progress".

Other goodness

As it is an evolving tool, fwts includes a lot more refinements (and bug fixes) compared the first cut that came out in Ubuntu 10.10. The log format to be less verbose and there is the new "-" option that dumps the log straight to stdout rather than appending it to a log file.

To see all the tests built into fwts, you can use the "--show-tests-full" option, rather than the more terse option "--show-tests".

Originally fwts ran silently and this caused some confusion as it was not obvious what was happening. For Ubuntu 11.04 fwts now runs in verbose mode and reports a brief per test progress information. The silent mode can be enabled using the "-q" or "--quiet" options.

One can also run the tool on dumped ACPI tables from other machines allowing to remotely diagnose bugs just from raw table data. Dump the tables using:

sudo fwts --dump

..this produces a dump of kernel log, dmidecode, lspci and the ACPI tables. One can read in the ACPI tables into fwts and run appropriate ACPI specific tests on this data, e.g.

fwts --dumpfile=acpidump.log syntaxcheck method acpitables

There are many more refinements and minor new features. I recommend reading the manual page to get more familiar with the tool.

To install fwts in Ubuntu 11.04 use:

sudo apt-get install fwts

Enjoy!

[ Update ]

I've written a fwts reference guide, available here: https://wiki.ubuntu.com/Kernel/Reference/fwts

Canonical

Canonical Voices

What cool people talk about

Posts tagged with 'uefi'

Firmware Test Suite New Features in Ubuntu Raring 13.04

sbkeysync & maintaing uefi key databases

An example key setup

generating keys

generating key updates

creating a keystore

using `sbkeysync`

signing a bootloader

reverting to setup mode

secure boot tools resources

Ubuntu ODM portal

YAHTNG

Does your UEFI firmware have CSM support or not?

UEFI Secure Boot and Linux

UEFI EDK II Revisited

Dumping UEFI variables

GNU EFI lib and Hello World

Firmware Test Suite for Ubuntu 11.04

Latest Official Posts

Featured Blogs

People