Tuesday, April 23, 2019

another meta-blog, no runtime, and a taste of Rust

I hate to blog about blogs, but I wanted to mention https://www.jsnover.com/blog/2011/10/16/on-becoming-a-senior-technical-individual-contributor/#more-49 and https://www.jsnover.com/blog/2011/12/24/focus-on-reality/#more-137, especially the quotation  “My job is to ship the best ideas not come up with them“. This quotation follows the sentiment of http://vzimmer.blogspot.com/2013/12/invention-and-innovation.html where I noted that invention is just a part of innovation, where innovation is delivering on an idea to the market. I enjoy this type of post, including more recent ones like https://blog.jessfraz.com/post/defining-a-distinguished-engineer/.

Speaking of 'shipping' things, one area of pain has been the support of UEFI run time variables, especially honoring the semantic of 'success means durably stored' and authenticated variables means 'no bypass of the SetVariable API to the SPI NOR storage,' as described in our design material https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Implementing_UEFI_Authenticated_Variables_in_SMM_with_EDKII_V2.pdf. Given those complexities, I am happy to see efforts toward having a UEFI conformant platform elide support for certain run time services. From https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf

Specifically the EFI_RT_SUPPORTED_SET_VARIABLE. This work was driven by the U-boot community implementing UEFI https://github.com/u-boot/u-boot/blob/master/doc/README.uefi since having a separate, isolated persistent storage if difficult, especially on 'single NAND' devices, for which many U-Boot devices can be found. In the future this could be the extended to a broad class of systems wherein the OS could elect to 'stage' UEFI variable writes during the pre-OS, such as saving to EFI system partition during OS run time and then setting on a subsequent boot prior to Exit Boot Services, in lieu of today's run time accesses. Some people refer to this as double-clutching.

This approach follows the existing UEFI PI Threat model https://members.uefi.org/learning_center/presentationsandvideos/Intel-UEFI-ThreatModel.pdf where the more secure environment is in the early boot. This is often referred to 'temporal isolation.' We historically considered all of the OEM code (SEC, PEI, DXE) to be trustworthy, but option ROM’s, OS loader, and the OS kernel to be potentially hostile. As such, having the boot service time manage the write is easier since the UEFI PI implementation manages the hardware. Although http://vzimmer.blogspot.com/2012/12/accessing-uefi-form-operating-system.html is historically the most accessed entry on this blog, I'd be happy to see the above UEFI 2.8 capability make that blog posting moot.

On the topic of isolation, EndOfDxe event is the last point at which only OEM code runs. Afterward, many more parties run on the platform. For pre-OS isolation from 3rd party hardware devices we have https://firmware.intel.com/sites/default/files/Intel_WhitePaper_Using_IOMMU_for_DMA_Protection_in_UEFI.pdf. And for isolation of pre-OS host agents we have defense in depth among ring 0 UEFI and DXE with   https://legacy.gitbook.com/book/edk2-docs/a-tour-beyond-bios-mitigate-buffer-overflow-in-ue/details and other options like pushing your PI implementation ring -1

In general eliding the UEFI runtime or isolating existing 3rd party binaries present challenges with compatibility for the existing catalog of .efi images generated since the late 90's. You cannot easily apply NX to .efi images that combine code and data sections, or to images that implement their own image loaders (i.e., turning a data page into a code executable). As such, UEFI and the existing code is now a 20 year compatibility surface. I was reminded by the power and challenges of binary compatibility when reading 

Beyond isolation, the fashionable idea in the air right now is to re-write a bunch of stuff in Rust https://firmwaresecurity.com/2017/11/05/biors-bios-implementation-in-rust-language/, but that doesn’t handle the existing catalog of potentially errant or malicious native code objects out in the market. The nice part of language based security (LBS) approaches like Rust, though, is that existing C artifacts can incrementally be migrated to Rust. And Rust seems to have the mind share momentum, with representative OS https://www.tockos.org/assets/papers/rust-kernel-apsys2017.pdf ports https://doc.redox-os.org/book/ in hand. And Hacker news reminded me of other advantages as I type up this blog https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/ https://kkimdev.github.io/posts/2019/04/22/Rust-Compile-Time-Memory-Safety.html.

Sunday, February 24, 2019

Tiano, '147, and 22 or Anniversary.Next^7

This covers my 7th blog aligned with my work anniversary, a successor to http://vzimmer.blogspot.com/2018/03/open-platforms-and-21-or.html.  I'm now passing the 22 year milestone.

I try to land this blog posting on the anniversay day. Luckily this year I received an email reminding me that I'm already one year into my 3 year sabbatical eligibility. As far as topics go, replying to Juan's https://twitter.com/juanrodpfft/status/1099896998704996352 brought up a couple of milestones in time, namely Intel Achievement Awards (IAA's).  Some background on the IAA can be found at https://blogs.intel.com/jobs/2012/05/why-the-intel-achievement-awards-ceremony-was-amazing/#gs.13ww1ppY.

My first of 2 IAA's was delivered in 2004 and read on the Tiano architecture.

Tiano is the code name of what became the Intel Framework Specifications and the EFI Developer Kit (EDK), which has since evolved into the EDKII project and the UEFI Platform Initialization (PI) specifications. Even though this was about 15 years ago, progress in this space is continuing apace, including the open platform work. The last decade and a half was laying the foundations of the host firmware, and the next will be scaling how it's delivered.

To that end, the open Kaby Lake (KBL) platform has a newly added system, namely the Clevo board
https://github.com/tianocore/edk2-platforms/tree/devel-MinPlatform/Platform/Intel/ClevoOpenBoardPkg for System76 KBL laptops. This builds upon the infrastructure detailed in https://github.com/tianocore/edk2-platforms/blob/devel-MinPlatform/Platform/Intel/MinPlatformPkg/Docs/A_Tour_Beyond_BIOS_Open_Source_IA_Firmware_Platform_Design_Guide_in_EFI_Developer_Kit_II%20-%20V2.pdf.

So this means that I'm still building upon the project recognized by the first IAA, but what about the second one? The award from 2012 was on deploying signed updates across Intel and the industry, building upon the NIST 800-147 standards effort https://csrc.nist.gov/publications/detail/sp/800-147/final.

In the last 7 years work continues in this space and follows a similar arc, namely standards and scaling an implementation. A scaling of implementations of signed updates can be found in work like https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Capsule_Update_and_Recovery_in_EDK_II.pdf and additional standards, such as https://csrc.nist.gov/publications/detail/sp/800-193/final for resiliency. The latter is important because one of the challenges of deploying '147 style updates includes fear of a machine become bricked, or not successfully completing the update.

Awards are an interesting thing. One school of thought is that an award should only be delivered after an idea is delivered to market for several generations, thus ensuring that the originator of the idea carries the ball to the goal line. Without this tracking you end up with possible technologist patterns like a 'pump and dump', namely evangelize an idea and achieve rewards, but move on to the 'next big thing' prior to enabling and scaling the concept, or 'dumping it' on others prior to delivering market success. At the same time, though, technology is often a funnel that starts small with a few pioneering parties at the beginning, or mouth of the funnel, and telescopes to much larger sets of contributors by the time it appears in the market. So if you wait until the end, it's harder to reward smaller classes.

A colleague once suggested a potential solution to this 'pump and dump' risk for senior technologists, namely extend their review cycle from twelve months to a couple of years. The logic being that the annual review cycles encourages 'pump' periodicity of 12 months in order to optimize the remuneration calculus of annual reviews.

I personally don't know if there's a magic bullet other than the have a culture of each individual having the 'business first' mindset of one of the below quotations. Also, perhaps you can get away with a random 'pump and dump', but your personal brand and reputation will ultimately suffer for this type of behavior. The industry is relatively small, and 'trust is earned in droplets but lost in buckets.' A dump or two can lead to spilling that bucket.

Speaking of quotations and beyond those couple of awards milestones, a few other items came to mind during this anniversary posting. These include memory quotes from mostly-former colleagues, such as DM's "If anyone knew true cost of a project, nothing would be funded" or BP's "It has always been this bad.  you are just now higher up in the organization to see more." From there we have more valuable life and career advice, such as "Never lie, but don't tell all of the truth" or GC's "Two sisters never got along with - 'Polly' and her sister 'Ticks.'" Another one that helped me empathize with the machine was RH's "Moving higher in management ranks means making successively more impactful decisions with diminishing amounts of information."

In addition to the quotations I can source, the next ones are ones I find myself dispensing that I cannot recall if they originated from a party inside or outside, including "Prioritize your work with business first, team second, career third, "Be kind to people because you don't know what crisis they have going on personally," and finally "Your career is like archery of Zen - the harder you focus on the target of just 'success' the more difficult it will be to achieve."

OK. Awards and quotations. That's enough for noting the passing of 264 months.

Monday, December 31, 2018

STM, Mu, Chaos

This should be my last blog of 2018, so I'll keep it short.

I just wanted to note a couple of news items on the SMI Transfer Monitor which I long ago noted in https://firmware.intel.com/content/smi-transfer-monitor-stm. The NSA's evolution of the design as a checker was described earlier this year https://www.platformsecuritysummit.com/2018/speaker/myers/ and now has a public example https://github.com/EugeneDMyers/STM. This work, along with the patches to Xen to support the launch of the STM https://github.com/PPerfLab/xen/tree/stm-optin provides an exciting example of this technology being enabled.

Speaking of SMM, an interesting study of building systems without SMM was mentioned by an Intel colleague in the OCP talk described at https://firmwaresecurity.com/2018/12/30/alternatives-for-smm-usage-in-intel-platforms/. As opposed to jailing SMM code with an STM, this approach speaks to alternatives to implement capabilities formerly found in OEM SMM code in UEFI runtime and other portions of the platform.

Beyond the STM there is other interesting happenings in the world of open source firmware, including Microsoft's 'Project Mu' described in the blog posting
https://blogs.windows.com/buildingapps/2018/12/19/%E2%80%AFintroducing-project-mu/ and represented by various Github repositories https://github.com/topics/projectmu. There are interesting elements to be found, including test infrastructure https://github.com/Microsoft/mu_basecore/tree/release/201808/MsUnitTestPkg and https://github.com/Microsoft/mu_plus/tree/release/201808/UefiTestingPkg. On the security front, UEFI crypto interfaces https://github.com/Microsoft/mu_plus/tree/release/201808/MsCorePkg/MuCryptoDxe and a secure configuration infrastructure https://github.com/Microsoft/mu_plus/blob/release/201808/DfciPkg/Dfci_Feature.md for zero touch management can be found. These packages meet the spirit of the more 'code first' methodology I mentioned on slide 15 of http://www.uefi.org/sites/default/files/resources/UEFI_Plugfest_VZimmer_Fall_2016.pdf, for example. I've been told that although some folks in the Redmond area refer to UEFI as YOO-FEE https://vzimmer.blogspot.com/2018/03/open-platforms-and-21-or.html, no one refers to Project Mu as MOO-FEE.

Regarding EFI topics on Github, I opined about the EFI Byte Code (EBC) many years ago http://vzimmer.blogspot.com/2015/08/efi-byte-code.html, including challenges with natural integers, so I was happy to hear about an open source compiler with an EBC back-end https://github.com/retrage/elvm/tree/retrage/ebc-v2. I haven't dug in to see how they handle the sizeof(INTN) issue or if they just support x64. Either way, good stuff seeing the open source community pick up on this gap.

For my final topic I'd like to cover a talk from the Chaos Communications Conference (CCC). Watching this over the holiday has been a ritual of mine since I learned of talks like Trammell's Thunderstrike talk https://www.youtube.com/watch?v=TsRt76v8gPQ in 2014. This year's talk of interest was https://media.ccc.de/v/35c3-9778-open_source_firmware given by the organizer of OSFC https://osfc.io/ Zaolin. He mentioned the EFI on U-Boot work https://www.suse.com/media/article/UEFI_on_Top_of_U-Boot.pdf, which I find valuable since having alternate clean-room implementations helps increase the quality of the standard. Without alternate implementations, a single code base can become the de facto standard (recall the byte swap bug from my last blog). A couple of the data items were a bit off, though, such as the timeline with  "1998 Apple EFI by Intel" when Apple didn't convert to EFI until the x86 transition in 2005 https://en.wikipedia.org/wiki/Macintosh.

The PowerPC Macs prior to the transition used Open Firmware based upon Forth. Maybe the first article in https://www.intel.com/content/dam/www/public/us/en/documents/research/2011-vol15-iss-1-intel-technology-journal.pdf can provide a better timeline? Beyond small nits like the latter, though, it was a great talk and advocacy for more openness in firmware. This blog also had a short mention in the talk, too.

Other talks at CCC I liked include https://hackaday.com/2018/12/31/35c3-safe-and-secure-drivers-in-high-level-languages/ which reinforces the argument around using safer languages in low-level code like device drivers. And of course I cannot forget Trammell's talk https://media.ccc.de/v/35c3-9597-modchips_of_the_state. It was a definite counterpoint to the Portland BSides panel https://bsidespdx.org/events/2018/speakers.html on this topic. When I asked Joe F. about the variety of panel members he smiled and replied "yes, we have diversity. Some of the panel members have beards, some don't." Ah, 2019.

Here's looking forward to a safe and productive 2019.

© 2018, Vincent Zimmer. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License

Tuesday, November 27, 2018

API's, Sandbox's, and 400

As with my blog entries of late, below are some random thoughts based upon readings or events.  To begin I came across the article https://arxiv.org/pdf/1801.05198.pdf that made me think about the API's I mentioned in the last blog and how implementations have made consistent API's. Sometimes an API is defined but later discover implementation artifacts that contradict the specification. One such API is the storage security command protocol. At the time this API was defined I worked with the OS teams on coding this, I had inadvertently done a byte swap on one of the arguments, making it big-endian. In general the UEFI specification has a little-endian ABI. Since there were a plurality of implementations that had shipped in OS's and platforms, we 'fixed' the issue by codifying this behavior, viz.,

This change reminds me of challenges in enforcing memory protection in the UEFI phase, naming making code non-writable and data pages non-executable https://edk2-docs.gitbooks.io/a-tour-beyond-bios-memory-protection-in-uefi-bios/memory-protection-in-uefi.html. This was fine in principal, especially for DXE which is OEM only extensible, but for the 3rd party extensible boot service phase which requires binary .efi application and driver compatibility back to those early 1998 days, we found that some applications, like OS loaders, allocate a data page and copy code into which control is passed.  This type of data page to code page is something that the UEFI image loader can provide since it understands this semantic, but a UEFI implementation enforcing protection during the application phase sees these data allocations for custom image loaders as attacks.  And this behavior is baked into years of shipped OS loaders. We saw similar classes of app compat issues in UEFI drivers when we deployed https://firmware.intel.com/sites/default/files/Intel_WhitePaper_Using_IOMMU_for_DMA_Protection_in_UEFI.pdf since many drivers did not call PCI Map/Unmap for common buffer DMA since on x86 host and i/o memory are coherent and regular page allocations 'just worked.'

Some of these issues lead people to post items like http://uefi.party/ and
https://www.instagram.com/p/Bm_jCe2DPG3/?utm_source=ig_web_button_share_sheet but are really aspects of challenges in retrofitting security. Sandboxing is one potential security retrofit that has long interested me and for which I was reminded by Halvarflake talk
https://www.youtube.com/watch?v=JCa3PBt4r-k. A couple of examples of sandboxing in UEFI PI via SMM STM https://firmware.intel.com/content/smi-transfer-monitor-stm and VMM in EFI can be found in https://firmware.intel.com/sites/default/files/A_Tour_Beyond_BIOS_Launching_VMM_in_EFI_Developer_Kit_II_0.pdf & the ancient 2008 paper https://dblp.uni-trier.de/rec/bibtex/conf/csreaSAM/Zimmer08 https://github.com/vincentjzimmer/Documents/blob/master/SAM4877.pdf. For UEFI runtime we've mentioned UEFI runtime http://vzimmer.blogspot.com/2017/02/specifications-and-new-book.html with EFI_MEMORY_ATTRIBUTES_TABLE.

So on from random readings to other events. This week I achieved my 400th US patent:

Valles, Zimmer, "Cluster anomaly detection using function interposition," Issued 11/27/2018, US patent #10,140,449

Ironic that I've been reading Ovshinky https://en.wikipedia.org/wiki/Stanford_R._Ovshinsky biography lately, and he's listed at 400 issued, too

https://en.wikipedia.org/wiki/List_of_prolific_inventors. For some perspective on the long-game of patents, I crossed the 300 mark in 2014

And it was six years ago when I archieved 250 http://vzimmer.blogspot.com/2012/10/.

During this run of patents I've worked on lots of 'boot', including
EFI measured boot https://people.eecs.berkeley.edu/~kubitron/cs194-24/hand-outs/SF09_EFIS001_UEFI_PI_TCG_White_Paper.pdf, UEFI secure boot https://www.intel.com/content/dam/www/public/us/en/documents/research/2011-vol15-iss-1-intel-technology-journal.pdf, netboot6 https://tools.ietf.org/html/rfc5970, and HTTP boot

So many boot* activities over the past decade+. I used to say things like 'boot from a tennis shoe' when I had a simple mental model to explicate, but stopped using it during the last few years since that's a potential use case (IOT?).

And on observing the arc of time, I hearken back to the early days of patenting on any milestone. For #400 I cannot but recall #1, the now expired https://patents.google.com/patent/US5940587 "System and Method for Trap Address Mapping for Fault Isolation." Mil Travnicek https://billiongraves.com/grave/Mil-Travnicek/7514980, my original hiring manager at Intel, encouraged me to file this item in my first year at Intel. I still recall the 1/1 with Mil where he provided this feedback.

Speaking of Mil, after working for Mil on the first Itanium server firmware and moving on to EFI, I bumped into Mil in the hallway of DuPont, maybe sometime in 2000, and his query "Vincent, do you think it's a good idea doing something like EFI and moving away from compatibility? You know, we're really good at compatibility." Interesting sentiment given today's boot experience of UEFI on Aarch64, RISC-V and quite radical non-PC class x86 machine. Also, given my last posting http://vzimmer.blogspot.com/2018/10/ghosts-of.html of circa 1998 boot service compatibility and top of this blog, maybe UEFI is the new 'compatibility' box?

As a quick aside on the topic of compatibility, I enjoyed Tim Lewis on the topic https://uefi.blogspot.com/2018/04/the-oft-rumored-death-of-uefis-csm.html.

As a final thought on patents, I don't get so excited by raw number of patents alone. To me patents have always been part of a flow http://vzimmer.blogspot.com/2013/12/invention-and-innovation.html, and I also heard an interesting comment in a a https://www.ycombinator.com/ interview with a former Apple engineer who said something like "having lots of patents means you worked for a company that files patents."

So that's enough for tonight, I'd say. Until next time....

© 2018, Vincent Zimmer. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License 

Sunday, October 14, 2018

Ghosts of....

Ghosts of GUID's past. This post, like, many of my recent ones, walks backward in time. Recent events usually stir these memories. If you're not such a fan old these mutterings, I'd pass on this mid-month posting.

To begin, I couldn't help but remember

https://trustedcomputinggroup.org/wp-content/uploads/Platform-Reset-Attack-Mitigation-Specification.pdf during the F-Secure talk at Blue Hat https://www.microsoft.com/en-us/msrc/bluehat-conference recently.

That MEMORY_ONLY_RESET_CONTROL_GUID was GuidGen.exe'd https://blogs.msdn.microsoft.com/syedab/2010/05/09/generate-guid-using-guidgen-exe/ from my erstwhile cubicle in DuPont, WA http://vzimmer.blogspot.com/2018/07/the-march-of-time.html. I guess that I can now say 'buried' (thanks Fish for the latest pic) former campus.
This, along with other buried piles of GUIDs in the EDK code, the UEFI specification, and the PI specification http://uefi.org/specifications emanated from that dank DuPont corner cubicle. I've seen prezo's like this Bluehat one commencing in 2007 with Heasman's UEFI Black Hat talk through a decade of folks searching for GUID's in binaries and mentioning them in prezos and papers.

At the beginning of the hardware track a researcher came up to me and asked "Are you Vincent Zimmer? You're famous, man." I replied, "Er, 'famous', or 'infamous', given the queued up talks." He replied, "Nah, famous." That was nice.

Speaking of ghosts of technology past and true rock stars, people have been remarking this year that UEFI is a '20 year old technology.' I was curious about the precision of those statements, so I looked into an early Intel Boot Initiative (IBI) https://www.afterdawn.com/glossary/term.cfm/intel_boot_initiative tree. IBI was the original name of EFI. I found the following. 


Copyright (c) 1998  Intel Corporation

Module Name:



    Global IBI runtime & boot service interfaces


    Ken Reneris     Oct-14-1998

Revision History


// IBI Memory

    IN IBI_ALLOCATE_TYPE            Type,
    IN IBI_MEMORY_TYPE              MemoryType,
    IN UINTN                        NoPages,

    IN IBI_PHYSICAL_ADDRESS         Memory,
    IN UINTN                        NoPages

    IN OUT UINTN                    *MemoryMapSize,
    OUT UINTN                       *MapKey

    IN IBI_MEMORY_TYPE              PoolType,
    IN UINTN                        Size,
    OUT VOID                        **Buffer

    IN VOID                         *Buffer

// IBI Events

typedef enum {

    IN IBI_EVENT                Event,
    IN VOID                     *Context

    IN IBI_EVENT_TYPE           Type,
    IN IBI_TPL                  Tpl,
    IN IBI_EVENT_NOTIFY         NotifyFunction,
    IN VOID                     *NotifyContext,
    OUT IBI_EVENT               *Event

typedef enum {

    IN IBI_EVENT                Event,
    IN IBI_TIMER_DELAY          Type,
    IN UINT64                   TriggerTime

    IN IBI_EVENT                Event

    IN IBI_EVENT                Event

// Task priority level

#define TPL_NORMAL         4
#define TPL_CALLBACK       8
#define TPL_NOTIFY        16 
#define TPL_HIGH_LEVEL    31 

    IN IBI_TPL      NewTpl

    IN IBI_TPL      NewTpl

// IBI platform varibles

    { 0x8BE4DF61, 0x93CA, 0x11d2, 0xAA, 0x0D, 0x00, 0xE0, 0x98, 0x03, 0x2B, 0x8C }

// Variable attributes
#define IBI_VARIABLE_NON_VOLATILE           0x00000001
#define IBI_VARIABLE_RUNTIME_ACCESS         0x00000004

    IN CHAR16                       *VariableName,
    IN IBI_GUID                     *VendorGuid,
    OUT UINT32                      *Attributes OPTIONAL,
    IN OUT UINTN                    *DataSize,
    OUT VOID                        *Data

    IN OUT UINTN                    *VariableNameSize,
    IN OUT CHAR16                   *VariableName,
    IN OUT IBI_GUID                 *VendorGuid

    IN CHAR16                       *VariableName,
    IN IBI_GUID                     *VendorGuid,
    IN UINT32                       Attributes,
    IN UINTN                        DataSize,
    IN VOID                         *Data


It looks like today is makes one milestone of 20 years if you use source artifacts as a sign post. You'll notice the code below matches chapter 7 of http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_7.pdf pretty closely, too (i.e., replace 'IBI' with 'EFI'). The code author is the same Ken Reneris mentioned in the Beyond BIOS https://www.amazon.com/Beyond-BIOS-Developing-Extensible-Interface/dp/1501514784 acknowledgement, too.

Although there's no explicit mention of IBI in the UEFI specification, it still lingers in

#define EFI_SYSTEM_TABLE_SIGNATURE 0x5453595320494249



Moving on from Bluehat and IBI, I am surprised by the feedback around Linus T's behavior https://www.zdnet.com/article/linus-torvalds-and-linux-code-of-conduct-myths/.

I recall one event (maybe the 2015 OSTS mentioned in http://vzimmer.blogspot.com/2015/05/ocp-csw-and-new-specifications.html) when I was introduced to Linus as a 'UEFI guy, so tell him what you don't like.'  Linus said 'That UEFI runtime is really screwed up.' I replied 'I agree, especially services like SetVirtualAddress that are not idempotent, so they break things like kexec where the latter kernel cannot re-invoke the service.' He looked at me and said 'Hmmm, but I like the UEFI Shell for debugging.' I responded 'It's OK, I guess.'  At this point the Linux die-hard who had initiated the interaction was fuming and shouted 'But Linus, what about ACPI?' Linus then looked at us both and said 'But wasn't ACPI screwed up before EFI and UEFI?'  Good times.

My philosophy on getting strident feedback from open source leaders, whether Linus, Minnich, or the spectrum in-between on the net, is to not take it person 'how' the message is delivered, but 'why.' I use the analogy of the bazooka.  Don't cavil about the calibre of weapon, but try to figure out why it's aimed at me. Often it's because the party delivering the message is passionate about a legitimate concern, and my job entails trying to understand and make progress against 'fixing' the concern, if possible.

Final thoughts are on grabbing the free Friday sessions as CppCon in Bellevue. I was impressed with the wisdom behind
As recently as a day ago I had to remind someone that adding new behavior to a 20 year API without changing software visible version indicia, such as version field or GUID of the API, was a doomed path. They replied 'but everyone builds with the latest code.' To which I responded 'that makes sense within one company, but the point of standardized API's is interoperability, and for the latter you cannot dictate the provenance or age of the caller.'

Speaking of Bellevue and the Pacific Northwest, I'll leave with a couple of shots from http://www.issaquahchamber.com/salmondays. Namely a 'before'

and 'after'
of the salmon.

© 2018, Vincent ZimmerThis work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License 

Wednesday, September 26, 2018

East, and further east

Since I last blogged the Open Compute Project Open System workstream https://www.opencompute.org/files/2018OCP-OSF-OpenEDKII-Workstream.pdf has continued to evolve https://docs.google.com/document/d/1DWFdPrZlifSxznirN4r5QemmBEi6-1Fpfy0lac77arQ/edit. Part of the feedback from that community helped inform the decision to liberalize the Intel FSP license, too https://www.phoronix.com/scan.php?page=news_item&px=Intel-Better-FSP-License. A theme here includes trying to ease system development.

A lot of those efforts were driven out of the Seattle area, but I made my first sojourn east to https://www.platformsecuritysummit.com/ for https://www.platformsecuritysummit.com/2018/speaker/zimmer/. I followed the Trammell Hudson's presentation, which is always tough given his presentation prowess. This reminded me of the time when the Toorcamp organizer put my EFI defense talk immediately after Dan Griffin's EFI attack talk. In the end I got to know Dan and appreciated his offensive work since great offense inspires more strident defense.

The platform security summit was a great opportunity to engage with companies concerned about the transparency of open platforms, system assurance, and firmware. There has been a lot of discussion about moving to RUST https://www.rust-lang.org/en-US/, including the sentiment from Ron Minnich about today's proliferation of ring 0 C code "Too much writing of code, too little thought about not writing code, and it's all too easy nowadays just to barf out a couple KLOCs without thinking things through."  I'm especially interest in the potential ability to do verification actions, such as http://plv.mpi-sws.org/rustbelt/.

I was pondering that while traveling back from DC when I bumped into David Aucsmith
Aucsmith https://www.root9b.com/leadership/david-aucsmith/ while awaiting a return flight to Seattle. Dave provided me the insight the use Ceremonies https://eprint.iacr.org/2007/399.pdf as a model for system provisioning back at CanSecWest in 2015 in addition to the legendary contributions he made at Intel. I asked Dave what he though of language based security, such as RUST, and he simply replied to me, "If this is such as consideration, why haven't you been coding in Ada https://en.wikipedia.org/wiki/Ada_(programming_language)?" coreboot even has a Ada runtime https://github.com/coreboot/coreboot/tree/master/src/lib/gnat and I don't see much community support, so maybe Dave is on to something.....

After returning to Seattle, I steeled myself for the 'further east' journey, namely visiting Erlangen, Germany for https://osfc.io/. I am honored to have been invited to deliver the keynote https://osfc.io/talks/keynote for this multi-firmware community event. What a passage of time since it makes 15 years since my first Intel Developer Forum solo talk https://github.com/vincentjzimmer/Documents/blob/master/EFI_Specification_Evolution_Final_04%20-%202003.pdf. Fast forward and I get to make a solo keynote.

Ironically, my keynote preceded Trammell's security keynote and he amazing slip-streamed my image into slide 10 of his deck https://osfc.io/uploads/talk/paper/2/OSFC_Security_Keynote.pdf

I tried not to 'preach' about firmware, especially since the event was held in a Church.

I also had the opportunity to provide security overviews w/ Maggie for the security hack-a-thon at the event.

I was definitely among my firmware brethren, of which I was reminded with pages like 'booting is hard.' Yes, it is.

Here's a shot of the event location from the outside.

I mentioned the Intel Firmware Support Package (FSP) in the event. That evening event a Swiss engineer answer my query about what I was eating with "It's like an FSP. We know what's on the outside,

but often not what's on the inside."

Nice. Firmware humor on top of the technical conversation and information exchange flow. Speaking of flow, I was reminded of the importance to share knowledge when an engineer early in his career asked for a signature of https://www.apress.com/us/book/9781484200711

Since last blogging I'm happy to have also participated in documenting more of the Intel platform behaviors, albeit the small core SOC https://firmware.intel.com/sites/default/files/uefi_firmware_enabling_guide_for_the_intel_atom_processor_e3900_series.pdf, too. To me it's another tactic on how to scale knowledge and empower communities.

Finally, I'm glad to be back in the Pacific Northwest this week. Today and tomorrow I'm at Blue Hat https://www.microsoft.com/en-us/msrc/bluehat-conference which is a short walk from the Intel office. And no presenter-angst.

So no multi-hour flights, security lines, or strange hotel rooms

If you're around Blue Hat and catch this blog, say hello.

© 2018, Vincent ZimmerThis work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License 

Monday, July 2, 2018

The march of time

Driving home from Intel Hillsboro Friday night I took a small detour through DuPont, WA. Typically night fall precludes seeing the old campus, but given the summertime extended days, I took a chance.

The campus sign is still there

but as noted in the blog post http://vzimmer.blogspot.com/2014/02/anniversary-day-next-next.html
we were moved from the campus to further north in WA a few years back. Afterward Intel sold the campus to another company.

DuPont Building 2, or "DP-2," the specific building shown in the above posting

has become


Little profundity found in the erstwhile company sign or the visitor parking sign compared to  https://www.poetryfoundation.org/poems/46565/ozymandias, but seeing my original Intel campus building disappear nevertheless saddened me.

The march of time.

© 2018, Vincent ZimmerThis work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License