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.' https://www.youtube.com/watch?v=9lc95nXKWMM and associated transcript dialog http://transcripts.foreverdreaming.org/viewtopic.php?f=140&t=27259 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 www.uefi.org, and shortly afterward in the book
http://www.amazon.com/Beyond-Bios-Implementing-Extensible-Interface/dp/0974364908/
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 tianocore.org. This first implementation was also based upon the Intel Framework specifications http://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-specifications-general-technology.html that subsequently became the UEFI Platform Initialization (PI) Specifications.
While at Intel, Richard Wirt https://www.crunchbase.com/person/richard-wirt-m-s-ph-d#/entity 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
http://www.amazon.com/Beyond-BIOS-Developing-Extensible-Interface/dp/1934053295/
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
http://www.amazon.com/Embedded-Firmware-Solutions-Development-Practices/dp/1484200713/
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 https://homes.cs.washington.edu/~zahorjan/homepage/.
At UW, this project entailed working on evaluating Round Robin DNS policies using web data from Brian Pinkerton's https://en.wikipedia.org/wiki/WebCrawler 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 http://www.cs.bu.edu/fac/crovella/list.html.
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 http://vzimmer.blogspot.com/2012/08/one-conference-down-one-to-go.html 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.'
Cheers
PS
And don't think about the meat clown
To begin with shields, the clip 'UEFI on Agents of S.H.I.E.L.D.' https://www.youtube.com/watch?v=9lc95nXKWMM and associated transcript dialog http://transcripts.foreverdreaming.org/viewtopic.php?f=140&t=27259 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 www.uefi.org, and shortly afterward in the book
http://www.amazon.com/Beyond-Bios-Implementing-Extensible-Interface/dp/0974364908/
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 tianocore.org. This first implementation was also based upon the Intel Framework specifications http://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-specifications-general-technology.html that subsequently became the UEFI Platform Initialization (PI) Specifications.
While at Intel, Richard Wirt https://www.crunchbase.com/person/richard-wirt-m-s-ph-d#/entity 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
http://www.amazon.com/Beyond-BIOS-Developing-Extensible-Interface/dp/1934053295/
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
http://www.amazon.com/Embedded-Firmware-Solutions-Development-Practices/dp/1484200713/
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 https://homes.cs.washington.edu/~zahorjan/homepage/.
At UW, this project entailed working on evaluating Round Robin DNS policies using web data from Brian Pinkerton's https://en.wikipedia.org/wiki/WebCrawler 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 http://www.cs.bu.edu/fac/crovella/list.html.
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 http://vzimmer.blogspot.com/2012/08/one-conference-down-one-to-go.html 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.'
Cheers
PS
And don't think about the meat clown
