Regarding a prediction for 2015

Given it is the final day of 2014, I thought that my final blog of 2014 would treat the year.next which commences in a few hours, maybe with another one of my infamous TL:DR-style postings? Specifically, I'd like to build upon missive from Tim Lewis at http://uefi.blogspot.com/2014/10/security-to-eclipse-user-features-as.html wherein he shared his belief that security concerns in the platform firmware will predominate as the top user story of 2015. Given the sampling below from 2014, he may be observing an unenviable trend line.

Regarding that trend, there have been talks at several venues in 2014, such as the Black Hat (BH) talks a few months ago https://www.blackhat.com/docs/us-14/materials/us-14-Kallenberg-Extreme-Privilege-Escalation-On-Windows8-UEFI-Systems.pdf. This talk had an associated CVE http://www.kb.cert.org/vuls/id/552286 and white paper https://www.mitre.org/sites/default/files/publications/14-2221-extreme-escalation.pdf.

In addition, just this week there were a couple of talks featured on UEFI at the Chaos Communications Conference (CCC), including https://www.youtube.com/watch?v=5BrdX7VdOr0 and the associated presentation https://frab.cccv.de/system/attachments/2557/original/AttacksOnUEFI_Slides.pdf
by researchers from Bromium and Mitre, respectively.

The other CCC talk was on EFI and Thunderbolt https://www.youtube.com/watch?v=5BrdX7VdOr0. Glad to hear from the Matthew Garrett question to the presenter near the end of the talk that the option ROM vulnerability could have been mitigated if the Apple platforms implemented UEFI Secure Boot with option ROM verification (i.e., UEFI Driver Loading) enabled.

These security events and broad use of UEFI and edk II-based platforms definitely argue for the need to have additional industry coordination. This is a role that CERT has done admirably, but as Tim noted, they are now joined by the UEFI Security Response Team (USRT) http://www.uefi.org/security. This effort has been followed by a more code base-specific effort, too http://tianocore.sourceforge.net/wiki/Security. I am happy to be involved in both and although my CVSS-Fu isn't too evolved yet, I'm trying my best in writing technical advisories and doing the associated grading.

It is interesting that the references for both BH and CCC  https://www.youtube.com/watch?v=5BrdX7VdOr0 talks above cite the Intel Framework Specifications at www.intel.com and not the superseding UEFI Platform Initialization (PI) specifications http://www.uefi.org/sites/default/files/resources/PI_Spec_1.3.zip. This might contribute to some of the ambiguity seen in the boot script implementations, for example, noted in the CCC talk, since the Intel Framework specifications are frozen after having been contributed to the UEFI Forum. Maybe posting a ZIP of the PI specs and a PDF of the Framework makes the latter more search-engine friendly?

For the CCC talk https://frab.cccv.de/system/attachments/2557/original/AttacksOnUEFI_Slides.pdf, it was good to see that slide 53 mentions the work done with my Intel colleague

      [11] A Tour Beyond BIOS:
      Implementing S3 Resume with EDK2 –JiewenYao and Vincent Zimmer,
      October 2014

Jiewen and I designed features like the Lock Box protocol https://github.com/tianocore/edk2-MdeModulePkg/blob/master/Include/Protocol/LockBox.h to allow for protecting the boot script memory, via SMM or other container, back in 2009. But issues in seeing the protections deployed are compounded by the sheer difficulty in implementing S3 resume in platforms. Specifically, getting the functionality correct and having less-easily testable properties like securing the boot script has proven challenging. As a platform developer the last call you want to hear during product development is from the SQA team, saying "Everything works great, but our S3 resume testing fails once out of 10,000 times."

The above S3 document represents part of an effort to document some of the design intent on edk II source artifacts. We already have architectural intent documents such as http://www.cs.berkeley.edu/~kubitron/courses/cs194-24-S14/hand-outs/SF09_EFIS001_UEFI_PI_TCG_White_Paper.pdf (including the companion talk https://www.youtube.com/watch?v=lZ505uz1TZ4).

Regarding other defenses, in the S3 talk Corey also mentioned the "SMI Transfer Monitor" (STM). Corey's co-presenter Rafal discusses the STM in more detail at http://invisiblethingslab.com/resources/bh09dc/Attacking%20Intel%20TXT%20-%20paper.pdf. This is also mentioned in CCC 2013 talk http://events.ccc.de/congress/2013/Fahrplan/system/attachments/2266/original/Gal_Diskin_-_Virtually_Impossible_-_30C3__release_version_.pdf by former Intel researcher Gal Diskin.on slide 13. Chapter 13 of Grawrock's 2nd edition of Safe Computing http://www.amazon.com/Dynamics-Trusted-Platform-Building-Approach/dp/1934053171 also describes this feature. The gist of the STM is that it represents a usage of the peer-monitor capability in IA32, a hardware feature defined in chapter 34.15 of the Intel Software Development Manual (SDM) https://www-ssl.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html. There is a nice peer monitor overview at http://virtualizationtechnologyvt.blogspot.com/2011/07/vmx-and-smm-dual-monitor-mode.html. The use of the peer monitor, which is essentially virtualization controls in System Management Mode (SMM), allows for de-privileging today's ring 0 SMM code, such as that built responsive to the infrastructure in volume 4 of the PI 1.3 specification http://www.uefi.org/sites/default/files/resources/PI_Spec_1.3.zip. So when Corey said "where is the STM specification?", he was referring to the firmware convention for loading the STM, interaction with Intel TXT, and how to expose resource lists for which the guest SMM code can access. This class of firmware interaction is the "STM specification" and it is built upon the hardware specifications of the peer monitor virtualization capability treated in the SDM. The SDM is the bible for software-visible parts of IA32, i.e., the 'architecture.' The SDM hasn't changed over the last decade plus, whereas the STM specification has, er, evolved. 

I have spent quite a bit of time on SMM over the last decade plus, from having defined the Framework SMM CIS http://www.intel.com/content/www/us/en/processors/itanium/efi-smm-cis-v09.html infrastructure http://www.google.com/patents/US6848046, from which the present PI 1.3 SMM design has been derived, to collaborating on peer monitor and STM work. I'm a big fan of isolation technologies and trusted computing, but I'll have to pause here for this 2014 entry on this topic. If I were a smarter guy I would follow in the foot-steps of Fermat's Last Theorem and claim to have the final proof of solving the SMM security issues but excuse myself for today by noting that the answer is "too large to fit in the margin" of this blog http://en.wikipedia.org/wiki/Fermat%27s_Last_Theorem.

Just as a document cannot replace well commented codes, having more executable methods for assurance are always preferred. These include efforts such as the CHIPSEC work https://github.com/chipsec/chipsec which I also describe in http://www.uefi.org/sites/default/files/resources/2014_UEFI_Plugfest_04_Intel.pdf and https://www.youtube.com/watch?v=aV1DSF4cwGw. These tests are run after boot and provide an a posteriori view of the platform.

More recent technology includes having security testability in-situ with the platform, versus a CHIPSEC style post-boot test, and reporting the results. This type of test and reporting capability was mentioned in 2013 at http://www.uefi.org/sites/default/files/resources/UEFI_Summerfest_2013_-_Microsoft_Hardware_Security_Test_Interface.pdf and now has a public specification realization at  http://msdn.microsoft.com/en-us/library/windows/hardware/dn879006.aspx (HSTI) This work bridges the semantic gap historically faced by platform builders wherein the various system requirements in a Windows Hardware Certification document, such as http://download.microsoft.com/download/7/0/E/70E74967-B0FE-477A-974F-C1ED16EE31DF/windows8-1-hardware-cert-requirements-system.pdf, can now have a companion reporting channel. Examples include injunctions in System.Fundamentals.Firmware.UEFILegacyFallback, such as

"An OEM may not ship a 64 bit system which defaults to legacy BIOS or loads legacy option ROMs if that system ships with a UEFI-compatible OS. When Secure Boot is Enabled, Compatibility Support Modules (CSM) must NOT be loaded."

These Compatibility Support Module (CSM) behaviors are something that only the platform implementation can deduce and are difficult to detect via a later test, although heuristics like scanning 0xC0000p through 0x100000p in the address space 'could' be done.

The HSTI interface builds upon the Adapter Interface Protocol (AIP) class of structure defined in the UEFI 2.4 specification http://www.uefi.org/sites/default/files/resources/2_4_Errata_A.pdf. Since AIP producers are boot service only, a pre-OS agent needs to query the HSTI interface in order to cull the settings and convey the results into the operating system run time, if needed, in a vendor-specific fashion.

Related work to HSTI that goes beyond mapping to Windows requirements include the ability to report BIOS Integrity Attributes, as described in http://csrc.nist.gov/publications/drafts/800-155/draft-SP800-155_Dec2011.pdf in 3.2.1.1. And in order to surface this information, we defined in http://www.trustedcomputinggroup.org/files/static_page_files/D4268663-1A4B-B294-D05DE87EE90558B6/TCG_EFI_Platform_1_22_Final_-v15.pdf the following:

    typedef struct {

       UINT32 VendorId;

       EFI_GUID ReferenceManifestGuid;

    } TCG_Sp800-155-PlatformId_EventStruct

This structure can be used to reference an off-machine Reference Manifest (RM). The idea is that the GUID in the structure above would be specific to a vendor, model, and firmware instance in a XML-based manifest document on the platform suppliers website. The schemas are defined in http://www.trustedcomputinggroup.org/files/resource_files/73638609-1A4B-B294-D0902CC2A13C8697/Reference_Manifest_Schema_Specification_v2.0.r5.pdf, so now it's a set of work items for the industry to map the RM's to platform attributes, such as mentioned in 155.

Who knows, at some point maybe these reporting and testing efforts will all align?

Well, if you have gotten this far, the 'Didn't Read" portion of "Too Long, Didn't Read" (TL;DR) hasn't been the case for you. I'm not sure whether to reward you for your stoicism or not for wading through this entry.

To summarize, 2014 has shows a spate of security-related activities, both by the attackers (BH, CCC) and the defenders (USRT). The firmware-producing and consuming community is acutely aware of assurance concerns and new testing methodologies have been deployed in '14 and are coming in '15, too, including HSTI. I don't necessarily subscribe to the 'Spy versus Spy' aspect of security, or fall into existential angst that the "Defenders Dilemma" is not solvable. Instead, I see many parties passionate about having robust, usable systems and collaboration on art to achieve those goals. Open source, open documentation, open specifications, open platforms,.... All help in the cause.

And if you're still working these last hours of today, pause and have a coffee.

Also, enjoy a happy and safe new year.

Cheers,

V.Z.兹梅

"So Long, and Thanks for All the Fish"

Yesterday my last day in DuPont after nearly 18 years, 15 of those in the same cube, here at this WA Intel site. Off to work at the Seattle office in early '15. So long, DuPont, and thanks for the memories. And all of the Fish, although in this case 'Andrew Fish.' Although Fish doesn't work at Intel any longer, the inventor of the "Intel Boot Initiative" (IBI), which became EFI/UEFI, still lives in the South Puget Sound. We broke bread for the final time at our favorite local restaurant.

This is the "R&R" mentioned in the acknowledgements section of the 2nd edition of Beyond BIOS http://www.amazon.com/Beyond-BIOS-Developing-Extensible-Interface/dp/1934053295/, "Also many of this team will recall over ten years of "design discussions" at R&R." I captured Fish on the left and Mark Doran http://newsroom.intel.com/community/intel_newsroom/bios?n=Mark%20S.%20Doran&f=searchAll on the right eating our final Teriyaki bowls. As always, good conversations on firmware and technology. And the picture is also epic in that the duo often introduces itself as "Andrew Fish who invented EFI, and Mark Doran who delivered it to the industry."  Mike Kinney & I held down the other side of the table. I've learned quite a bit working with all three of these colleagues over these many years.

During my final days at Compaq in late 1996 I talked to Intel about joining, and my options were "Join Portland for Xeon, or DuPont for Merced." I was inspired by the thought of joining the 64-bit revolution, so there was no doubt in my mind as to which locale to choose.  Also, having grown up in Texas, the Pacific Northwest was a large unknown, so the distinction between OR and WA didn't even factor into my decision.

And my whole tenure at Intel in DuPont since February 1997 has been boot firmware.  I began with a PC/AT BIOS underneath the Merced System Abstraction Layer (SAL), with the original OS loader interface of SAL_PROC (0x13), as a 64-bit mapping of BIOS 13h.  Same for video mapping of SAL_PROC (0x10), keyboard of SAL_PROC (0x13), etc. The OS community wasn't amused.

As the OS interface evolved to C-based IBI, then EFI, the underlying boot infrastructure changed. I moved from driving some of the SAL-on-BIOS for server (aka "FrankenBIOS"), to the short-lived Workstation Product Division (WPD) where we evolved a C-based boot solution. The latter pioneered art such as the Furball and interposer, which were the predecessor of the Intel Framework Compatibility Support Module (CSM) and CSM16 binary.  We called the former 'furball' because it was something we imagined a native 32-bit (IA32) and 64-bit (Itanium) firmware solution would eventually 'cough up', with a less than pleasant imagery derived from the world of cats.

In 1999 we had evolved the workstation firmware to binary modules called "Plug-In Modules", or PIM's. I recall a fateful meeting with the lead on that effort and my colleague visiting from OR. The conversation went something like 'And we can also put the PIM's into option ROMs, too.' At that point I realized the trajectory was ill-fated since the problem with open platforms and option ROM's isn't factoring code to run in that storage container so much as 'how' to interoperate with the system firmware, namely what API's to expose, where to define them, and how to evolve this art. And to that end, I realized that EFI would win as it was the only man standing to solve this problem.

Specifically, EFI nailed down the interface methodology to the OS loader and option ROM community where the broad interoperability was needed.  Moving the underlying initialization firmware to a new methodology, such as what became Intel Framework and then UEFI PI was valuable, but not the necessary first step.  The first step was to lay the foundation for broad interop in order to have time for the top-level OS and IHV ecosystem to start moving their dependent infrastructure.

At that point in my career when I had that realization, I was lucky enough to have a friend and Intel colleague like Andrew Fish who suggested I have lunch with Mark Doran.  Afterward I on-boarded to the EFI team in 1999 and the rest has been a great 15 run on helping evolve EFI into UEFI, EFI-on-BIOS into Framework and then UEFI PI, and the open source offering from "EFI Sample" to EDK to today's EDK II.  Since then a lot of code and specifications have ensued

with hopefully more to come in 2015+.  Not sure if there is another 15 years into the run.  Although one co-developer of Tiano, the code-name for the underlying Framework (and now PI work) quipped a few years ago "We said Tiano was the '20 year' BIOS replacement solution, so when did you start counting?"

Speaking of 2015+, I had better get back to work if I want to get a head start on the next way of the firmware revolution started in South Puget Sound, WA.

Cheers

Porting to a new architecture

Part of the excitement of working with system firmware includes programming on bare metal. I recall taking an NT Driver class back in 1998 led by some Ex-DEC engineers. The engineer said "programming kernel mode drivers is tricky, but the real magic entails the work of the firmware guys." As an embedded guy working in this area since 1992, all I could say is 'Yes.'

The news about the RISC-V http://riscv.org/ port of coreboot http://review.coreboot.org/#/c/7065/ reminded me of some of the thrills in porting firmware to a new CPU architecture. A possible UEFI port for RISC-V is even mentioned during the technical discussion of this new instruction set architecture https://www.youtube.com/watch?v=vB0FC1DZqUM&feature=youtu.be.

Some of my favorite work includes bring-up for EFI on new CPU's. We started the EFI journey in 1998 working on Itanium and IA32. The Itanium port built upon SAL-A/B as the PI equivalent code, such as memory and CPU initialization http://www.amazon.com/IA-64-Linux-Kernel-Design-Implementation/dp/0130610143.  Simarly, for IA32 we originally booted upon a PC/AT BIOS using techniques like DUET https://github.com/tianocore/edk2/tree/master/DuetPkg.

Over time we moved to native code for the platform initialization as the Framework specifications evolved. These Framework specifications became the UEFI Platform Initialization (PI) specifications, and the code base evolved from EDK http://tianocore.sourceforge.net/wiki/EDK to EDKII http://tianocore.sourceforge.net/wiki/EDK2.

In those early 2000's some fun path-finding was a port to XScale http://en.wikipedia.org/wiki/XScale. I mention that work a bit in the above article and also discuss the port in chapter 7 of  the first edition of Beyond BIOS http://www.amazon.com/Beyond-BIOS-Implementing-Extensible-Interface/dp/0974364908 since Intel was still delivering XScale-based products, although EFI wasn't an official requirement. Instead, I used the XScale port to show the cross-architecture flexibility and scaling of both the specifications and the associated code bases. In the second edition http://www.amazon.com/Beyond-BIOS-Developing-Extensible-Interface/dp/1934053295/, I removed that content and replaced it with Intel IA32 SOC examples.

Ironic to think that I was possibly the first person to do an EFI port to 32-bit ARM, albeit EDK-based and it had a faked-PEI but full DXE.

After that the next excitement occurred with Intel64/EM64T/AMD64/X86_64, or as is now known in the UEFI binding, x64.  See chapter 2 of the UEFI2.4 specification at www.uefi.org. There the challenge was having to enable paging. Itanium also needed paging but we used software TLB handlers and had simple logic to program the TR registers in our SAL, then DXE CPU driver. For x64, we kept PEI to 32-bit since page tables in ROM and / or temporary RAM were tricky and ported DXE, our EFI/UEFI core, to 64-bits.

The crafting of .s/.asm files for a new architecture and getting through the first boot is more exciting than a platform port within a given architecture since there is a sense of pioneering with these foundation components.

Since this pioneering, the ARM community has done the EDKII ports to ARM32 and Aarch64 and they are first class citizens in the standards, including UEFI & PI, and the codebase, such as EDKII.

And although there isn't an official MIPS UEFI binding, there is a port to MIPS 32 at http://sourceforge.net/projects/efi-mips/.

I look forward to seeing more ports to UEFI, including the presently non-UEFI Power8 firmware such as https://github.com/open-power/skiboot.

Like the RISC-V work and ARM ports, I'll have to watch the latter efforts from the sidelines. My day job and extra-credit/after hours budget have enough Intel-architecture based efforts and opportunities to pursue.  Although I have to admit I miss some of the excitement of the port to ISA.Next.

Post-Intel Developer Forum 2014

I would like to thank Tim Lewis for mentioning this blog at http://uefi.blogspot.com/2014/09/new-bios-related-blogs.html. I have dual-posted this item to https://uefidk.com/blog/edkii-fsp-and-other-topics, too, as an experiment. The later community has some interesting code projects and write-up's I reference below.

I spent a few days last week in San Francisco at the Intel Developer Forum (IDF).  My hotel was right off Union Square, thus allowing me to witness of cross-section of San Francisco each morning.

All of the sessions were at the Moscone Convention Center.

My presentation at https://intel.activeevents.com/sf14/connect/sessionDetail.ww?SESSION_ID=1265 now has the material posted https://intel.activeevents.com/sf14/connect/fileDownload/session/08F28DCA2DB2EA88418F93B309D82DE4/SF14_STTS001_102f.pdf.

The audio variant of the material should be posted in a couple of weeks. My talk immediately preceded and also mentioned the session of UBMS https://intel.activeevents.com/sf14/connect/sessionDetail.ww?SESSION_ID=1266 led by Brian Richardson and Mark Doran.

As always, the most exciting part of the event entailed discussion with customers and collaborators both within and outside of Intel. My session was at 9:30am on Thursday and I took a short trip down memory lane, remarking on the two presentations I made in 2003, the first of which entailed how to build out platforms using the Intel (R) Framework specifications http://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-specifications-general-technology.html along with Bob Hart from Insyde and Mike Kinney from Intel, which became the foundation for chapter 7 of the Beyond BIOS books http://www.amazon.com/Beyond-Bios-Implementing-Extensible-Interface/dp/0974364908 and http://www.amazon.com/Beyond-BIOS-Developing-Extensible-Interface/dp/1934053295.

My talk picked up off Brian and Mark's talk from last year https://intel.activeevents.com/sf13/connect/fileDownload/session/DB60155205A8DF5837DA22D0FF90E3A3/SF13_STTS001_100.pdf and built out the progress during the intervening twelve months. I was happy to have Giri Mudusuru and Jiewen Yao from the PC Client Group (PCCG) and my Software and Services Group (SSG) help with questions and answers at the end, too, in addition to serving as co-authors on some of the white papers mentioned later in this blog.

Beyond the FSP-on-EDK2, which is a hybrid of source plus binary, the session also treated on alternate enabling models, including pure open source. Since the session only ran for one hour, with 50 minutes of presentation and 10 minutes of Q&A, we wanted to provide both the attendees and the broader ecosystem an opportunity to 'go deeper' on the subjects treated. As such, beyond the above-listed presentation material, we also note some addition material on slide 27.

The two papers we posted ahead of the talk includes the FSP-on-EDK2 aspect in http://www.uefidk.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Using_the_Intel_Firmware_Support_Package_with_the_EFI_Developer_Kit_II_0.pdf for the initial portion of the third agenda item, and http://www.uefidk.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Implementing_the_TinyQuark_Design.pdf for the second portion of fourth agenda item, respectively. The idea behind the white papers is to 'add words between the Power Point pictures', or elaborate on some of the design intent behind these two engineering efforts.

Another reveal at the talk is the upcoming book from Apress Embedded Firmware Solutions. The alpha posted online http://www.apress.com/9781484200711 already treats the coreboot plus FSP topic, with the final book due early next year. Again, this type of material production aligns with the intent of providing more behind-the-scenes detail and intent of these efforts. Presentations are great to set the tone and direction, and open source repositories must exist in the 'reduction to practice' phase, but having the written word in between the evangelism and the bits helps close the loop for the development community, in my opinion.

Some of the material left of the cutting room floor, in the interest both of time and scope of the presentation, included the recent UEFI payload for coreboot built with EDKII http://www.uefidk.com/develop#accordions_develop-page-9. This was going to follow foil 16 of the presentation were the concept of a 'payload' is introduced, but the inclusion seemed to veer astray of the EDKII/coreboot + FSP tenor of this section.

Here are a couple of the redacted foils that show the flexibility of these open source firmware communities, EDKII, FSP, and coreboot.

and

In the first diagram above you can see that the payload is composed of modules out of EDKII built into a firmware volume. This is the spatial view. We didn't want to mix GPL-based coreboot and EDKII sources, so the only import from the coreboot community was the coreboot memory declarations, or CBMEM, which were also defined in coreboot's libpayload, a BSD-friendly licensed set of sources. The second diagram above shows the flow of the UEFI payload with the coreboot platform 

The ultimate theme of the presentation, though, was to offer customers choice. The imagery used to reinforce this point included the quotation "All Roads Lead to Rome" http://en.wiktionary.org/wiki/all_roads_lead_to_Rome with 'Rome' in this case representing the customer using Intel(R) products and the 'Roads' describing the various enabling options.

Beyond IDF and its technical sessions, though, there was a rare Sergey Brin sighting http://www.theverge.com/2014/9/10/6133589/this-photo-of-sergey-brin-doing-yoga-at-IDF-is-not-strange, although my picture is a bit blurrier

And IDF also featured live music Weds night, namely Weezer http://www.weezer.com/

which was pretty interesting.

While at IDF I also had a chance to work directly with Jiewen, and overseas colleague. We typically interact over email or phone given his home site in the Shanghai, PRC, area and mine in the Seattle, WA, US area. One of the common questions we receive about UEFI Secure Boot UEFI Secure Boot entails Authenticated Variables. This was a topic treated lightly in the implementation document, so Jiewen and I created http://www.uefidk.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Implementing_UEFI_Authenticated_Variables_in_SMM_with_EDKII.pdf to specifically address the SMM-protected variant of this driver posted on http://www.tianocore.og.

On any of these presentations, white papers, and even this blog posting, I look forward to community feedback.

2/15/2015 update - the book cited at the end of the IDF presentation is now for sale http://www.apress.com/9781484200711

ToorCamp redux, Upcoming IDF 2014

To lead off today, I was lucky to have the opportunity to speak at ToorCamp this summer, with my talk titled “Secure boot, network boot, verified boot, oh my” http://toorcamp.toorcon.net/talks/#16 and material posted to https://docs.google.com/file/d/0BxgB4JDywk3MdnRsbnh6NW9rYU0/edit
I especially liked my quotation

A reminder from the KGB school of cipher security: “You never attack the standard, you attack the implementation, including the process.” - Grugq

The locale is pretty remote, namely the western-most portion of the US

My talk was on a Thursday and I was swamped at the office, so I ended up making it a 'day trip' from Tacoma to Neah Bay.

Like 2012, the talks were all hosted in the dome

including the couch for chatting with the host

I have to admit that the speaker on bio-hacking and transhumanism didn't convince me to get an RFID injection into my hand this trip.

I gave my talk and followed up with some face to face discussions for a couple hours afterward. Invariably the question of key revocation came up as a question in response to the Secure Boot discussion. Then I scurried to the nearby beach, snapped a photo of the sunset, and then headed back home. Luckily the local tribesman selling smoked salmon hadn't closed up shop, so I picked up a few packages of the same and beat a hasty retreat.

Saying goodbye to the Makah reservation

and the hackers at Hobuck Beach

The next journey is the Intel Developer Forum in San Francisco.  My upcoming talk is “Firmware Flexibility  using Intel Firmware Support Package,” Talk STTS001, Intel Developer Forum, San Francisco, September 11, 2014 https://intel.activeevents.com/sf14/connect/sessionDetail.ww?SESSION_ID=1265 This should provide a deep dive responsive to the https://intel.activeevents.com/sf13/connect/fileDownload/session/DB60155205A8DF5837DA22D0FF90E3A3/SF13_STTS001_100.pdf presentation last year, along with a few other updates on ecosystems and open source. Drop me a line if you're in SF at this time.

On other progress, my issued US Patents continue to climb, albeit slowly. Now that I've crossed the 300 mark (303 this week for US Patent Families and 823 for INPADOC) maybe I'll get to join the list of 'Prolific Inventors' at http://en.wikipedia.org/wiki/List_of_prolific_inventors. I am curious how to site confirms the assertion: "However, this table currently has an arbitrary cut-off limit for inclusion of 300 patent families. This is purely for practical reasons – there are 81 inventors throughout history with more than 300 utility patent families, but tens of thousands of inventors with more than 15 patents."  Hmmm.

This summer has also witnessed a flurry of presentations on attacks against UEFI implementations, including http://www.mitre.org/sites/default/files/publications/14-2221-extreme-escalation-presentation.pdf. This reminds me of the importance of the Grugq quote above on 'implementation' and underscores the value of work like Chipsec https://github.com/chipsec/chipsec I mentioned in http://www.uefi.org/sites/default/files/resources/2014_UEFI_Plugfest_04_Intel.pdf and other developer guidance, such as 'best practices' in pages 34-35 of http://www-inst.eecs.berkeley.edu/~cs194-24/sp13/hand-outs/SF09_EFIS001_UEFI_PI_TCG_White_Paper.pdf, But there are many additional things we can do with respect to testing, guidance, and instances of best-practices on http://tianocore.sourceforge.net/wiki/EDK2. Speaking of edk2 and security practices, I'm happy to see a reference implementation of a signed capsule update implementation, including the https://svn.code.sf.net/p/edk2/code/trunk/edk2/SecurityPkg/Library/DxeRsa2048Sha256GuidedSectionExtractLib/ support code.

Another exciting open source action is the release of seL4 kernel http://sel4.systems/ and the Isabelle proofs. I mentioned this effort in http://vzimmer.blogspot.com/2013/12/better-living-through-tools.html and since that publication https://github.com/seL4/seL4 has gone live. Gernot and the NICTA guys are impressive. I was happy to see my ex-NICTA collaborator Leonid posted our driver synthesis paper http://www.nicta.com.au/pub?doc=7690 to NICTA's website http://ssrg.nicta.com.au/projects/TS/drivers/synthesis/.  

Regarding the latter paper, this is as close as I can get to a refereed conference, it would seem, as Mike Rothman and I were bounced from LISA '14. We posted the rejected manuscript at https://uefidk.com/sites/default/files/resources/uefi-manageability-security-white-paper.pdf.  Since I'm not an academic but an ordinary Joe who has been slogging away in industry for the last 20+ years, I cannot understand the publish-or-perish or other metrics around papers http://blogs.lse.ac.uk/impactofsocialsciences/2014/04/23/academic-papers-citation-rates-remler/ in academia. I see the value of peer review and appreciate the written-word, along with open source, to scale pedagogy and advocacy.  

Social media never ceases to fascinate me.

Pageviews by Countries Entry Pageviews Malaysia 2

Pageviews by Browsers Entry Pageviews Chrome 2 (100%) Pageviews by Operating Systems Entry Pageviews Macintosh 2 (100%)

represents the latest access to this blog.  Someone reading this blog while running Google Chrome on a Macintosh in Malaysia.  Fascinating.

Or on Twitter https://twitter.com/vincentzimmer when I get a re-tweet or message from famous mathematicians

John Allen Paulos retweeted your Retweet

Jun 28: 

This is a geometry joke. pic.twitter.com/QLpUqHA3cz

1. 

Great stuff.

1/7/2015 update -
A friend of mine from Houston just pointed out an update to http://en.wikipedia.org/wiki/List_of_prolific_inventors.
I'm now on the list, and not even the 'bottom-most' entry (and among the youngest who owns up to his/her age).

Vincent Zimmer

312

USA

848

1970-

Computer software and firmware

[181][182]

Trends and openness

The balmy days of summer have made me reflect upon the past. And colleagues leaving of late make me more thoughtful. This is sort of a twist on the earlier career development talk, but with advice on how to pivot and react to the world. Of course the discourse includes a long-winded blog format that also treats on various aspects of life in tech and the human condition.

To begin, I work at a remote site (aka 'Siberia' of West Coast), so a long period of time can pass between seeing most colleagues. Even in the age of video conferencing, few parties use that class of tool, and I keep my camera covered with a yellow sticky note for other reasons.... In fact, I can work with some colleagues for years and only communicate on the phone or e-mail. When I finally do meet one of those long-distance collaborators in person, I often want to blurt out "you sounded much taller/shorter/fatter/older.... on the phone." But there really isn't an appropriate response. At one point I had mistakenly thought a collaborator was the Office Space stapler guy while remotely collaborating, and when we did finally meet, I sat stunned for the first ten minutes when I realized that I had mistaken this gentleman for an erstwhile cryptographer. The stapler guy image and the tan, fit person sitting across from me in the conference room didn't quite align.

On the other side of the coin, I do see certain people aperiodically over the course of the years, say at internal conferences or face-to-face mission meetings. In the early days of my tenure we would beat our chests and opine about all-night coding sessions, weight lifting, and other antics of youth, all with shiny, fresh cherubic faces.

Fast forward 10-15 years, and I note the weariness on faces w/ lines reflecting hours of ennui in meetings, bodies thicker around the middle from those days of eating lunch while on con-calls + fast-food while working late + more meetings + poor eyesight from poring over code and docs....  There is an occasional spark in an eye recounting the past, but mostly there are discussions that entail children and who is promoted or working at company XYZ.

But the advantage of wisdom includes having a network of collaborators and a more senior role to effect change. And that position is important, because the one thing that is constant over this span of time is change, especially in the technology industry. And when it comes to disruptive trends and change in our industry, I like to think of these trends as the four horseman of the apocalypse. When a disruptive trend is afoot, you can be in one of the three places: in front of the trend (and get trampled), behind the horses (and do clean-up duty), or riding one of the horses. Given my simplified view of things, you can imagine my predilection, namely riding one of the horses and being that agent of change.

As part of riding that course and driving change, one of the trends I observe has been the movement to open ecosystems, open source, including the move from PC/AT style BIOS to firmware environments like UEFI and its edk2 based development on tianocore.org. The salient portion of system software work, whether operating systems like Linux or edk2, includes openness and ecosystems. That's where open source can help.  Marc Andreesen rightly noted that software is eating the world http://online.wsj.com/news/articles/SB10001424053111903480904576512250915629460, and now open source software is eating software http://readwrite.com/2013/12/12/open-source-innovation#awesm=~oIwdZdqu0YdTo8.

This tend of open source source helps inform innovation paths, too.  Whether the discussion includes the minimal features to exemplify a capability, such as a micro-hypervisor using hardware virtualization https://github.com/udosteinberg/NOVA, or showing how a full UEFI edk2 implementation on Quark (1MByte image) can scale down to a 64-kbyte solution with "TinyQuark" http://firmware.intel.com/sites/default/files/Intel_Galileo_TinyQuark_64K.zip for https://firmware.intel.com/projects/get-started-intel-galileo-development-board. Why zips for the latter and not checked into an upstream open source IA firmware ecosystem? That's a discussion for another day. These small examples prove an innovation direction ahead of broad product execution that may embrace some of the design precepts demonstrated therein.

Another example of openness and innovation is network boot. Recall my description of IPV6 network booting at http://vzimmer.blogspot.com/2013/10/configuring-ipv6-network-boot.html. I'm a big fan of pre-OS networking https://www.researchgate.net/publication/258834396_A_Quick_History_of_UEFI_Networking and I chair that subteam, along with security, in the UEFI forum.

Since that discussion the options at http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml have been expanded by my friend at HP Samer El-Haj-Mahmoud http://www.uefi.org/sites/default/files/resources/UEFI_Summit_July_2013_UEFI2.4_Networking.pdf. The essence of these new options is to allow the UEFI machine to express that it has the ability to boot using a TCP-based, or connection-oriented protocol like HTTP, versus today's TFTP-based PXE wire protocol. This allows for more robust and scalable deployments without the need for retries and timeouts that afflict the UDP-based TFTP deployments.

Processor Architecture Types

Registration Procedure(s)

Expert Review

Expert(s)

Vincent Zimmer

Reference

[RFC5970]

Available Formats

CSV

Type	Architecture Name	Reference
0x00 0x00	x86 BIOS	[RFC5970][RFC4578]
0x00 0x01	NEC/PC98 (DEPRECATED)	[RFC5970][RFC4578]
0x00 0x02	Itanium	[RFC5970][RFC4578]
0x00 0x03	DEC Alpha (DEPRECATED)	[RFC5970][RFC4578]
0x00 0x04	Arc x86 (DEPRECATED)	[RFC5970][RFC4578]
0x00 0x05	Intel Lean Client (DEPRECATED)	[RFC5970][RFC4578]
0x00 0x06	x86 UEFI	[RFC5970][RFC4578]
0x00 0x07	x64 UEFI	[RFC5970][RFC4578]
0x00 0x08	EFI Xscale (DEPRECATED)	[RFC5970][RFC4578]
0x00 0x09	EBC	[RFC5970][RFC4578]
0x00 0x0a	ARM 32-bit UEFI	[RFC5970]
0x00 0x0b	ARM 64-bit UEFI	[RFC5970]
0x00 0x0c	PowerPC Open Firmware	[Thomas_Huth]
0x00 0x0d	PowerPC ePAPR	[Thomas_Huth]
0x00 0x0e	POWER OPAL v3	[Jeremy_Kerr]
0x00 0x0f	x86 uefi boot from http	[Samer_El-Haj-Mahmoud]
0x00 0x10	x64 uefi boot from http	[Samer_El-Haj-Mahmoud]
0x00 0x11	ebc boot from http	[Samer_El-Haj-Mahmoud]
0x00 0x12	arm 32 boot from http	[Samer_El-Haj-Mahmoud]
0x00 0x13	arm 64 boot from http	[Samer_El-Haj-Mahmoud]
0x00 0x14	pc/at bios boot from http	[Samer_El-Haj-Mahmoud]
0x00 0x15-0xff 0xff	Unassigned

These tags as part of the wire protocol for DHCP, along with the URI device path node from the UEFI 2.4 specification, errata B, allow for negotiating this download and informing the network boot program from where it was loaded, respectively. Good stuff. And I look forward to booting UEFI on the Skynet.

Openness and ecosystems also allow for bringing people along in the journey. I was shocked and pleased when one of my overseas colleagues mentioned how to escape from the 'Cathedral', namely a reference to Eric Raymond's book http://www.catb.org/esr/writings/cathedral-bazaar/ on the same. The meme infects technologists regardless of experience or culture, as exemplified by our Friedman'esque Flat World http://www.amazon.com/The-World-Is-Flat-Twenty-first/dp/0374292884.

And you have to innovate. I cannot recall the number of conversations I've had over the years which evolve roughly as follows (I'm the 'technologist' here):

[technologist] 'You can do this feature with open technology.'

[incumbent] 'Don't do that, you'll compete w/ my value proposition.'

Which is sometimes met by 

[incumbent's marketing] 'It's easy to pass someone by when they are standing still.'

Exactly.

Regarding this exchange, the technologist doesn't want to break the cathedral's feature since both parties often work for the same company. But the technologist does observe these business facts to his colleagues, namely that the bazaar has the potential to power this disruption. Given that potential, why not disrupt yourself? I use the analogy of driving down I-5 to Portland. I can mind the fuel gauge and re-fuel when necessary. This entails diligence in observing the physical reality of an automobile. Or I can ignore reality and run out of gas in the middle of the interstate. The fuel constraint is like the competitive technology, you should only ignore at your own peril and 'control' the phenomena as best you can.

In the thick disruption and openness, being open also helps solve the outside-in problem. Sometimes a technologist in the cathedral wants to drive something that the other priests in the cathedral are loathe to support. So the 'outside-in' strategy can include getting customers (i.e,. the 'outside') excited and pulling the internal team (i.e., the 'inside') to respond. This is the less-kind version of  http://knowledge.wharton.upenn.edu/article/outside-in-strategy-for-the-c-suite-put-your-customers-ahead-of-your-capabilities/ since recalcitrant priests may be caught flat-footed to respond to the customer request once the outside-in push accelerates. But by enjoining the outside with open source ecosystems, there is a ready substrate to help the cathedral meet the incoming business request. Essentially the bazaar is the join point and shared infrastructure to evolve technology between partners, such as common open source code into which the cathedral can accrete its features.

The other fact I have realized over time is that everyone has their own cognitive frame and history. This is where the humanities http://blogs.scientificamerican.com/cross-check/2013/06/20/why-study-humanities-what-i-tell-engineering-freshmen/ still have a place in engineering. The arts teach 'how' to think and embrace change. Whether its the questioning of all premises in the spirit of Socrates, realizing the arbitrary language games of many conversations via Wittgenstein, or treating the world with skepticism that is resolved via Popper-like proofs and refutations. Take these words with a grain of salt, of course, as my bachelors degree is in electrical engineering and my masters in computer science. Thus you're reading the advocacy of an autodidact in the humanities, not a lettered representative therein.

And sometimes you just need time to be alone with your thoughts.

And you have to leave your ego at the door. The best advice I received on this point came from Andrew Fish, who once confided in me his secret, namely when you are in the thick of a debate and you realize that you are in the wrong, do the 'flip', or embrace the interlocutor's position. There is no shame in evolving your position in light of additional data. The flip should be done with due care and consideration lest you become a relativist or perceived as wishy-washy, but you must observe the truth when you see it. Part of leaving your ego at the door also includes taking criticism and feedback. You will often be incorrect, or not everyone will love you or your ideas, especially if you are on the wave front of a disruption. And the more you disrupt, the more ire you might draw from your peers and the incumbents.  And following Rumsfeld, "Learn to say `I don't know.' If used when appropriate, it will be used often."

And you must also always tell the truth. My best advice in this vein comes from Mike Richmond: "Never lie, but don't always tell everything." Telling the truth and being genuine eases the burden of having different stories for different parties and having to compartmentalize yourself. You will ultimately succeed on being transparent and delivering value, not on dissimulation and currying favor.

Another piece of advice includes finding the true root cause of an issue. It's quite easy to 'blame' other people, or the ad hominem attack, since the targets are nearly inexhaustible, with the last number I heard pinning the figure at a world population of over seven billion people in 2013. This class of attack sows enmity and reduces your credibility since a barbed tongue replaces truth.  But the technique goes pretty far, especially within companies. Only when existential realities like external market forces or internal resources enter the fray does this technique lose its potency.

Also, I observe that technologists who were most successful in the last disruption have difficulties in adapting to the next trend. I analogize this to the armies in the wake of World War I (WWI). In that conflict, trench warfare prevailed and the best defense devised for future conflicts by the French was the Maginot Line, or an armored variant of a trench covering their border. When World War II occurred, airplanes flew over the line. The quote that is often related to this historical event includes: "generals always fight the last war, especially if they have won it."

In the technology industry, you can imagine the parallels to the Maginot Line. Specifically, the technologist who drove the last disruption may be loathe or unable to address the next one. To me, you should always acts as the challenger, or a recent colleague graduate, with something to prove. The technology industry doesn't respect tenure. It instead demands results. And as Heraclitus said (now we're going pre-Socratic), "you can never step in the same place of a river twice." In the river of technology, that has never been more true than today.

But spotting trends is tough. I recall the exuberance of Gilder's Telecosm.  This hasn't aged as well as Grove's or Christensen's books, I fear. It turns out that the fiber of the Telecosm became the conduit for the web and data traffic that drove the new businesses, such as Google.

And having a network doesn't just include your co-workers. Your network should span other industries and companies - see advice on same at http://www.forbes.com/sites/ricksmith/2014/07/02/5-career-mistakes-you-will-regret-in-10-years/. I still remember my first trek to the Intel Developer Forum where I presented in 2003. The then-CTO of Sun Greg Papadopoulos said in his keynote "All of the smartest people don't necessarily work for your company." Your company does have the smartest people who are both dialed into the road map, strategy and capabilities of that enterprise, though, so I believe the advantage still goes to the company - necessary for success, but typically not sufficient (i.e., the 'if' but no the 'iff'). To close the sufficiency argument (and get to 'iff'), alternate views and help of others, especially in open ecosystems I've described in this posting, are key. As evidence of same, just throughout these recent blog entries you'll find reference to colleagues both within and outside of my company from whom I have had the honor to learn and collaborate over the years.

So you might not always guess right, but by enjoining the community with openness, listening, and reacting to the customer and acclimate market needs, you'll do fine. The tactics might include a pivot, flip, or re-plan, and through all of those actions remain genuine, honest, and work hard.

Speaking of working hard, time to get back into the melee and cease by blog graffiti on the wall of the internet.