TPM microconf at 2017 Linux Plumbers Conference

Matthew Garrett has announced a TPM microconference at the upcoming Linux Plumbers Conference:

I’m pleased to say that after the success last year, there will be another TPM microconference at this year’s Linux Plumbers Conference. The current schedule has this taking place on Wednesday the 13th of September, so just under 4 weeks from now. We have a list of proposals for discussion at http://wiki.linuxplumbersconf.org/2017:tpms but please feel free to add more! I intend to finalise the schedule by the end of next week, so please do so as soon as you can. For those of you who weren’t there, the Linux Plumbers conference is an event dedicated to bringing together people working on various infrastructural components (the plumbing) of Linux. Microconferences are 3 hour long events dedicated to a specific topic, with the focus on identifying problems and having enough people in the room to start figuring out what the solutions should be – the format is typically some short presentations coupled with discussion.

From James Bottomley’s comments on the LPC entry on this microconf:

Following on from the TPM Microconference last year, we’re pleased to announce there will be a follow on at Plumbers in Los Angeles this year. The agenda for this year will focus on a renewed attempt to unify the 2.0 TSS; cryptosystem integration to make TPMs just work for the average user; the current state of measured boot and where we’re going; using TXT with TPM in Linux and using TPM from containers.



Full text of Matthew’s email:


Intel AMT, continued

Matthew Garrett has a new tool to check for AMT on Linux:

If AMT is enabled and provisioned and the AMT version is between 6.0 and 11.2, and you have not upgraded your firmware, you are vulnerable to CVE-2017-5689. Disable AMT in your system firmware.


A little bird told me some info about Intel AMT and Linux:

* Some BMC/IPMI devices also listen on port 623 because they support the same asf-rmcp protocol. So if you are using nmap to scan networks you may see false positives from these devices.

* The Intel OpenAMT tool can be used on Linux to determine if AMT is enabled. The procedure is something like:
  * build with: ./configure;make
  * on the system to test, load the mei modules with: modprobe mei-me
  * run the src/lms binary (only uses standard libraries, no need to ‘make install’)
  * check daemon.log, not enabled should be something like “LMS: Cannot connect to Intel AMT via MEI driver”
  * clean up by killing the running lms process, removing the lms binary, and unloading the mei modules: rmmod mei-me mei

* On Linux, blacklisting the mei-me/mei modules will prevent local access to AMT, but doesn’t help if it’s already enabled.


Matthew Garrett leaves CoreOS, joins Google

Matthew Garrett is leaving CoreOS and has gone to Google!




Linux Kernel lockdown

David Howells of Red Hat submitted a 16-part patch to the Linux-(Security,EFI,Kernel) mailing lists, with an interesting security patch for the Linux kenel. The patch includes contributions from: David Howells, Josh Boyer, Kyle McMartin, Matthew Garrett, and Dave Young. Quoting the patch announcement:

These patches provide a facility by which a variety of avenues by which userspace can feasibly modify the running kernel image can be locked down. These include:

* No unsigned modules and no modules for which can’t validate the signature.
* No use of ioperm(), iopl() and no writing to /dev/port.
* No writing to /dev/mem or /dev/kmem.
* No hibernation.
* Restrict PCI BAR access.
* Restrict MSR access.
* No kexec_load().
* Certain ACPI restrictions.
* Restrict debugfs interface to ASUS WMI.

The lock-down can be configured to be triggered by the EFI secure boot status, provided the shim isn’t insecure.  The lock-down can be lifted by typing SysRq+x on a keyboard attached to the system. They are dependent for some EFI definitions on the keys-uefi branch.

Copy secure_boot flag in boot params across kexec reboot
Add the ability to lock down access to the running kernel image
efi: Get the secure boot status
efi: Lock down the kernel if booted in secure boot mode
efi: Disable secure boot if shim is in insecure mode
efi: Add EFI_SECURE_BOOT bit
hibernate: Disable when the kernel is locked down
acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down
Add a sysrq option to exit secure boot mode
kexec: Disable at runtime if the kernel is locked down
PCI: Lock down BAR access when the kernel is locked down
x86: Lock down IO port access when the kernel is locked down
ACPI: Limit access to custom_method when the kernel is locked down
asus-wmi: Restrict debugfs interface when the kernel is locked down
Restrict /dev/mem and /dev/kmem when the kernel is locked down
x86: Restrict MSR access when the kernel is locked down

More information:


Matthew and James on IoT security

Matthew Garret and James Bottomley have two blog posts out on IoT security.

I have nearly given up on IoT security, there is so much new IoT vulnerabilities in the news each day. 😦


Home Automation: Coping with Insecurity in the IoT


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.