Month: April 2016

Android Nexus 5 Monitor Mode

~ hucktech ~ Leave a comment

Vincent recently tweeted this pointer to a blog from Frédéric Basse, talking about Android Nexus 5’s Monitor Mode:

Analysis of Nexus 5 Monitor mode
This article will first describe how to locate the Monitor mode code in Nexus 5 firmware (hammerhead-ktu84p-factory-35ea0277, bootloader-hammerhead-hhz11k : c32f8bec310c659c1296739b00c6a8ac). Then, we will try to understand what it does (its functionalities). Finally, you will have to find bugs by yourself because I didn’t find any…so far !
[…]

Full article:
http://www.fredericb.info/2014/12/analysis-of-nexus-5-monitor-mode.html?spref=tw

ARM Security Extensions

~ hucktech ~ Leave a comment

There’s a new blog post on the ARM blog, talking about Security Extensions and Privilege Levels in ARMv8-M Cortex systems:

Security Extensions and Privilege Levels
[…]
ARMv8-M introduces Security Extensions that provide hardware features for more secure devices. The Security Extensions allow the protection of trusted and system resources from untrusted handlers and applications. They can be executed without the additional software sandboxing overheads of reprogramming the MPU.  The Security Extensions collaborates with the associated software model to provide a mechanism to restrict access to system resources and processes through well-defined interfaces similar to system calls, thereby ensuring a higher level of protection and also offering an implicit privilege-stack. […]

https://community.arm.com/groups/processors/blog/2016/03/21/security-extensions-and-privilege-levels?et=blogs.comment.created#comment-19571

LUV 2.0 released!

~ hucktech ~ Leave a comment

The Intel LUV team, at least including: Gayatri Kammela (12), Megha Dey (12), Naresh Bhat (1), and Ricardo Neri (46) have released 2.0 of LUV, the Linux UEFI Validation Project.

These are the highlights of the release:

*Different types of image available (i386 and x86_x64)
*Logging and debugging via network (or serial)
*Tests for persistent memory (NVDIMM)
*Support for i386
*Booting LUV via network (PXE, HTTP boot later)
*Miscellaneous updates (BITS perf improvements, Linux 4.4 kernel, …)
*Dropped support for fido (focus is on Jethro)
*Known issues and limitations (Debugging works only over Ethernet, not WiFi, …)

Read the full announcement, there are pages of details not included here.

One new feature is i386 support. LUV 1.x was x64-centric, now we hopefully also use LUV 2.0 for testing x86 systems! But signed shim is still only available for 64-bit, so Secure Boot is not enabled for 32-bit support [yet?]. Quoting the release notes:  “At the last minute we faced a kernel issue when booting on a i386-based system. We are debugging. Once this is cleared, a bootable image will be uploaded (issue #76 on [3])”

Full announcement:
https://lists.01.org/pipermail/luv/2016-April/001035.html
https://download.01.org/linux-uefi-validation/v2.0
https://download.01.org/linux-uefi-validation/v2.0/sha256_sums.asc
[1]. https://github.com/01org/luv-yocto/tree/master/meta-luv
[2]. https://github.com/pmem/ndctl
[3]. https://github.com/01org/luv-yocto

TPM2 ACPI table

~ hucktech ~ Leave a comment

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

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

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

Xen patches for AMD FIP/FCS/FDP/FDS/FOP instruction leak

~ hucktech ~ Leave a comment

The Xen security team posted an updated security advisory with a workaround to an AMD CPU issue. Heavily-edited announcement follows, see the OSS-security list post for the full announcement and patches:

Xen Security Advisory CVE-2016-3158,CVE-2016-3159 / XSA-172
version 3
broken AMD FPU FIP/FDP/FOP leak workaround

There is a workaround in Xen to deal with the fact that AMD CPUs don’t load the x86 registers FIP (and possibly FCS), FDP (and possibly FDS), and FOP from memory (via XRSTOR or FXRSTOR) when there is no pending unmasked exception.  (See XSA-52.) However, this workaround does not cover all possible input cases. This is because writes to the hardware FSW.ES bit, which the current workaround is based on, are ignored; instead, the CPU calculates FSW.ES from the pending exception and exception mask bits.  Xen therefore needs to do the same. Note that part of said workaround was the subject of XSA-52. This can leak register contents from one guest to another.  The registers in question are the FPU instruction and data pointers and opcode.

A malicious domain is able to obtain address space usage and timing information, about another domain, at a fairly low rate. The leaked address information might be used to help defeat address space randomisation in order to enable another attack.  The leaked address and timing information forms a low-bandwidth covert channel which might be used to gain information about the operation of a target guest. The affected FPU facility would not normally be used by cryptographic operations, as it does not provide cryptographically-relevant SIMD functions. It appears to us very unlikely that the leak might directly compromise sensitive information such as cryptographic keys, although (without knowledge of the guest software) this cannot be ruled out.  (This is notwithstanding the contrary statement in `Impact’ in XSA-52.)

Xen versions 4.0 and onwards are vulnerable.  Any kind of guest can exploit the vulnerability. The vulnerability is exposed only on AMD x86 systems.  Intel and ARM systems do not expose this vulnerability. Both PV and HVM guests are affected. The vulnerability can be avoided if the guest kernel is controlled by the host rather than guest administrator, provided that further steps are taken to prevent the guest administrator from loading code into the kernel (e.g. by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. On Xen versions 4.3 and earlier, turning off XSAVE support via the “no-xsave” hypervisor command line option will avoid the vulnerability. On Xen versions 4.4 and onwards there is no other known mitigation.

This issue was discovered by Jan Beulich from SUSE.

http://xenbits.xen.org/xsa/advisory-172.html
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2016-3159
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3158

 

UEFI Forum Spring plugfest presentations uploaded

~ hucktech ~ Leave a comment

The UEFI Forum is concluding their Spring plugfest in Taipei. They’ve uploaded the 8 presentations to uefi.org:

    UEFI Forum Update – Dong Wei (HPE)
    UEFI Forum ARM Update – Mitch Ishihara (ARM)
    Improving Platform Security with UEFI Secure Boot and UEFI Variables – David Chen (Insyde Software)
    The TPM 2.0 specs are here, now what? – Dick Wilkins (Phoenix Technologies)
    Standardized Firmware for ARMv8 based Volume Servers – Jonathan Zhang (Cavium Inc.) and Robert Hsu (AMI)
    Microsoft Update for Windows Security – Jackie Chang, Tony Lin (Microsoft Corporation)
    UEFI Port to RISC-V Processor Architecture – Abner Chang (HPE)
    Tianocore 2016 Updates – Tony Mangefeste (Intel)

http://uefi.org/learning_center/presentationsandvideos

and look for the videos to start showing up here:
https://www.youtube.com/user/UEFIForum

Debian plans for UEFI Secure Boot

~ hucktech ~ Leave a comment

Steve McIntyre of the Debian Project posted a message to the Debian-EFI list, with plans for getting Debian to support UEFI Secure Boot. A summary of the main steps:

1. Generate a key and an EV code-signing cert, submit to Microsoft
2. dak changes to support upload and signing of EFI executables
3. Prepare and upload a package of the ‘shim’ EFI boot loader
4. Updates for other core packages to add signed versions
 * grub2
 * linux
 * fwupdate
 * ???
5. Minor tweaks to other places to make use of the signed packages
 * d-i
 * debian-cd
 * debian-live
 * ???

Full status message and more information:
https://wiki.debian.org/SecureBoot
https://lists.debian.org/debian-efi/2016/04/msg00002.html

Intel patch to Linux kernel for ACPI overlays

~ hucktech ~ Leave a comment

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

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

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

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

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

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