OpenCIT 2.2 released

Adolfo V Aguayo of Intel announced the version 2.2 release of OpenCIT.

New Features in 2.2:
– TPM 2.0 support.
   + Added support for platform and asset tag attestation of Linux and Windows hosts with TPM 2.0.
   + Support attestation of either SHA1 or SHA256 PCR banks on TPM 2.0.
   + Ubuntu 16.04 and RHEL 7.2, 7.3 (SHA1 and SHA256), Windows Server 2012 and Hyper-V Server 2012 (SHA1) are supported with TPM 2.0
– All the certificates and hashing algorithms used in CIT are upgraded to use SHA256.  SHA1 has been deprecated and will no longer be used.
– CIT Attestation Service UI has been updated to allow the user to select either the SHA1 or SHA256 PCR bank for Attestation of TPM 2.0 hosts.
    + The CIT  Attestation Service will automatically choose the strongest available algorithm for attestation (SHA1 for TPM 1.2, and SHA256 for TPM 2.0)
– CIT Attestation Service UI Whitelist tab no longer requires the user to select PCRs when whitelisting, and will automatically choose the PCRs to use based on the host OS and TPM version.  This is done to reduce confusion due to differing behaviors between TPM 1.2 and TPM 2.0 PCR usages.
– Additional changes made to support TPM 2.0:
    + Linux hosts with TPM 2.0 will now utilize TPM2.0-TSS (TPM 2.0 Software Stack) and TPM2.0-tools instead of the legacy trousers and tpm-tools packages. The new TSS2 and TPM2.0-tools are packaged with the CIT Trust Agent installer.
    + TPM 2.0 Windows hosts use TSS.MSR (The TPM Software Stack from Microsoft Research) PCPTool.
    + TPM 1.2 hosts will continue to use the legacy TSS stack (trousers) and tpm-tools components.

For more information, see the full announcement on the oat-devel@lists.01.org mailing list.

https://github.com/opencit
https://01.org/opencit

FWTS 16.011.00 released

Ivan Hu of Canonical announced the 16.011.00 release of FWTS, the FirmWare Test Suite.

New Features include:
 * ACPICA: Update to version 20160930
 * uefibootpath: add test for eMMC device path
 * uefidump: add dumping for the eMMC device path

There are lots of bugfixes as well, see the Changelog.

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

Dirty COW Linux security issue

From the OSS-Security list, some details on a new “Dirty COW” Linux security issue:

CVE-2016-5195 “Dirty COW” Linux kernel privilege escalation vulnerability

This was brought to the linux-distros list (and briefly inadvertently to the distros list, although discussion continued on linux-distros only) on October 13 and it was made public yesterday, so it must be in here as well.  Unfortunately, no one posted about it in here so far (the person who brought this to [linux-]distros must have done so!), and I don’t have time to make a proper posting (with full detail in the message itself, as per oss-security list content guidelines), but I figured it’s better for me to post something than nothing at all.

Red Hat’s description:

“A race condition was found in the way the Linux kernel’s memory subsystem handled the copy-on-write (COW) breakage of private read-only memory mappings.  An unprivileged local user could use this flaw to gain write access to otherwise read-only memory mappings and thus increase their privileges on the system.”

https://access.redhat.com/security/cve/cve-2016-5195
https://bugzilla.redhat.com/show_bug.cgi?id=1384344
https://security-tracker.debian.org/tracker/CVE-2016-5195
http://www.v3.co.uk/v3-uk/news/2474845/linux-users-urged-to-protect-against-dirty-cow-security-flaw
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619
https://lkml.org/lkml/2016/10/19/860
https://dirtycow.ninja
https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails

https://www.us-cert.gov/ncas/current-activity/2016/10/21/Linux-Kernel-Vulnerability

Matthew Garrett on Linux boot security

Amber Ankerholz wrote an article for Linux.com on the Linux boot-time security presentation that Matthew Garrett recently gave at the Linux Security Summit. In addition to the article, the video of the presentation is also available.

https://www.linux.com/news/matthew-garrett-explains-how-increase-security-boot-time

 

EFI changes for Linux v4.9

Matt Fleming sent a message to Linux Kernel/EFI lists with a set of UEFI-centric patches for Linux 4.9. Excerpting his message:

[…]There’s more work on refactoring EFI code to be architecture independent and the largest number of patches is spent cleaning up the EFI memory map code and allowing drivers on x86 to reserve EFI boot services for all of runtime. The architecture independent quest is going pretty well and it was only a couple of lines to get the esrt driver working on arm64. Other than that there’s some cleanups and fixes, and a merge of the out of tree EFI runtime driver from the FWTS project.

 * Refactor the EFI memory map code into architecture neutral files and allow drivers to permanently reserve EFI boot services regions on x86, as well as ARM/arm64 – Matt Fleming
 * Add ARM support for the EFI esrt driver – Ard Biesheuvel
 * Make the EFI runtime services and efivar API interruptible by swapping spinlocks for semaphores – Sylvain Chouleur
 * Provide the EFI identity mapping for kexec which allows kexec to work on SGI/UV platforms with requiring the “noefi” kernel command line parameter – Alex Thorlton
 * Add debugfs node to dump EFI page tables on arm64 – Ard Biesheuvel
 * Merge the EFI test driver being carried out of tree until now in the FWTS project – Ivan Hu
 * Expand the list of flags for classifying EFI regions as “RAM” on arm64 so we align with the UEFI spec – Ard Biesheuvel
 * Optimise out the EFI mixed mode if it’s unsupported (CONFIG_X86_32) or disabled (CONFIG_EFI_MIXED=n) and switch the early EFI boot services function table for direct calls, alleviating us from having to maintain the custom function table – Lukas Wunner
 * Miscellaneous cleanups and fixes
[…]

git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git tags/efi-next

_DSD Guidance updated

Re: this previous post:

Guidance on using ACPI _DSD with Linux

Al Stone of Red Hat published an updated version of 3 documents giving guidance on using _DSD ACPI:

[RFC DSD v3 00/04] How to Use the ACPI _DSD Device Properties UUIDs

A copy of the ChangeLog is also attached so that you can see what the primary changes were for this second version.

https://github.com/ahs3/dsd/tree/master/documentation

https://github.com/ahs3/dsd/commit/7fbdce494b9b7b952e709e43b8dbbfd5cf8d4fcb
https://github.com/ahs3/dsd/commits/master

Click to access _DSD-device-properties-UUID.pdf

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

cryptboot

Interesting new project. I wish most modern Linux distros let you control keys in ways like this. Check out the entire web page on Github, nice read for Linux/UEFI even if you don’t plan on using cryptboot.

https://github.com/xmikos/cryptboot

Encrypted boot partition manager with UEFI Secure Boot support

With encrypted boot partition, nobody can see or modify your kernel image or initramfs. GRUB boot loader supports booting from encrypted boot partition, but you would be still vulnerable to Evil Maid attacks. One possible solution is to use UEFI Secure Boot. Get rid of preloaded Secure Boot keys (you really don’t want to trust Microsoft and OEM), enroll your own Secure Boot keys and sign GRUB boot loader with your keys. Evil maid would be unable to boot modified boot loader (not signed by your keys) and whole attack is prevented. cryptboot simply makes this easy and manageable.

Requirements
* Linux (x86_64)
* UEFI firmware with enabled Secure Boot
* separate /boot partition encrypted with LUKS
* cryptsetup
* openssl
* efitools
* sbsigntools
* efibootmgr
* grub (grub-efi on Debian based distributions)

[…]

And this article points out something else crazy: “but current TrustedGRUB2 doesn’t even support UEFI yet.

Steven Ellis: firmware updating on Linux

Steven Ellis of Red Hat has a new article on OpenSource.com on updating firmware and UEFI, with lots of good stuff to read. He mentions his next article will be on the topic of patching SSD firmware, which sounds very interesting. Spoiler alert: I’m exerpting his Recommendations from the end of the post:

[…] In this article, I’ll walk through my recent firmware update on Linux, and I’ll share a few recommendations based on that experience. […]
Recommendations:
* More vendors should allow UEFI BIOS updates directly from the BIOS-style interface. UEFI shell command-line isn’t for the casual user.
* If your vendor supplies a bootable image, try to use that first.
* Investigate what supported tools are available, but consider using a live image for patching. I’m somewhat wary of tools that build and install their own kernel modules.
* Assist projects—like flashrom—to avoid these issues in the future.
[…]

https://opensource.com/life/16/8/almost-open-bios-and-firmware-update-tips-linux-users

Cook on status of Linux’s Kernel Self Protection Project

A few days ago at the Linux Security Summit (LSS), Kees Cook of the Chromium project gave a presentation about the current status of the Kernel Self-Protection Project. Slides are available, I’m not sure about any A/V archives.

Status of the Kernel Self Protection Project
Linux Security Summit 2016

Click to access kspp.pdf

Kernel Self Protection Project
http://www.openwall.com/lists/kernel-hardening/
http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project

Microsoft OMI: WMI for Linux

WMI, the Windows-centric API wrapper the DMTF CIM standard, has an OMI variant that works outside of Windows. I don’t understand why Microsoft didn’t just submit OMI to DMTF, instead of OpenGroup… 🙂

https://twitter.com/mattifestation/status/768445468925829120

Open Management Infrastructure (OMI) is an open source project to further the development of a production quality implementation of the DMTF CIM/WBEM standards. The OMI CIMOM is also designed to be portable and highly modular. In order to attain its small footprint, it is coded in C, which also makes it a much more viable CIM Object Manager for embedded systems and other infrastructure components that have memory constraints for their management processor. OMI is also designed to be inherently portable. It builds and runs today on most UNIX® systems and Linux. In addition to OMI’s small footprint, it also demonstrates very high performance. RPM and DEB packages are provided for the installation of OMI on most enterprise Linux distributions. To install OMI, download the correct package for your Linux computer. […]

https://github.com/Microsoft/omi

http://www.opengroup.org/software/omi

https://blogs.technet.microsoft.com/windowsserver/2012/06/28/open-management-infrastructure/

AMD Secure Encrypted Virtualization (SEV) patch for Linux kernel

Brijesh Singh of AMD submitted a 28-part patch to the Linux-(kernel,efi,kvm,…) mailing lists, with a patch for the the Linux kernel to support AMD’s Secure Encrypted Virtualization (SEV), which relies on the recent AMD Secure Memory Encryption (SME) patch by Tom Lendacky of AMD. I’m excerpting the intro text from part 1/28:

[RFC PATCH v1 00/28] x86: Secure Encrypted Virtualization (AMD)

This RFC series provides support for AMD’s new Secure Encrypted Virtualization (SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFC.

SEV is an extension to the AMD-V architecture which supports running multiple VMs under the control of a hypervisor. When enabled, SEV hardware tags all code and data with its VM ASID which indicates which VM the data originated from or is intended for. This tag is kept with the data at all times when inside the SOC, and prevents that data from being used by anyone other than the owner. While the tag protects VM data inside the SOC, AES with 128 bit encryption protects data outside the SOC. When data leaves or enters the SOC, it is encrypted/decrypted respectively by hardware with a key based on the associated tag.

SEV guest VMs have the concept of private and shared memory.  Private memory is encrypted with the  guest-specific key, while shared memory may be encrypted with hypervisor key.  Certain types of memory (namely instruction pages and guest page tables) are always treated as private memory by the hardware. For data memory, SEV guest VMs can choose which pages they would like to be private. The choice is done using the standard CPU page tables using the C-bit, and is fully controlled by the guest. Due to security reasons all the DMA operations inside the  guest must be performed on shared pages (C-bit clear).  Note that since C-bit is only controllable by the guest OS when it is operating in 64-bit or 32-bit PAE mode, in all other modes the SEV hardware forces the C-bit to a 1.

SEV is designed to protect guest VMs from a benign but vulnerable (i.e. not fully malicious) hypervisor. In particular, it reduces the attack surface of guest VMs and can prevent certain types of VM-escape bugs (e.g. hypervisor read-anywhere) from being used to steal guest data.

The RFC series also includes a crypto driver (psp.ko) which communicates with SEV firmware that runs within the AMD secure processor provides a secure key management interfaces. The hypervisor uses this interface to enable SEV for secure guest and perform common hypervisor activities such as launching, running, snapshotting , migrating and debugging a  guest. A new ioctl (KVM_SEV_ISSUE_CMD) is introduced which will enable Qemu to send commands to the SEV firmware during guest life cycle.

The RFC series also includes patches required in guest OS to enable SEV feature. A guest OS can check SEV support by calling KVM_FEATURE cpuid  instruction.

The following links provide additional details:

AMD Memory Encryption whitepaper:

http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf

AMD64 Architecture Programmer’s Manual:
http://support.amd.com/TechDocs/24593.pdf
SME is section 7.10
SEV is section 15.34

Secure Encrypted Virutualization Key Management:
http://support.amd.com/TechDocs/55766_SEV-KM%20API_Spec.pdf

See the full patch for more information.
https://lkml.org/lkml/2016/8/22/960

more info for AMD Secure Memory Encryption (SME) for Linux

A follow-up to:

AMD’s Secure Memory Encryption (SME) and Secure Encrypted Virtualization (SEV)

Tom Lendacky of AMD posted v2 of a 20-part patch to most of the linux-kernel (and other) lists, adding support for AMD Secure Memory Encryption (SME), adding more documentation about AMD SME.

Secure Memory Encryption (SME) is a feature found on AMD processors.
SME provides the ability to mark individual pages of memory as encrypted using the standard x86 page tables.  A page that is marked encrpyted will be automatically decrypted when read from DRAM and encrypted when written to DRAM.  SME can therefore be used to protect the contents of DRAM from physical attacks on the system.
[…]
BOOT data (such as EFI related data) is not encyrpted when the system is booted and needs to be accessed as non-encrypted.  Add support to the early_memremap API to identify the type of data being accessed so that the proper encryption attribute can be applied.  Currently, two types of data are defined, KERNEL_DATA and BOOT_DATA.
[…]
Documentation/x86/amd-memory-encryption.txt

http://vger.kernel.org/majordomo-info.html

Also check out the older v1 patch posting on the lists, there was some interesting technical discussion. The above previous blog post has a pointer to that discussion, as well as some other AMD specs.

FWTS v16.08.01 released

Alex Hung of Canonical announced v16.08.01 of FWTS, the FirmWare Test Suite.

There are a few new ACPI tests in this release:

  * acpi: nfit: add ACPI NFIT test
  * lib: acpi: add support for MPST
  * acpi: mpst: add ACPI MPST test
  * lib: acpi: add support for PMTT
  * acpi: pmtt: add ACPI PMTT test
  * ACPICA: Update to version 20160729

See the release notes for the list of bugfixes.

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

New Linux VM Rowhammer attack

Catalin Cimpanu has a story in Softpedia about a new use of Rowhammer:

New FFS Rowhammer Attack Hijacks Linux VMs: Attack was successful in tests against Debian and Ubuntu

Researchers from the Vrije University in the Netherlands have revealed a new version of the infamous Rowhammer attack that is effective in compromising Linux VMs, often used for cloud hosting services. The Rowhammer attack was discovered two years ago and caused a lot of stir when researchers disclosed it because it showed how, by bombarding a row of memory cells, an attacker could reverse binary zeros into ones and vice versa. […]

http://news.softpedia.com/news/new-ffs-rowhammer-attack-targets-linux-vm-setups-507290.shtml

Position Independent Executables for ARM

Alexandre Belloni submitted a patch to the Linux-kernel list with patch to run Position Independent Executables (PIEs) on ARM:

Embedding Position Independent Executables:
This series introduces Position Independent Executables (PIEs) for the ARM architecture. The main goal is to avoid having to write low level code in assembly as this is currently the case for suspend/resume. Multiple platforms will benefit from this infrastructure: at91, rockchip, sunxi, am335x. I’ve still avoided using the ELF header itself to be more efficient. For example, for atmel, the PIE is 66772 bytes when embedded in an ELF versus 344 bytes standalone. This is working properly because the PIE is self standing and correctly padded. Changes in v2:
 – handle big endian
 – handle gcov and ftrace by disabling them before compilling the PIE
 – Get the alignment from the original ELF to ensure the PIE is
   properly aligned in SRAM.
 – stop using fncpy
 – rebased on v4.7-rc1

 

https://lkml.org/lkml/2016/6/28/989

kernelscan

Colin Ian King has written kernelscan, a tool to help parse Linux kernel messages.

[…] The Linux kernel contains lots of error/warning/information messages; over 130,000 in the current 4.7 kernel.  One of the tests in the Firmware Test Suite (FWTS) is to find BIOS/ACPI/UEFI related kernel error messages in the kernel log and try to provide some helpful advice on each error message since some can be very cryptic to the untrained eye. The FWTS kernel error log database is currently approaching 800 entries and I have been slowly working through another 800 or so more relevant and recently added messages.  Needless to say, this is taking a while to complete.  The hardest part was finding relevant error messages in the kernel as they appear in different forms (e.g. printk(), dev_err(), ACPI_ERROR() etc). In order to scrape the Linux kernel source for relevant error messages I hacked up the kernelscan parser to find error messages and dump these to stdout.  kernelscan can scan 43,000 source files (17,900,000 lines of source) in under 10 seconds on my Lenovo X230 laptop, so it is relatively fast. […]

http://smackerelofopinion.blogspot.com/2016/07/scanning-linux-kernel-for-error-messages.html

http://kernel.ubuntu.com/git/cking/kernelscan.git/