Software assurance, security, and more talks

On the topic of software assurance and security, I'd like to provide a quick summary of the Design Automation Conference (DAC) panel discussion
Fazzari, et al., “Panel: Design for Hardware Security: Can You Make Cents of It?”, Design Automation Conference, June 9, 2015  http://www2.dac.com/events/eventdetails.aspx?id=182-18  

I sometimes grab a picture with my phone of my travels, but this time the best I have is my parking space at Seatac airport. You know the picture, namely the one you take to remind oneself of 'where' you parked after a 22 hour travel day and you brain isn't quite running at peak efficiency.

So other than my above parking travails, back to the trip. DAC is historically a venue for Computer Aided Design (CAD) vendors and innovation from academia and industry. The above-listed panel was part of a security track. Both security and embedded are two notable additions to DAC's historically CAD-oriented theme. The morning had sessions on hacking software-defined radio and IOT devices. The panel session offered interesting perspectives, including such quotations as Dino's "Insecure software can burn up the world," which is a play on Marc Andressen's quotation "Software Is Eating The World" http://on.wsj.com/1w2FbVs.

Other discussions included Common Criteria and today's platforms, secure elements/smart cards. A funny quotation from another panel member was "it's all software, whether C code or Verilog." A more cynical comment was 'Hardware is more difficult than software. That's part of the problem."

The most inspiring question from the audience came from Todd Austin http://web.eecs.umich.edu/~taustin/. His observation was that formal methods experts for hardware should move up into software security. And the latter infosec experts should move their expertise more into evaluating hardware. He also observed that DAC is a perfect venue to evolve that type of dialectic.

Speaking of that feedback of moving hardware assurance experts into software (at least the 'firmware' class of software), I'm happy to note that:
Oleksandr Bazhaniuk, John Loucaides, Lee Rosenbaum, Mark R. Tuttle, Vincent Zimmer, "Symbolic Execution for BIOS Security," 9th Usenix Workshop on Offensive Technologies (WOOT) '15, August 10, 2015 https://www.usenix.org/conference/woot15/workshop-program/presentation/bazhaniuk
has been accepted. This paper will describe how formal methods can be applied to the challenge of firmware assurance. I'm anxious for the paper and presentation to go public next month. I'll revisit the topic in this blog at that time.

Given the modular nature of thing like UEFI PI-based EDKII firmware, it's often not sufficient to do analysis from one supplier element. Testing needs to happen across the final composition of the modular elements. As such, I'm excited to see work like http://www.infoq.com/news/2015/06/facebook-infer being available in the open and covering C code. I'd like to see tools like this available for both the open source EDK II platforms on www.tianocore.org (a firmware upstream) and then for the various vendor consumers of this code, including vendor downstreams.

In general, I want to encourage more cross-over between tools researchers and the firmware producing community. Starting with the driver synthesis work https://ssrg.nicta.com.au/publications/nictaabstracts/Vij_KRHZRWL_13.abstract.pml in 2013, and now WOOT in 2015, I hope to observe more frequent instances of such opportunities in the future. I always say that most innovations happen at the seams between two domains. As such, I'm happy to see the boundary between formal methods and firmware bearing fruit.

Now to move from to-be-published security collateral, I bumped into some existing papers, namely an interesting UEFI Security paper curation at https://github.com/robguti/firmware_security_docs/tree/master/bios
I see a couple of mine - https://github.com/robguti/firmware_security_docs/blob/master/bios/SF13_STTS002_100.pdf … and https://github.com/robguti/firmware_security_docs/blob/master/bios/SF09_EFIS001_UEFI_PI_TCG_White_Paper.pdf Nice to see what people cull as potentially useful material.

I'm also happy to see the following elements continually being updated in the open source, namely the UEFI 2.5 conformant HTTP driver,
https://github.com/tianocore/edk2/tree/master/NetworkPkg/HttpDxe,
HTTP boot https://github.com/tianocore/edk2/tree/master/NetworkPkg/HttpBootDxe
and finally, no need to type in octets
https://github.com/tianocore/edk2/tree/master/NetworkPkg/DnsDxe. Great progress on building out the HTTP scenarios, especially for data center usages where the needs of scale and connectionless downloads have been at odds historically.

I also look forward to participating in some upcoming talks.

The first talk is at the Intel Developer Forum (IDF) in San Francisco during late August. The talk is STTS003 - "Developing Best-in-Class Security Principles with Open Source Firmware."

http://myeventagenda.com/sessions/0B9F4191-1C29-408A-8B61-65D7520025A8/7/5

There will be some messages I've delivered in the past, but hopefully an exciting announcement about an innovation in system software to provide some additional defenses.

The next talk is later in the year at LinuxCon Dublin in October. Great overview at
http://firmwaresecurity.com/2015/07/13/uefi-mini-summit-at-linuxcon-europe-in-october/
UEFI Mini-Summit at LinuxCon/CloudOpen/
Embedded Linux Conference Europe
Wednesday, Oct. 7 in Dublin, Ireland
The UEFI Forum will host its second LinuxCon Mini-Summit. The one day event includes presentations on UEFI and ACPI developments, including tools and resources available to the
Linux community.

Option ROM's, code size

I noticed the recent post on Google+ https://plus.google.com/u/0/113713059726404063654/posts/7KTPg174pm1 about the UEFI PlugFest presentation http://www.uefi.org/sites/default/files/resources/UPFS11_P6_OptionROM_AMI.pdf. Specifically, Brian's https://plus.google.com/u/0/+BrianRichardson/about slide 3 comment "–Designed to reduce code size".

Code size and host firmware implementations, such as UEFI-based solutions, can be a controversial topic. As can be boot-time, security,....

As such, I'm not going to discuss a feature comparison of coreboot versus EDK II for comparable hardware in this posting. I showed a design comparison of the firmware designs on slide 16 of https://firmware.intel.com/sites/default/files/resources/SF14_STTS001_102f.pdf, but size and / or other metrics like cyclomatic complexity weren't discussed. That'll be an exciting posting for another day. A data driven view is always the best way to approach this topic and I'd like to have 2 fully open platform trees build in coreboot www.coreboot.org (plus a payload like U-Boot http://www.denx.de/wiki/U-Boot with its I/O drivers) and EDK II http://www.tianocore.org/edk2/ on a community site.

There's no better way to teach developers about a topic than source trees, IMHO. I recall talking with a developer recently about SMM and Authenticated Variables. He had read https://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Implementing_UEFI_Authenticated_Variables_in_SMM_with_EDKII.pdf and kept asking follow-up questions. After seeing the EDK2 implementation https://downloadcenter.intel.com/download/23962/EDKII-Update-for-Intel-Quark-BSP and the PI SMM code therein he finally said "I get it."

And speaking of open source, glad to see posting of information like https://download.01.org/future-platform-configuration-hub/skylake/register-definitions/ to help enable open source firmware community development. Good stuff.

For this posting, though, I wanted to address the note above at the top of the blog regarding the plug fest presentation. The size comment was embedded in a broader point about "UEFI solves many problems for the IHV." It wasn't meant to be 'UEFI relative to something else', but more 'various embodiment options of UEFI.'

Specifically, the UEFI Driver Model has the concept of Bus drivers and Child device drivers. Common idioms are put into Bus Drivers, which today include USB, PCI, SCSI, Blue Tooth, etc. The bus drivers are typically stored in the system board ROM by the Original Equipment Manufacturer (OEM) so that the child device drivers built by the Independent Hardware Vendors (IHV's) only have to carry device specific code. The latter code is typically delivered as separate binaries in Host Bus Adapter (HBA) cards, such as PCI adapter, or embedded in the OEM system board firmware image.

The above figure from the UEFI 2.5 specification www.uefi.org above shows the relationship of the bus and child device drivers. Servers with sophisticated RAID and networking devices still enjoy the ROM savings and configurability afforded by the UEFI Driver Model. For small devices and more purpose build devices, this bus/device dichotomy may not yield as many code savings since you will not often observe a 1 bus to many devices relationship.

I don't want to be viewed as a UEFI apologist or partisan in this posting, but I did want to clarify the context of the 'size' comment here. It was size in the sense of, if given N PCI device drivers, either duplicate logic from the bus driver is copied into each device driver instance (e.g., EFI1.02), or the EFI1.10+ (now UEFI2.5) driver model with the bus and device driver dichotomy of sharing code logic pushed into the bus driver.

Cheers