Linux Security Summit 2014/Abstracts/Cook 1

From Linux Kernel Security Subsystem
Revision as of 15:51, 15 July 2014 by JamesMorris (talk | contribs) (New page: == Title == Verified Component Firmware == Presenter == Kees Cook == Abstract == Privileged executable code running on a device is not limited to just the Boot Firmware and Kernel. On...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Title

Verified Component Firmware

Presenter

Kees Cook

Abstract

Privileged executable code running on a device is not limited to just the Boot Firmware and Kernel. One major area that gets frequently overlooked is Component Firmware: firmware loaded on network interfaces, wifi and cellular wireless devices, hard drives, keyboards, etc. Some of these devices have direct DMA access to system physical memory, some have access to potentially sensitive information (keystrokes, network or storage data, etc). Presently, the Linux Kernel loads firmware from userspace via directly located files, data passed by uevent handlers, or by specialized updater tools that manipulate (potentially undocumented) device interfaces. There is no mechanism in place for the kernel to reason about the origin of the firmware, so it is possible for userspace to load malicious Component Firmware that could result in a compromised kernel or a component that persistently snoops on data.

As was done for kernel module loading, I have introduced a new interface for firmware loading that operates on a file descriptor rather than arbitrary blobs passed from userspace. This allows a system to limit firmware loading to only known sources. For example, firmware loading could be limited to read-only crypto-verified storage, or with verified signatures.

Additionally, I will present a methodology for evaluating Component Firmware risks based on the component's own level of firmware validation and the component's access to sensitive interfaces or data. With this, a plan for firmware that is loaded external to the kernel (entirely via userspace) can be developed, potentially leading to filtered device communication.