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
https://firmware.intel.com/sites/default/files/resources/UEFI_Plugfest_2015_Challenges_in_the_Cloud_Whitepaper_0.pdf.
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
