Tuesday, December 18, 2012

Sometimes the question arises about accessing UEFI services during the operating system runtime. Recall that UEFI demarcates its core services into boot services and runtime services. The former are only available prior to the invocation of ExitBootServices(), whereas the latter are available during the life of the platform for a UEFI-aware operating system. This is the design intent. Other boot services components can expose content during runtime if said content is allocated in runtime services memory and exposes itself through infrastructure like an installable GUIDed table.

In practice today, these services are not necessarily exposed 1:1 between an operating system services and the corresponding UEFI runtime service.

Beyond variables, though, UEFI interfaces are opaque at OS runtime for Windows. For Linux the UEFI system table is a kernel global object for Linux drivers.

The net result is that you cannot get to the UEFI RT or the system table at OS runtime, I'm afraid. The Linux sysfs is the closest but even there it doesn't expose each UEFI RT call point. The reason that the UEFI variable services are exposed in the fashion they are via Win32 calls is that OS installer programs have needed them since EFI1.02 back in 1999. Writing UEFI RT code is pretty tricky because of things like the OS owning the hardware, the virtual mapping of the firmware, etc.(i.e., tough for firmware folks). Also, the OS guys don't necessarily trust firmware and the UEFI RT code/data isn't hardware isolated from the other OS kernel components and drivers.

As such, the preferred industry approach to having a runtime interface to the platform is ACPI since ACPI runs in a sandbox with an interpreted bytecode AML. There is some interesting open source implementations of ACPI at http://www.acpica.org/, for example. UEFI is great for pre-OS applications and usages, of course. And one model observed today is to stage activities from the OS, such as writing a file to the UEFI system partition, and then rebooting so that an associated UEFI application can act upon the file or directive from the OS agent.

Of course, UEFI runtime services are always available in the pre-OS, namely during the boot services (BS) phase.

5/22/14 update-
Regarding the protection of the platform resources by the OS, you need to have administrative privileges in Windows and Linux in order to access the OS API's that abstract the UEFI variable interface from user-land code.

11/5/14 update -
if you boot via Int19h PC/AT BIOS process, the UEFI runtime memory is given back to the OS and is reported as available via the memory map call in E820h Int15h call. As such, there is no way to invoke Get/Set Variable from a PC/AT "Legacy" BIOS boot.

Tuesday, December 4, 2012

Recall that the UEFI Forum (www.uefi.org) governs several specifications. The first is the main UEFI specification which serves as the contract between the platform firmware and several pre-OS components. The latter components include pre-OS applications, drivers, OS runtimes. The other specification under the aegis of the UEFI Forum is the platform initialization, or "PI" specifications. These five volumes describe interoperability between components that comprise the construction of the platform firmware, including the Pre-EFI Initiation (PEI) phase and the Driver Execution Environment (DXE). For both the UEFI and PI specifications, major specification releases entail updates to functionality and capabilities. A fortiori, such changes entail updates to the version fields in the various services tables, such as the UEFI System Table for UEFI and the PEI, DXE, and SMM services tables for PI, respectively. These service table revisions allow for software to detect the variant of a given platform firmware in case a certain service has evolved modal behavior or to ascertain if a certain capability exists.

With all that in mind, evolution of the UEFI and PI specifications can also occur via the errata process. If you think of the major specification updates to be a forward direction evolving process, the errata process is more lateral in that it clarifies issues within a given set of specifications without introducing interoperability issues. This interop issue is important in that there is no software discernible difference between various implementations of errata for a given UEFI or PI major version, so such changes cannot be probed by software via the version number conceit listed earlier.

Finally we get to the point of this blog posting and the PI 1.2.1a specification. The 'a' suffix means that this revision of the specification consists of the first errata against the PI 1.2.1a specification. Recall that the PI 1.2.1 specification was released on May 2, 2012. The PI 1.2.1a specification, in turn, was released on October 26, 2012. This five month cadence is not unreasonable, with the most frequent errata cycle being once per quarter if there are sufficient bugs to address.

The creation of errata allow for consistency in the software definitions. This, along with conformant implementations of the UEFI and PI specifications at http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=EDK2, provides an evolution of the platform firmware between the addition of new features and capabilities in major specification revision updates.

Tuesday, October 23, 2012

Hat's off to Scott. Like all of my IP adventures, I enjoy the human, collaborative aspect most of all with my co-inventors. And what a list of co-inventors, from recent-college graduates to Intel Senior Fellows, from North America to the near East and the far East.

I won't opine on the alternate perspectives regarding the need or value of patents promulgated by the various voices spanning the meat space to cyberspace. To me patents are a business fact in the modern, knowledge-driven economy of the 21st century, and I am a small cog in this economy.

Luckily the name "Vincent Zimmer" is unique enough in the patent realm to allow direct hits on the USPTO queries. This is especially important since a few cases omit the assignee company and other data that would allow for a more specific query string.

So how does this activity relate to the rest of the US patent-filing population?

According to Michael Orlando, an economist for the Federal Reserve Bank of Kansas City“40 patents per year are developed within a population of 200,000. In 2006, the patent office received 443,652 patent applications, but only 183,187 were issued that year.”

From Orlando's figures, one can see a 183,187/443,652 or 41% approval rate.

From the queries above to the USPTO, I'm at 251 issued and 453 abandoned, issued or active cases. This gives a rough metric of 251 / 453 = 55% approval rate, which is slightly better than the 2006 average of 41%. Given the number of cases in play on my list, including cases in that 18 month window of filed but not public, this isn't an exact number. But it's probably in the neighborhood of where the metric will converge over time.

The size of the applications can range from eight to 20+ pages. Assuming an average size of 10 pp., that makes 4500 pages of application data alone. What a formidable number for my troubled memory.

Seattle definitely has more public technical talks than the South Puget Sound area. The day after the IP talk, the same venue, namely the Bellevue Court House, hosted the October Seattle Meet-up on Cloud Computing. I was the third speaker, after the Citrix and Microsoft talk. As you can read from http://joewlarson.com/blog/2012/10/20/cases-of-network-tech-stf/ this eastside crowd was a bit higher in the software stack than I'm used to dealing. The blogger captured my angst, with the associated Rodney Dangerfield foil 4 https://docs.google.com/file/d/0BxgB4JDywk3McWhfX0ZlSk03bkE/edit with his observation "Zimmer explained that the BIOS had an awkward place in technology, because hardware guys tend to think of BIOS as software, and software guys think of it as hardware."

As such, I sometimes wonder if the complaints over software patents even apply to my vocation in the land of firmware.

Going forward.

I'm getting old. I filed my first patent at 20 when I was an intern at Texaco. I never followed up on the office action and USPTO application records are not available prior to 2001, so this item is lost in the sands of time. My IP activity picked up in the late 90's, with the following run of issued US cases:

1999 - 1

2002 - 1

2003 - 1

2004 - 2

2005 - 2

2006 - 22

2007 - 46

2008 - 40

2009 - 36

2010 - 44

2011 - 34

2012 - 22

This is less interesting since the latency from filing to issue can span from four to nearly ten years. The more interesting data is number of filings per year.

To that end, the application publications per year have progressed as follows:

2002 - 4

2003 - 6

2004 - 60

2005 - 86

2006 - 63

2007 - 55

2008 - 57

2009 - 59

2010 - 21

2011 - 20

2012 - 22

Definitely not Gaussian. More of a long-tail Pareto style distribution.

Well, enough on this topic. 250 is a strange number. Not sure if I'll reach 300, more less a 4-digit number. Nevertheless, it has been an interesting run.

I'll close with a quotation from Ralph Waldo Emerson, “Life is a journey, not a destination.”

Sunday, October 7, 2012

At the last Intel Developer Forum in San Francisco, Intel's futurist David Brian Johnson talked about the Tomorrow Projects http://www.tomorrow-projects.com/. I downloaded one of the related texts from David's works, namely Science Fiction Prototyping. The book talks about Science Fiction and how it contributes the the "future casting" efforts. The quote that I took away from the book that inspired this blog entry, though, was how many of the pioneers in aeronautics were inspired by the science fiction of Jules Verne. For me, the book that inspired my pursuit into electrical engineering, and then the computing sciences, wasn't from the genre of science fiction so much as science fact. Specifically, I recall Norbert Wiener's Cybernetics as the text which fused an information theoretic view of the world, including control theory, as an inspiration.

I would be curious whether others had a specific book or author that inspired their professional pursuits.

Starting with a scientific degree doesn't necessarily guarantee a successful engineering career, either. In fact, one of the best programmers with whom I've had the pleasure to work during my early career didn't even have a degree in computer science or engineering. Instead, he was an ex-Marine who afterward joined the Trappist order in Gethsemani http://www.monks.org/ for ten years, studying Heidegger's Being and Time while observing the silence and working in the fields. After leaving the order he returned to Houston and picked up a bachelors degree in philosophy.

Thursday, September 20, 2012

I'm back to the (still) sunny Pacific Northwest from the Intel Developer Forum (IDF) in San Francisco. Roy Hopkins & I presented on UEFI and McAfee EEPC. The presentation can be found at https://intel.activeevents.com/sf12/scheduler/catalog.do "Intel and McAfee: Hardening and Harnessing the Secure Platform" session EFIS003. As an "Advanced" course, we stayed away from generic feature overviews and spent most
time in design issues and code examples, including how a key logger could
afflict a pre-UEFI Secure Boot system. Some best practices for system design and coding were reviewed with the goal to follow-up w/ a document detailing this advocacy for posting at www.tianocore.org.
Looks like I was premature calling September the end of the speaking circuit. I will present at the Seattle Tech Forum on 10/17 along with speakers from Citrix and Cloudant on "Cases of Network Technology." More details can be found at http://www.meetup.com/Sea-Tech-Forum/events/36852802/. This meetup goes out to about 20k technologists in the Seattle area, so the subset of that list who show up in person should prove interesting. During my session, I will discuss the state of the art in UEFI pre-OS networking and security.

In addition, I will travel to down to the backyard of Intel, namely the Portland area, to talk about UEFI Secure Boot.

Speaking of UEFI Secure Boot, the Register picked up the posting http://www.itsec.it/2012/09/18/uefi-technology-say-hello-to-the-windows-8-bootkit. Akin to many earlier presentations, from John Heasman in BlackHat 2007 to Loukas K's BlackHat 2012 talk, they all conclude with the sentiment that UEFI image signing is a good idea. For Heasman, his advocacy antedated UEFI Secure Boot, but Loukas K and the ITSEC posting all advocate UEFI Secure Boot as part of their mitigation recommendations to address attacks against arbitrary UEFI code extensibility.

The dialectic isn't too complicated, IMHO, once the case is plainly stated. Here's the Q/A I'd like to have with the alarmists on this topic-

Question: What is UEFI?

Answer: UEFI stands for the “Unified
Extensible Firmware Interface,” a software interface to the platform
for booting operating systems such as Linux and Microsoft Windows. Along with
the Advanced Configuration and Power Interface (ACPI), UEFI abstracts away many
of the platform hardware details from the operating system.

UEFI software interfaces are codified in the UEFI Specification,
which is presently at version 2.3.1c. That specification is owned and
evolved by the UEFI Forum, an industry group that includes OS vendors (OSVs),
independent hardware vendors (IHVs), independent BIOS vendors (IBVs), original
equipment manufacturers (OEMs), and independent software vendors (ISVs).

Question: What is UEFI Secure Boot?

Answer: UEFI Secure Boot
entails a set of technology elements that apply policy for loading UEFI
executables, including applications and drivers. These elements include
the Platform Key (PK), the Key Exchange Key (KEK), the allowed database (db),
and the prohibited database (dbx). To provide access control, these objects are
stored in something called an authenticated variable, which is a class of UEFI
variable that needs to be cryptographically signed to update the
contents. These keys contain policy about who can update things and what
code can run.

UEFI is all about loading images, the most important being the
OS loader. With UEFI Secure Boot, the UEFI images are signed using
Authenticode, or an embedded signature format inside of the PE/COFF
executable. Authenticode and PE/COFF are the same cryptographic signature
and image encoding used by Microsoft Windows.

Question: What was the world like
before UEFI Secure Boot?

Answer: Prior to UEFI Secure Boot,
the UEFI firmware would load any well-formed UEFI executable found in an
adapter card, the EFI System Partition on the disk, or from across the
network. With the addition of UEFI Secure Boot, the UEFI firmware now will
assess the UEFI executable to see if it “meets policy.” This policy
includes if the image is cryptographically signed used asymmetric cryptography
such as public/private keys, whether the signature verifies to another key in
the allowed list, and whether it’s on the prohibited list.

In a sense, UEFI Secure Boot is a simple form of managing and
enforcing a white list of “good” and “bad” UEFI drivers and applications. This
allows the system board vendor or owner and other authorized parties to manage
which software publishers can execute content on a platform.

Question: Why is it important to the
industry?

Answer: At the highest level,
security is an important facet of platform deployment, along with
compatibility, usability, performance, power and other capabilities. In
the context of UEFI, Secure Boot helps support the general roll-out and mass
deployment of UEFI-based technology in the market. A platform owner can
leverage UEFI to defend the platform and operating systems from malware and
other software attacks.

To see why this is important, recall that the “E” in UEFI stands
for “extensibility.” Extensibility acts as a two-edged knife: on the
bright edge of extensibility, a UEFI-conforming platform can “just work” with
executables that conform to the construction and API rules of the UEFI
specification. This allows for shrink-wrap operating system vendors to
write one loader (Windows loader, Linux loader), or an IHV one boot driver
(NIC, GFX, Storage adapter), or an ISV pre-boot application
(diagnostic/provisioning), for a given micro architecture (Itanium, IA32, x64,
ARM).

On the dark edge of the UEFI knife, a permissive load policy of
“any UEFI executable” as featured in the UEFI specification circa 2006 might
allow bad actors to add and run content on the platform. Since UEFI
executables can be introduced via a pluggable PCI card, a possibly hostile
network, or from a disk that UEFI cannot protect after booting to an OS,
there’s a rich set of attack vectors. This class of attack against the
boot process is known in the security community as a “boot kit.” Such kits
for both UEFI-based and PC/AT BIOSs exist today. And, as operating systems and
hypervisors grow increasingly robust, malware and viruses are moving earlier in
the boot and into the platform. UEFI Secure Boot provides a policy
based control for the Extensible code elements within a UEFI pre-OS
environment.

Answer: No. The UEFI
Specification only reads on the mechanism. End-user controls and
choice of operating system, such as enabled via Custom Mode screens to add
additional keys, are provided in UEFI-based products. UEFI Secure
Boot is not an ‘attack’ on the compute ecosystem so much as a ‘prevention’ of
wounds on the compute ecosystem that the dark side of UEFI’s extensibility may
inflict.

Microsoft’s
announcement that new computers shipping with Windows 8 pre-installed must be
certified in UEFI mode has made the industry move fast to migrate all platforms
to this firmware architecture. Today there are both ARM- and Intel Atom-based
smartphones on the market that use UEFI, and in the x86 space products ranging
from laptops to high-end servers now expose their UEFI interface.

If you have
started porting your products, including development-, testing-, validation-,
and integration-tools, as well as your custom pre-OS applications, to run on
UEFI you are on your way to take advantage of this migration.

If you still are
focused on legacy BIOS, or other boot firmware, it is time to start the
migration, and it is getting urgent.

In either case
Techstream® can help you get to UEFI faster and easier.

We have the
experience: Over the last 15 years, we have delivered hundreds of Tiano,
UEFI PI, UEFI architecture, and legacy BIOS courses all over the world, and to
virtually all major players in the industry.

Our current
firmware-related offerings are:

Tiano and UEFI
Architecture.
Most UEFI implementations on x86-64, ARM, and Itanium use the highly flexible,
modular, and platform independent, architecture defined by the UEFI Forum’s PI
(Platform Initialization)Specification, based on the early
stages of Intel’s Tiano architecture.

This course
takes you through all of the UEFI PI’s and Tiano’s phases and
interfaces. For the full outline, please go to www.techstream.com/209.htm.

Sunday, August 26, 2012

Back fromToorCamp, 2012. To get a sense of the event, check out the closing video
http://www.youtube.com/watch?v=Q7IeJ0HGK6o. Here are a few pictures of the camp I snapped on my phone, including the dome in the distance.

The camp site was right next to the beach, too. Neah Bay is the northwest-most point of the continental US, so the Pacific Ocean formed the back yard for the talk.

The main dome hosted the various talks. Here's a closer view, including the podium in the back:

I delivered my talk on firmware security on Thursday afternoon. A link to my foils for

“UEFI Secure Boot and challenges in platform firmware” can be found at https://docs.google.com/open?id=0BxgB4JDywk3MWnM0WmNXMHBTcm8. The other talks were a mix of information security and the maker movement leading up to my presentation, so I treated my discussion of firmware security alongside a a review of the UDK2010 open source implementation of UEFI Secure Boot and the user controls enabled via Custom Mode on IA32 machines. Insightful questions both during the talk and with the researchers afterward.

Other interesting talks included Dan Griffin's discussion on TPM's and UEFI, which largely focused on measured boot from the operating system perspective. This talk was a shortened version of his DEFCON talk https://docs.google.com/file/d/0B7n3jaMQDSNCeDJBd2tnRGIxbDA/edit#. Dan Kaminsky also spoke about all things security, including weaknesses of random number generators http://dankaminsky.com/2012/08/15/dakarand/. Other interesting perspectives from DanK included how type safe language are not the security panacea since different machine on the network are written in different languages, so all communications must convert data to strings. And it is in these strings that attacks, injections, and vulnerabilities occur. Hearing both Seattle Dan's speak alone was worth the trip.

Overall, I enjoyed having the opportunity to participate in this type of conference. The spirit of creation, invention and curiosity was infectious and shared by all. And the accommodations were quite interesting, too.

Next stop is the Intel Developer Forum in San Francisco on September 10. I suspect that my hotel will be a little further detached from Mother Nature, though.

along with a review of the implementation at tianocore.org. I provide an overview of some of the material in the paper at the toorcamp talk next Thursday near Neah Bay.

Roy Hopkins of Intel/McAfee and I https://intel.activeevents.com/sf12/scheduler/speakers.dowill be presenting Intel and McAfee: Hardening and Harnessing the Secure Platform on Tuesday, September 11, at the Intel Developer Forum in San Francisco, CA. The topics will include:-UEFI and Platform Initialization (PI) security overview-Hardening the platform and development assurance practices-Introducing McAfee* Endpoint Encryption-Value proposition of a secured preboot-Maintain the chain of trust.I look forward to meeting people in SF next month.

Wednesday, July 4, 2012

These include the publication of errata C of the UEFI2.3.1 specification at www.uefi.org. One interesting update in that document includes support for network booting additional architecture types. See "Processor Architecture Types" at
http://www.ietf.org/assignments/dhcpv6-parameters/dhcpv6-parameters.txt. Notable additions in that list include PowerPC and ARM64, along with reconciling some earlier conflicts between the UEFI specification and early RFC's. This update, along with http://tools.ietf.org/rfc/rfc5970.txt, allows for rich network bootstrap opportunities.

In addition to the UEFI and IETF updates, a YouTube video of "Security & Personal Computing" was just posted to the intelchannel at http://www.youtube.com/watch?v=lZ505uz1TZ4. In this talk I provide a broad overview of some the efforts underway in the industry around platform protection.

Friday, February 24, 2012

Today makes 15 years since I started working at Intel. Coincidentally, it also makes 20 years for me in the technology industry (post undergrad).

I worked on my first embedded systems project 20 years ago, converting an embedded control system from assembly to C. And during the last 12 years on the EFI project, work has included converting a PC/AT BIOS ecosystem largely written in 16-bit assembly to a C-based infrastructure based upon UEFI.

Crazy stuff.

I've heard that the half life of an engineer is 15 years. I look forward to where the journey takes me next.

Tuesday, January 10, 2012

This is the latest UEFI Development Kit 2010 Specification Release 1 (SR1) that supports UEFI 2.3.1 and the PI1.2 specifications. The UDK2010.SR1 Release is now available at http://www.tianocore.org. Many of the capabilities discussed earlier in the blog, including netboot6 and secure boot, are available in the Networking Package (NetworkPkg) and Security Package (SecurityPkg), respectively.