Tuesday, December 18, 2012

Accessing UEFI from the operating system runtime

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.

For Windows, the only API that I know of for accessing UEFI entail the UEFI variable services.   Check out Get/Set firmware environment variables services http://msdn.microsoft.com/en-us/library/windows/desktop/ms724934(v=vs.85).aspx and http://msdn.microsoft.com/en-us/library/windows/desktop/ms724325(v=vs.85).aspx, respectively.

Linux provides access to the UEFI variable services through sysfs, too.  Some detail can be found at 

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.

3/10/14 update-
Windows now has kernel-mode variants of its access API's http://msdn.microsoft.com/en-us/library/windows/hardware/jj151553(v=vs.85).aspx and there is a nice description of variable access from Linux at firmware.intel.com/blog/accessing-uefi-variables-linux

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

Errata, PI1.2.1a and all that

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.

For PI 1.2.1a specification, the errata includes the following:

- Adding a 'boot with manufacturing mode'
- Addition of a simple signed firmware volume and file
- Clarification of memory usage across the S3 boot path
- Root handler processing clarification in SMI

and other clean-up.

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


This Tuesday I received my 250th US Patent.   

Vincent Zimmer, Scott H. Robinson, “Methods and Systems for Microcode Patching,”, Issued 10/23/2012, US Patent #8,296,528

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.   

When confronted by patents, like other phenomena in life, I first try to understand the item prior to making a value judgement.  As such, putting intellectual property law in a historical perspective provides one vantage for achieving additional insight. And to that end, I'm 1/3 of the way through Robert Merges Justifying Intellectual Property http://www.amazon.com/Justifying-Intellectual-Property-Robert-Merges/dp/0674049489/ref=sr_1_1?ie=UTF8&qid=1351049499&sr=8-1&keywords=robert+merges.   I'm in the thick of the Kantian versus Lockean view of property rights, but I am finding it increasingly difficult to find the time and focus to wade through the tome.  

So how to make sense of the morass of patents.  For international patents, Espanet and the query 
provides a compendium of my activities in the US and overseas.  I find it difficult to wade through the results given the amount of output and the query options.

The calculus is a bit easier in the United States, with the US Patent and Trademark Office (USPTO) having a couple of useful interfaces for applications that were published at least 18 months ago http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.html&r=0&p=1&f=S&l=50&Query=in%2F%22Zimmer%2C+Vincent%22&d=PG01 and issued cases http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=0&p=1&f=S&l=50&Query=in%2F%22Zimmer%2C+Vincent%22&d=PTXT.

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.  

The law is definitely fluid. This month there was an interesting update on IP law and what it means for technologists.  You can find the slides for the Tuesday Oct 16,2012 IEEE Seattle Communications Chapter presentation "Evolving Standards of Patent Eligible Subject Matter" at https://skydrive.live.com/?cid=b47e69a64974ad21&id=B47E69A64974AD21%21123#cid=B47E69A64974AD21&id=B47E69A64974AD21%21168

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

Did a book inspire your choice of a profession?

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.

What does philosophy mean for tech?  Consider the fact that most smart phones of 2012 can hold the equivalent of the Library of Alexandria.  But what do most most people use their devices for? Cat watching, such as http://www.youtube.com/watch?v=jI-kpVh6e1U&feature=relmfu and http://www.lolcats.com/.  Why not download from http://www.gutenberg.org/? As such, studying the philosophy and the meaning of existence doesn't sound like such a bad idea.

Now go back to work and/or read a good book.

From the earlier blogs, here's a quick update.  The SF IDF presentation has an audio link at http://intelstudios.edgesuite.net/idf/2012/sf/aep/EFIS003/EFIS003.html.   And for the http://pdxlinux.org/ talk, the presentation is posted to https://docs.google.com/open?id=0BxgB4JDywk3MbENUTVdqZkZaUmM   and watch the pdx website for the video to be posted.

Thursday, September 20, 2012

Late September mumbling

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.

      October 4th, 2012

      UEFI Secure Boot and Open Source. 
      It's not a 'general war against computation.' 

More details can be found at http://pdxlinux.org and http://calagator.org/events/1250462851.   Judging by some direct messages from some of the possible attendees, it should prove to be an 'animated' meeting.

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.
Question: Is this locking out the user and a salvo in the “war against computation” http://www.softwarefreedom.org/blog/2012/jan/04/doctorow-ccc-keynote/?
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.
For more information on UEFI Secure Boot, see
Chapter 27 of the UEFI 2.3.1c specification www.uefi.org

Magnus Nystrom, Martin Nicholes, Vincent Zimmer, "UEFI Networking and Pre-OS Security," in Intel Technology Journal - UEFI Today:  Boostrapping the Continuum, Volume 15, Issue 1, pp. 80-101, October 2011, ISBN 978-1-934053-43-0, ISSN 1535-864X  


Friday, August 31, 2012


I received this mail recently

From: Anders Amundson [mailto:anders.amundson@techstream.com]
Sent: Thursday, August 23, 2012 1:05 PM
To: Zimmer, Vincent
Subject: UEFI, BIOS, Tiano, and PC Architecture Training

Dear Vincent,

The transition to UEFI is happening fast.

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.

I think that I'll pass.


Sunday, August 26, 2012

One conference down, one to go....

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.

On top of the great info-sec talks, on Friday I had the opportunity to attend a session by George Dyson http://en.wikipedia.org/wiki/George_Dyson_(science_historian) on Project Orion http://en.wikipedia.org/wiki/Project_Orion_(nuclear_propulsion)

And speak with George afterward.
I was as much inspired by his discussions of Orion, my read of his recent book on the history of the computer http://www.amazon.com/Turings-Cathedral-Origins-Digital-Universe/dp/0375422773, and of course, kayaks http://www.amazon.com/Baidarka-Kayak-George-Dyson/dp/088240315X/ref=sr_1_4?s=books&ie=UTF8&qid=1346014068&sr=1-4.   Regrettably, the only hard copy of a book related to  George I brought along to the camp was the book 'about' George and his father Freeman http://en.wikipedia.org/wiki/Freeman_Dyson
But I asked for an autograph anyway.

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.


Saturday, August 4, 2012

A recent whitepaper posted and an upcoming talk

A Tour Beyond BIOS into UEFI Secure Boot at the download location http://sourceforge.net/projects/edk2/files/General%20Documentation/A_Tour_Beyond_BIOS_into_UEFI_Secure_Boot_White_Paper.pdf/download was recently posted.    My co-author Lee Rosenbaum and I provide a integrity model for an extensible pre-OS that motivates UEFI Secure Boot

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.do will 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

UEFI 2.3.1 Errata C, and more

A few things have happened recently.

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.

On that same topic, my presentation proposal http://toorcamp.org/content12/33 for ToorCamp 2012 was accepted.   The entire schedule of talks can be found at http://toorcamp.org/talks.  Dan "I broke DNS" Kaminsky is speaking that same day http://toorcamp.org/content12/28, and the speaker immediately prior to my talk http://toorcamp.org/content12/2 will discuss hacking measured and UEFI secure boot.   It should be interesting.

Friday, February 24, 2012

Anniversary day

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.

It has been an interesting run thus far.


Tuesday, January 10, 2012

UDK2010.SR1 is now available

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.