Uncategorized

Microsoft updates Secure Boot and ACPI requirements

These Microsoft pages have recently (last month) been updated. No changelog, so unclear what has changed. 😦

 

https://msdn.microsoft.com/en-us/windows/hardware/drivers/bringup/secure-boot-and-device-encryption-overview

https://msdn.microsoft.com/en-us/windows/hardware/commercialize/design/device-experiences/acpi-firmware-implementation-requirements

https://msdn.microsoft.com/en-us/windows/hardware/drivers/bringup/firmware-requirements-for-d3cold

 

Standard
Uncategorized

ACPI graph support

Sakari Ailus of Intel posted a patch to the Linux-ACPI list that enables ‘ACPI graph support’. Slightly edited version of announcement below:

I posted a previous RFC labelled set of ACPI graph support a while ago[1]. Since then, the matter of how the properties should be used as in ACPI _DSD was discussed in Ksummit and LPC, and a document detailing the rules  was written [1]. I’ve additionally posted v1 which can be found here[2]. This set contains patches written by Mika Westerberg and by myself. The patchset brings support for graphs to ACPI. The functionality achieved by these patches is very similar to what the Device tree provides: the port and the endpoint concept are being employed. The patches make use of the _DSD property and data extensions to achieve this. The fwnode interface is extended by graph functionality; this way graph information originating from both OF and ACPI may be accessed using the same interface, without being aware of the underlying firmware interface. The last patch of the set contains ASL documentation including an example. The entire set may also be found here (on mediatree.git master, but it also applies cleanly on linux-next)[3]. The resulting fwnode graph interface has been tested using V4L2 async with fwnode matching and smiapp and omap3isp drivers, with appropriate changes to make use of the fwnode interface in drivers. The V4L2 patches can be found here. The fwnode graph interface is used by the newly added V4L2 fwnode framework which replaces the V4L2 OF framework, with equivalent functionality.[4]

[1] http://www.spinics.net/lists/linux-acpi/msg69547.html
[2] http://www.spinics.net/lists/linux-acpi/msg71661.html
[3] https://git.linuxtv.org/sailus/media_tree.git/log/?h=acpi-graph
[4] https://git.linuxtv.org/sailus/media_tree.git/log/?h=v4l2-acpi

Full announcement — including changes for v1 — is on the linux-acpi list:
http://vger.kernel.org/majordomo-info.html
http://www.spinics.net/lists/linux-acpi/

Standard
Uncategorized

faking virtual firmware to thwart malware authors

Thomas Roccia write a new blog post on watching how malware detects VM’s virtualized hardware/firmware resources, including a defensive POC and a pointer to a similar tool.

Stopping Malware With a Fake Virtual Machine
As we explained in a previous post, some advanced malware can detect a virtual environment such as a sandbox to avoid detection and analysis. Some threats can also detect monitoring tools used for malware analysis. Often such malware will not execute or change their behavior to appear harmless. Because some malware uses these tactics, planting fake virtual machine artefacts or fake analysis tools on a system could stop their malicious behavior. We have created a quick proof of concept (POC) to demonstrate this defensive tactic. […] A lot of registry keys are created by specific tools or by sandbox emulation. Using the Windows API RegCreateKeyEx we can create all the (fake) keys normally created by a virtual hypervisor. The following list shows of few of the potential registry keys that malware can detect:
    HKLM\HARDWARE\DEVICEMAP\Scsi\Scsi Port 0\Scsi Bus 0\Target Id 0\Logical Unit Id 0\“Identifier”;“VMWARE”
    HKLM\SOFTWARE\VMware, Inc.\VMware Tools
    HKLM\HARDWARE\Description\System\ “SystemBiosVersion”;”VMWARE”
    HKLM\HARDWARE\Description\System\”SystemBiosVersion”;VBOX
    HKLM\SOFTWARE\Oracle\VirtualBox Guest Additions
    HKLM\HARDWARE\ACPI\DSDT\VBOX__

https://securingtomorrow.mcafee.com/mcafee-labs/stopping-malware-fake-virtual-machine/

https://github.com/fr0gger/RocProtect-V1

 

 

Standard
Uncategorized

AMI announces UEFI 2.6 and ACPI 6.1 support

AMI announced that their UEFI implementation, Aptio V, supports UEFI 2.6 and ACPI 6.1

American Megatrends Announces Aptio V Compliance with UEFI 2.6 and ACPI v6.1

AMI is proud to announce Aptio® V support and compliance for UEFI 2.6 and ACPI v6.1 specifications. As a leader in the BIOS/UEFI firmware industry and board member in the UEFI community, AMI keeps up with the latest upgrades and specifications to better serve its customers in the technology industry. Aptio® V, AMI’s flagship UEFI firmware, is developed according to UEFI specifications and the added support for UEFI 2.6 and ACPI v6.1 gives manufacturers the ability to enhance select platforms based on the latest UEFI specifications. The newest specifications, announced this past March, keeps up with the increasing expectations of the market, providing OEMs and ODMs greater manageability across various user systems and creating more expansive support for newer platforms and designs. By integrating and expanding support for UEFI 2.6 and ACPI v6.1 on its core UEFI firmware, Aptio V, AMI standardizes operating systems booting and optimizes pre-boot applications for its customers.

Full PR:

https://ami.com/news/press-releases/?PressReleaseID=373

 

Standard
Uncategorized

FWTS 17.01.00 released

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

New Features:
* ACPICA: Update to version 20161222
* klog.json: Add kernel errors to the database
* fedora/fwts.spec: Add initial version of fwts.spec
* fedora/buildrpm.sh: Add build script for RPMs

See the full announcement for more details:
http://fwts.ubuntu.com/release/fwts-V17.01.00.tar.gz
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/17.01.00
https://launchpad.net/ubuntu/+source/fwts

Standard
Uncategorized

Yuriy and Oleksandr at REcon

Baring the system: New vulnerabilities in SMM of Coreboot and UEFI based systems
By: Yuriy Bulygin, Oleksandr Bazhaniuk

Previously, we discovered a number of vulnerabilities in UEFI based firmware including software vulnerabilities in SMI handlers that could lead to SMM code execution, attacks on hypervisors like Xen, Hyper-V and bypassing modern security protections in Windows 10 such as Virtual Secure Mode with Credential and Device Guard. These issues led to changes in the way OS communicates with SMM on UEFI based systems and new Windows SMM Security Mitigations ACPI Table (WSMT). This research describes an entirely new class of vulnerabilities affecting SMI handlers on systems with Coreboot and UEFI based firmware. These issues are caused by incorrect trust assumptions between the firmware and underlying hardware which makes them applicable to any type of system firmware. We will describe impact and various mitigation techniques. We will also release a module for open source CHIPSEC framework to automatically detect this type of issues on a running system.

https://recon.cx/2017/brussels/talks/baring_the_system.html

https://firmwaresecurity.com/2017/01/05/yuriy-to-speak-at-recon-brussels/

 

 

Standard