Thursday, February 9, 2017

Specifications and a New Book

I recently came across which reminded me of the world of firmware. Specifically, there is an interplay of de jure standards, such as the UEFI 2.6 specification, and then de facto standards, including open and closed source behaviors.

I'll give a quick example where these two venues collided. Specifically, during the drafting of the UEFI 2.5 specification, there was an operating system request to make the UEFI run time code produced in a way such that the hypervisor or OS could apply page protection. Recall that UEFI runtime code and data are co-located in ring 0 with the OS kernel. This change entailed several things, including the OS making the UEFI run time code read-only and the data pages non-executable. To that end, the EDKII was updated to align the UEFI runtime driver sections on a 4KiB boundary and not merge the code and data pages. In addition, the UEFI memory map was updated to have a memory descriptor for each code and data page, creating several descriptors for each UEFI runtime image, versus the former behavior of having one memory descriptor for the entire set of PE images.

We codified this behavior in UEFI 2.5 with the memory properties table

This bit let the OS know that the code was factored into these separate pages and validated by the firmware producer to be truly pure code and data (e.g., no self-modifying code). This was a de jure UEFI 2.5 specification addition.

What happened?  Namely, why did we move to the EFI_MEMORY_ATTRIBUTES_TABLE in UEFI 2.6 and add language to the specification?

After publishing the 2.5 specification and upstreaming patches responsive to this properties table, many OS kernels started to crash. Uh oh.

What we learned was that when OS kernels invoke SetVirtualAddress to map the UEFI runtime entries from a 1:1 pre-OS setting to a non-1:1 OS kernel mapping, the relative distance between entries were not preserved. This didn't appear in earlier implementations since one memory descriptor covered a single image. In fracturing the single descriptor covering the PE image into multiple entries, the un-documented requirement to keep relative offsets between sections of a PE/COFF image during the SetVa call was surfaced.  We essentially discovered a de facto requirement to have a single descriptor covering a single PE/COFF image.

Thus the change in the UEFI 2.6 de jure specification to have an 'alternate' table to the UEFI memory map (e.g.,  EFI_MEMORY_ATTRIBUTES_TABLE) and maintain the single descriptor per image given the circa 1999 and beyond OS's and their SetVa expectations.

This new attributes table is also called out in some OS requirements

This doesn't moot the value of the de jure specification, of course. OS and device vendors appreciate standards so that long-term support (LTS) variants of the OS can have an expectation that platforms produced during the support lifetime, such as 10 years, will be compatible. Given the complexity of modern system, the de jure specification cannot always cover all of the system details. Thus the value of open source and products providing some de facto standardization, too, to complement the formal standard.

Speaking of industry standard firmware and code, I'd also like to let people know that the "Beyond BIOS" book is now available at and Since the original publication in 2006, many things have changed, including scaling of the industry standards efforts, but the basics remain the same.  And those areas that have evolved are deftly treated in the updated text.

This book serves as a good launching point for someone just diving into the world of industry standard firmware. I was happy to have the opportunity to work with my old friends and co-authors Mike Rothman and Suresh, along with new friends like Jeffrey, Megan, and others from De Gruyter. De Gruyter also allowed for me to share a sample chapter, too.

If you have the time please take a look.

And interactions of modern systems don't always behave as expected, too.

You can learn more about the UEFI Shell, which is nicely staged in the picture above, in a update of the UEFI Shell book later this year

Thursday, January 12, 2017

Whose bug is it?

My favorite quote from chapter 1, page 1 of includes "'If you can fix a hardware bug in firmware, it’s not a bug but a documentation issue.'  —An anonymous hardware manager." I still recall being aghast upon hearing that utterance early in my career, but over time I grew to understand the wisdom. In fact, this inaugural chapter from 2015 book further elaborates on work-around's of hardware concerns that can be implemented in firmware.

This same sentiment was echoed in the position paper and presentation for the 2010 IEEE International High-Level Design Validation and Test Workshop. Specifically, the firmware can be modified at the 23rd hour to fix a work-around in hardware, leading to a potentially long list of 'firmware changes' during a product's postmortem. This sentiment is expressed in 'Incentives to fix issues in firmware cause root cause to be commonly incorrectly assigned to firmware' of the presentation and the following section of the paper:

      "There could be confusion between the root cause and the fix
      for issues. In particular, there is great pressure to resolve
      hardware issues in firmware due to the order-of-magnitudes
      difference in the cost of resolution. A “spin” of a chip may
      take many weeks and cost millions of dollars whereas a
      firmware fix may cost a few thousand dollars and a day or two
      of total work. In fact, many modern chips are designed so the
      firmware can configure the chips to work around issues in the
      field rather than having the hardware recalled. The public is
      simply told that there is a firmware issue when, in fact, the
      firmware resolved what was a hardware issue. "

I also recall being given a harried call on a Friday night about a the number of 'firmware bugs' on a product. I replied to the caller with some of the sentiments above, including the caveat 'I think that we can get the firmware update out by Monday, but I don't believe we can get a new stepping of the SOC by then.' Regrettably programs don't roll up the reason for the firmware changes and people are just shocked by the cardinality.

And often these bugs are not easy to find Bohrbugs, but Heisenbugs or Hindenbugs where there is a subtle interaction between host firmware and opaque hardware state machines. A week of investigation may yield a solution wherein one line of code changing one bit in a register access yields a solution. A few months ago a firmware manager at a conference related to me that the promotion process in his company entailed upper management reviewing the Git commits of the engineers. The firmware manager had to defend the smaller number of code changes versus the OS kernel guys as each delivering similar business value. But I still recall the final quote from the manager when he smiled and said 'The coolest part is that they are reviewing code changes, right?'

Sometimes these work-around's mitigate errata in the hardware (board, silicon, etc), and sometimes the changes are for cost savings. An example of the latter I recall includes a board design where the integrated Super I/O could be decoded as I/O addresses 0x2E/0x2F or 0x4E/0x4F by application of a pull-down or pull-up resistor, respectively. The hardware design engineer omitted the resistor in order to save costs on the Bill of Materials (BOM), so the boot firmware had to probe for what port value being decoded on each machine restart. And this was a cost savings of a single surface mount resistor.

The above discourse isn't meant to be an apologist view about firmware bugs, though. In general there are many bugs based upon programming flaws, not just hardware work-around's. If one is interested in the latter, take a look at But hopefully this posting will provide an alternate view into firmware and firmware changes.

Sunday, January 1, 2017

Saying good bye to 2016

I meant to do a final blog of '16 but I instead opted to catch the fireworks at the Seattle Space Needle

I like the end of the year as it hosts the Chaos Communications Conference (33c3). I recall seeing Trammell Hudson's Thunderstrike 2 over the '15 holiday, and for this '16 holiday I watched his talk on Heads, variously described in

I like Trammell's threat model write up at, too. Today we only have the higher level

It was interesting to see his mention of Intel (R) FSP and also reference our work on pre-OS DMA protection

Another talk of interest for the pre-OS was the review of porting UEFI Secure Boot for virtual machines This entails the Open Virtual Machine Format (OVMF) variant of EDKII that executes upon QEMU and is used as the guest firmware in projects like KVM, Virtualbox, etc.

The latter talk included a reference to the EDKII lock box
work and emulating the full System Management Mode (SMM) infrastructure. The addition of more of the SMM infrastructure in was positively mentioned, too.

Speaking of security and 33c3, an interesting read about researchers and industry was posted to As long as the flaws are responsibly disclosed such that the conference presentations aren't zero-day events, I cannot argue with their sentiment.

One common element discussed in Heads and the Virtual Secure Boot topics entailed availability of full platforms. In that area there is great progress in having a set of full EDKII platform code in source that works with an Intel(R) FSP for the embedded Apollo Lake (APL) SOC (formerly known as "Broxton") in the repository

Regarding security and treatment of EDKII issues, we have moved our advisory update to gitbook from the former two PDF postings These recent postings represent fixes that honored the industry request for six month embargo of the project updates. Going forward we'd like to auto-generate the advisory from Bugzilla, but for now the document is manually curated. There have also been discussions of moving from the advisory document issue enumeration to things like CVE's which is an investigation in progress, too.

Moving into 2017, maybe I'll catch up to George Westinghouse's number of issued US Patents. I left 2016 with 354 issued, whereas George has 361

2017 should also feature an update to a couple of UEFI books, including Beyond BIOS and Harnessing the UEFI Shell Beyond BIOS was originally published in 2006, so this update will mark over a decade since its first appearance.

It has been an interesting run on this project, with over 17 years on the EFI team and nearly 20 years at Intel. I look forward to what the next wave of technology will bring in '17 and beyond.

Tuesday, December 13, 2016

Provisioning, Porting and Types

I'd like to begin this posting with a review of work presented years ago. Specifically, my friend Harry H provided me copies of my first three Intel Developer Forum (IDF) presentations from 2003 and 2004, respectively.

The first presentation was jointly delivered with Bob H and Michael K. This work informed some of the information in chapter 7 of the UEFI Book. The basics of the architecture haven't changed, with the notable exception of advocating the use of Intel(R) FSP and associated marriage with open source platform code on

That same 2003 event featured a solo talk on security features This talk included an introduction of the modular network stack which we internally ear-marked for a never-released "EFI 1.2" specification. These API's on slide 15 ended up appearing in the UEFI 2.0 specification circa 2006 and later in the open source Beyond these API's, though, other elements like the EAP-Teanie method were never realized in the market. The best documentation of the latter appeared in a paper on using UEFI in the Cloud on pp. 4-5 Custom EAP methods violate the design precept of UEFI, namely leveraging well-known art, including authentication methods. Thus the recent focus on TLS for HTTP-S and EAP-TLS for our various network use-cases.

From 2004, other items that landed on the cutting run floor included the EFI_SECURITY_SUPPORT_PROTOCOL on page 20 of the presentation. In the ensuing ten years I attempted to standardize an interface like this in the standards body, but we have ended up instead with a library class which can be layered directly on a static library such as OpenSSL or a private protocol. Finally, the pp 23-24 "COB's" of the EFI_CONFIGURATION_OBJECT_PROTOCOL never appeared in the open source or the standards, but the configuration aspects of slide 30 finally appeared in the UEFI standard from the original OEM-scoped HII Framework standard

So much for IDF in 2003. In 2004 we presented on EFI Security extensions again in In this talk we elaborated on the 2003 talk with more details, including slide 17 for PE/COFF EFI image integrity. Since that talk we have evolved a UEFI image integrity model in (2007), (2011), and (2012).  Same story on the rest of the vision, though. The vision of smart objects like COB's was not realized in the market.

A common theme on the IDF 2003 and 2004 presentation was the topic of provisioning, though. With the UEFI 2.6 specification, x-UEFI, and HTTP boot, the vision has been realized in a different figuration in 2016 As such, I can claim the ball has been moved down the field in the last decade.

Another topic that perhaps hasn't progressed as much in the last decade entails language-based security (LBS). Back in the early 2000's I investigated how technology like might be applied to the EFI firmware, including a failed port to That's why I am excited to see efforts like, including the write up These efforts show promise to complement other security efforts in this space. I also enjoyed the reference in the latter paper to the EFI memory map white paper, UEFI book, and Cloud presentation. To me this affirms the value of openness, from publications down to the source code, in evolving an ecosystem.

Another interesting intersection of Rust and system software is which a colleague at a nearby company mentioned to me over lunch. I need to dig into this work in the future.

Speaking of ecosystem evolution, I also want to cite our write up on the recently upstreaming capsule design If this paper work were to have pre-dated the Rust paper perhaps it would have been the capsule reference in lieu of the "BZ15" one? This latter white paper reads on 'platform recovery,' such as described in the UEFI PI specification. As a complementary overview of operating system (OS) recovery there is which explicates some of the technology in the UEFI specification and touched upon by me at the last UEFI plug fest.

Now off from working in an urban area

to a more suburban office

I'm not sure which is spookier.

Well, enough of looking in the rear-view mirror today. Let's instead face the wind screen and continue forward down the road.

Wednesday, November 23, 2016

Conferences, Forums, and Writings

It has been some time since I touched this blog. Thanks to Lee F. for his recent email bump "the blogosphere misses you" for reminding me of gap. I'll try to play a bit of catch up with today's posting.

I also need to refresh my postings to but I have to admit that I prefer the Blogger interface - it auto-saves the content, it doesn't ask me to update my password every time I log in, it's easy to important graphics,....

And I'm really glad to see Tim Lewis blogging again He's one of the most talented guys I know in this industry and I enjoy reading his postings almost as much as I enjoy talking with him in person.

Regarding Tim's blog, he described the recent UEFI Forum publication of the PI 1.5 specification The most notable update is the generalization of the System Management Mode (SMM) software model in volume 4 to the "Management Mode" or "MM" model that can accommodate both ARM TrustZone (R) (TZ) and IA32/x64 SMM. Historically we didn't unify the Itanium PMI software model with SMM since the former didn't offer the curtained execution model of both SMM and TZ. There are many commonalities of the latter two, though, such as the "SMI" activation mechanism, with "System Management Interrupt" for SMM and "Secure Management Interrupt" for TZ, etc. The ability to load earlier was informed by some ARM implementations establishing memory early and provisioning TZ, and also a potential SMM implementation of an early load One potential usage of the PI1.5 would be to cross-compile error logging code between a x64 Server to an Aarch64 based server, for example.

Beyond the UEFI Forum, there has been more industry discussion of the Intel(R) Firmware Support Package (FSP).  Specifically, this technology figures prominently in Tim's BlinkBoot (R) white paper mentioned in That paper is co-authored by another FSP fellow traveler, Ravi R, who helped create the series of Intel FSP producer/consumer papers, including  Along with the latter white paper co-author Giri Mudurusu I delivered the talk “Intel Firmware Support Package 2.0 Overview” at the coreboot conference, San Francisco, CA, June 14, 2016 The presentation is posted to

At the same conference, my colleague Lee Leahy and I delivered “EDKII and CorebootPayloadPkg." The presentation is at and the video at

On the coreboot payload package, in retrospect this code could have been generalized to the 'UEFI Payload Package.' Although the coreboot package has cbmem as its input data structures, which are then converted to HOB's, DXE and a UEFI implementation are easily launched from any environment with a HOB list. In fact, in the early days of Framework development we have a PEI shell command that would launch the DXE from the EFI Shell by just forging a HOB list. So this payload package could subsume today's DuetPkg, or EDKII on a PC/AT BIOS. Or the payload could be appended to U-Boot as an alternative to U-Boot native EFI implementation, perhaps?

The coreboot conference was at a Google office near the waterfront in San Francisco, with the following view from the Google cafe.

Nice view and food. Over breakfast one morning Ron Minnich and I discussed the RISC-V Supervisor Binary Interface (SBI) and how it was a similar model to the DEC Alpha PALcode We each agreed that having a hardware interface is often preferable to yet more run time firmware interfaces like sbi.

And the after-hours activity for the conference included a visit to with a mock-up of the 10,000 year clock

After this conference I revisited San Francisco again to deliver a poster chat at the Intel Developer Forum.  Below is the abstract of the talk:

SOFTC01 — New Firmware Security Requirements for the Modern Data Center
Data center security relies on a core root of trust, which is provided by platform firmware. The latest Trusted Platform Module (TPM) standard, TPM 2.0*, and updated Unified Extensible Firmware Interface (UEFI) requirements for enterprise operating systems are critical for companies deploying modern, secure data centers. In this session, you will learn security practices for UEFI firmware in enterprise and data center environments, based on new OS requirements and capabilities
Topics include:
• Update on latest UEFI standards for networking and security.
• Latest updates for TPM2.0.
• Guidance on building trusted enterprise class platform firmware.

About the Speaker

Vincent Zimmer Senior Principal Engineer, Intel Corporation

Vincent Zimmer is a Senior Principal Engineer in the Intel Software and Services Group. Vincent has been working on the EFI team since 1999 and presently chairs the UEFI Security and Network Subteams in the UEFI Forum He has authored several books and articles on firmware.

With the following poster.

The poster chat provided a lot of discussion with members of the industry around data center host firmware and deployment, including interest in HTTP-S style deployments in lieu of today's TFTP-based PXE.

It was great to see Kushagra on stage during the data center keynote, too.

When Kushagra was at Intel as a CPU architect he helped the firmware team pioneer the cache-as-RAM usages and later as a data center technologist some interesting platform solutions and

And during the event I was able to catch up with some colleagues on the show room floor, including Jeff Bobzin and Tim Lewis from Insyde, Dick Wilkins (thanks Bob H. for catching my typo in original posting) and Jonathan from Phoenix, and Stefano and Zach from AMI. Good folks all around.

After these sojourns to California, I gave a talk at the UEFI Plugfest here in the Seattle area. You can find the talk material at and the video at Many of my slides on the specification's features listed the corresponding Github repository. I omitted a link to the capsule work since at the time of the talk the EDKII feature was under community review. If I were to reprise the presentation today I'd affix to the top of slide 7.

During the Plug Fest Microsoft's Scott Anderson also provided an overview of in slides 4 and 5

In my UEFI Plugfest talk I also gave an update of the standards and some of the developments on EDKII, including mentioning some DMTF alignment topics I had also discussed at OCP I also enjoined the community to complement the industry standards with more informative information. To that end, beyond the above presentations and new industry standards, I co-authored a few new white papers since my last blog posting, including:

And under the guise of the UEFI Forum, "Establishing the Root of Trust," UEFI White Paper, August 2016, was published.

The intent of such material is to provide rationale and some guidance on how one might successfully refine the standards into a working artifact, including ones based upon EDKII style technology.

Well, so much for a catch-up blog. I wish everyone a happy Thanksgiving tomorrow from the always raining-in-November Seattle area.

Tuesday, July 26, 2016

M, M, and P

These three letters stand for "Mission, Mastery, and Passion."

I was motivated to scribe this quick blog based upon a conversation with an engineer in the Seattle area awhile back. He had lived through stints at Amazon, Microsoft, and other technology companies, including sole proprietorship's.  I asked him why he chose his latest career turn and he uttered that the job satisfied his three criteria - Mission, Mastery, and Passion. I won't break down the specifics of his explication of that 3-tuple, but here's the generic interpretation I derived.

In fact, this MMP triple has a fractal quality.  It can be used to describe a person's role, a group, or an entire company. And in the the process of this exploration I hopefully won't sound like a poor imitation of a Seth Godin blog

To begin with "Mission," the essential question to ask oneself is 'do I believe in the goals or business imperatives of the specific company?' In retrospect it's easy to arm-chair quarterback this one, especially during the go-go days of the dot com businesses, but I do believe that technologists have a reasonable acumen in this space. .

And at a personal level regarding mission, I work on software in the hardware industry. If Marc Andreessen has correctly characterized that 'software is eating the world', then I would ask 'upon what hardware and firmware will this software run?'  And I do believe in contemporary mission statements, such as

Assuming you are OK with the mission, the next question to explore is "Mastery." In this case the question is simple, namely 'Is there head-room to learn in this role?' To be effective in the technology world, you have to continue to re-train and learn In fact, the best advice I received during my Masters in Computer Science from UW occurred in Ricahrd Ladner's algorithms class. He said something to the effect of 'I cannot teach you everything about this topic, but what I can do is teach you how to research and learn on your own.' Given the nature of my employ and its mission statement listed above, I definitely have opportunities to learn each day in my present role.

And finally there is "Passion." This is a topic I treated earlier in, and this aspect of the employ cannot be understated. If you don't 'believe' and have fervor to perform your job, you are unlikely to be successful. You have to believe in what you're doing entails a mission and have a personal stake in the endeavors. It's not 'the company' or 'the job', it is integrally 'you.'

But also head the advice of others, too

With that passion in hand you should also be authentic in your role and truly strive to achieve, or 'do something,' as the author of notes in his question "To be someone or to do something, which would I choose?" In the act of 'doing something' you will hone your skills, expand your network, and support the progress of the business.

So with that I encourage you to explore your own MMP list. I recently met a junior engineer who seemed despondent about his job. I interviewed him using the MMP rubric and discovered that he had the two M's covered but not the P.  I told him to work on the P, else evolving from a junior to a senior role could be a tough journey.

Monday, June 6, 2016

Shields and Networks

In this blog I opine about shields, API's, and networks.

To begin with shields, the clip 'UEFI on Agents of S.H.I.E.L.D.' and associated transcript dialog included "This is called a Unified Extensible Firmware Interface."

What a fascinating occurrence in the popular culture of 2016. It reminds me of the introduction of the "Unified" term to the 'Extensible Interface' when our circa 1998 EFI 1.02 specification was sent to the standards body, and shortly afterward in the book

I wasn't the first choice for the book. The opportunity was offered to several others and only landed upon my doorstep after the editor had read the 2004 white paper UPDATE. I was motivated the pursue this effort in order to declare that UEFI was being implemented by "Intel's Framework", or our code base infrastructure that became EDKII on This first implementation was also based upon the Intel Framework specifications that subsequently became the UEFI Platform Initialization (PI) Specifications.

While at Intel, Richard Wirt was our Vice President and told me that there is both 'real and perceived' leadership. I believe we demonstrated 'real' leadership by delivering the EFI 1.0 specification into UEFI 2.0, the Framework specifications into PI 1.0, and the Framework code into the EFI Developer Kit (and later the EFI Developer Kit II - EDKII). But the book helped highlight that our 'real' leadership also had attendant 'perceived' leadership in the market.

Another good sound bite from management in those days was "if you cannot describe your job in a sentence or two, you don't really know what you're doing."

We updated the book five years later

The part of the latter book that most pleased me was sneaking the work 'eschew' past the editor. From page 285

'Although the development and design team eschewed use of proper names in code or the resultant binaries, the "VZ" and "Vincent Zimmer" association appeared harmless, especially given the interoperability advantages.'

Regarding UEFI ,a nice thing about UEFI and PI include locking down interfaces for purposes of interoperability.  The Intel Firmware Support Package (FSP) builds upon this API codification, with the following quote from R. Minnich in the introduction to
So API's are one thing, but the system also has interfaces on the network. This is where networking and wire protocols come into play. I'm happy to see the boot-from-HTTP that we codified in UEFI 2.5 and expanded upon with RAM disk scenarios in UEFI 2.6 continuing its build out. We struggled a bit thinking about how to evolve the UDP/TFTP-based PXE to the HTTP-based use cases. One of the features of the UDP-based PXE was the multi-cast variant of TFTP. We explored evolving PXE to be more scalable with streaming, big block, and reducing the number of ACK's. Dave Thaler told me that with those efforts in hand we were 'inventing' TCP, thus the move to the best-known implementation of TCP today, namely the application protocol HTTP, built upon TCP.

And for use-cases where you need the type of scalability found in multicast TFTP if PXE, we have DNS and HTTP for the UEFI HTTP boot. And the entire web model, from content delivery networks (CDN's) to load balancers, optimize the scaling of HTTP. Given that 'the world' is working on that particular scaling problem, the meagre firmware network use case should ride that wave of industry R&D practices. This is in the spirit of EFI wherein we tended to avoid reinventing known art, like file systems (FAT12/16/32), image formats (PE/COFF), and image integrity (Authenticode).

Speaking of scaling HTTP in these first 10000 days of the web, I have to hearken back to my days at the University of Washington 1998 when I was pursuing my masters. I took the computer performance class from John Zahorjan

At UW, this project entailed working on evaluating Round Robin DNS policies using web data from Brian Pinkerton's MetaCrawler. My partner on this proejct was an engineer from the erstwhile Teledesic effort, and we built a discrete event simulator fed by web traffic to assess response latencies based upon DNS server load balancing techniques.

I now appreciate the blog and web posting of information, such as on github, since the code and documentation from this project are lost in the sands of time. If I were to do this project today, I'd definitely share the results on the web. At the time I was also interested in heavy tailed traffic characterization, including work by Mark Crovella

Now we are in 2016 and we are booting from web servers in a standards based fashion.  Cool.

Regarding networking use-cases, it is a continuous challenge deciding  how much functionality to put into the pre-OS versus just booting a deployment operating system, like Linux or Microsoft Windows Pre-installation Environment (PE). I'd say that for diskless workstations, P-blades (processor + memory only compute nodes without local disk), diskless clients, recovering a a failed main OS on disk, etc having integrated networking makes sense. But for sophisticated deployments that need a multi-processor, multi-threaded, interrupt-driven, high performance and feature rich environment, a Linux or Windows PE makes the most sense.

These questions of balanced design weigh upon me as I look after the UEFI networking and security subteams in the UEFI Forum. I worry that I sometimes starve the former given the amount of issues and work in the latter.

And now for some final thoughts on networking and security. At ToorCamp 2012 I still recall Jacob Appelbaum suggested a removable TPM that the platform owner could destroy when encountered by law enforcement, and then Cryptocat author Nadim Kobeissi mentioned porting to UEFI in order to have a safer environment to do network communications.

The other convention-time suggestion from this era occurred during a trek to the Ubuntu Developer Summit in Orlando. My colleague Harry and I bumped into Mark Shuttleworth in the expo area after the presentations. After discussing UEFI with Mark for a few moments he asked us both about just putting Linux in the hardware for booting Linux from disk.

I'm not sure if these 2012 suggestions will ever come to pass in the platform, but it's always to follow the arc of technology in this industry.

And speaking of following arcs, I need to follow the arc of 'getting back to work.'


And don't think about the meat clown