Tuesday, July 6, 2021

Patents and co-inventors

The following announcement of a fellow Cornell alum Mark Charney on his linkedin page

https://www.linkedin.com/feed/update/urn:li:activity:6815764405725270016/ caught my eye today

where Mark is celebrating the receipt of his 100th US patent.

I especially liked the comment about collaboration. That has always been the most interesting aspect of the inventive and technical development process.

To that end, I roamed over to https://en.wikipedia.org/wiki/List_of_prolific_inventors to see about other Intel inventors, and to my surprise, I saw 30 Intel inventors listed. I believe that I have mentioned this site before in earlier postings, too, http://vzimmer.blogspot.com/2014/08/ http://vzimmer.blogspot.com/2021/01/innovation-and-invention-redux.html.

Two immediate collaborators I recognize are Ned Smith and Mike Rothman. 

I am a co-inventor on 272 of Mike's (96%) issued US patents and 27 of Ned's (9.7%)

Ned has a pretty interesting publication history, too, with dblp picking up https://dblp.org/pid/56/3580.html. This compares to my dblp list https://dblp.org/pid/34/5641.html. Regrettably no joint publications, although I'm a big fan of Ned's Clark Wilson integrity model study of the TPM. We cited this in https://link.springer.com/book/10.1007/978-1-4842-6106-4, for example, along with his IOT security book. That paper was presented at the Security and Management (SAM) conference in Las Vegas. I published my first four papers in the 2000's at that venue, too. If I recall Selim Aissi https://www.linkedin.com/in/aissi/ encouraged folks to contribute to that venue?

I spent time working with Ned when he was the VPro security architect, too https://www.intel.com/content/dam/www/public/us/en/documents/research/2008-vol12-iss-4-intel-technology-journal.pdf. And it looks like Ned and I were co-inventors my latest issued patent "Static and dynamic device profile reputation using cloud-based machine learning" 11,049,039 with our erstwhile McAfee colleagues.

As for Mike Rothman, he has been a long-time collaborator (and physical office neighbor when we aren't in COVID seclusion). Mike overlaps on my dblp above with a couple of books and we also contribute to the firmware standards, including the review of the UEFI ecosystem in  https://www.intel.com/content/dam/www/public/us/en/documents/research/2011-vol15-iss-1-intel-technology-journal.pdf

Perusing the list further I see David Durham with whom I collaborated on a few patents

or 4% of his total 216. And finally, one joint patent with another Cornell alum Gil Neiger 

out of his 211 patents (0.5%) as of July 6, 2021, along with some of the other Intel virtualization crowd https://ieeexplore.ieee.org/document/1430631

Although Neiger and Charney are Cornell alums, they are Phd's & I am but a BSEE from Cornell and MS Comp Sci from UW here in Seattle. I was reminded of my lowly spot on the tech education totem pole when shopping at Fred Meyer in Issaquah, WA last night and two customers were loudly speaking with each other in the vegetable section. I caught the fragment of their conversation "...and he only has an MS and not even a Phd." I didn't recognize the two but at that point I seriously doubted my credentials to buy that bundle of organic carrots I had in my hand....

Although we are not co-inventors on any patents, my more immediate neighbors on the https://en.wikipedia.org/wiki/List_of_prolific_inventors list include the number one Intel inventor Robert Chau https://newsroom.intel.com/news/creating-new-technologies-keep-moores-law-alive-well/ and number three inventor Jack Kavalieros  https://www.intel.com/content/www/us/en/newsroom/news/2021-inventor-year.html#gs.55miv2

who bound me from above with Chau's 486 patents, my 453, and Jack's 440 below, respectively.

Robert and I each passed the 300 mark in 2015, although Chau has pulled ahead of me quite a bit in subsequent years. And in light of the pipeline of pending patents Jack has, I suspect he'll leave me watching his transistor research taillights, too, in short order. 

The other good thing about Jack passing my count will be maintaining grade monotonicity. Instead of Fellow->Sr. PE->Sr. Fellow as we have today with Jack->Vincent->Robert, we'll have Sr. PE->Fellow->Sr. Fellow, where grade level will increase on the Y-axis as patent count increases on the X-axis.

Finally, given that Intel was founded on many of the transistor and integrated circuit accomplishments of folks like Robert Noyce https://en.wikipedia.org/wiki/Robert_Noyce, having Robert and Jack as the lead inventors for the company is a wonderful thing.

So much for random thoughts and numbers around issued US patents on a summer day.....

Wednesday, February 24, 2021

24 or Anniversary.Next^9 and 128 bits

I was pretty late last year in posting http://vzimmer.blogspot.com/2020/05/recovery-tech-talks-23-or.html in order to maintain this ritual. It's OK to be late but I cannot really make up by being early in 2021 since there is no guarantee that will be employed on the anniversary date, of course.

As such, here's the anniversary year 24 edition. It features rolling into upcoming year, which may culminate in the '25' edition of this posting, the need to take the extended sabbatical (extension based upon COVID), and hitting the 'rule of 75' at the near midpoint of this upcoming 12 months. Either way, I hope to have a "Anniversary^10 and 25 years" post. 

I have definitely learned many things in the past past couple of decades, including how to take criticism, whether code & spec review or paper and patent feedback. It's tough sometimes but feedback provides one of the key ways to grow. There is always room to learn, too. Thanks to Hot, via Rob, for recent reference https://www.amazon.com/12-Essential-Skills-Software-Architects/dp/0321717295. I especially like the quote "Architecture is about business. It focuses on representing, communicating, and building on the key points of a technology or even a nontechnology solution that has beneficial impact to the business in some way."

Beyond keeping up with the times via feedback and book learning, I sometimes like to ponder the basics in this fast moving technology world. The basics include maths, science, and for computers. Vintage computer topics include the EDVAC http://web.mit.edu/STS.035/www/PDFs/edvac.pdf. This led me to think about pointer sizes. I started my career programming 8-bit 8051's with its infamous 16-bit 'DPTR' and Harvard Architecture. Then I moved to the 16-bit 186, 16-bit V20 286, 32-bit 386EX & 486 from Intel, 29k from AMD, and Pentium Pro. Then I segued to 64-bit with Itanium here at Intel where I on-boarded to lead some of the boot firmware development, and then EM64T/x64/x86_64 to provide the first EFI boot. But what about 128-bit https://en.wikipedia.org/wiki/128-bit_computing ?

My journey into the past led to some questions about the integer and pointer size of the Unisys 1100 (72 bit ptr, 576 bit integer?) mentioned in https://www2.cs.arizona.edu/~mccann/cstyle.html. GCC has a data type https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html. Maybe a future ILP128/LP128 to scale beyond today's ILP64/LP64 http://archive.opengroup.org/public/tech/aspen/lp64_wp.htm?

The C style document mentions DEC, which reminded me of some of the innovation they, as chronicled at http://simh.trailing-edge.com/dsarchive.html. During my undergraduate days at Cornell Digital was to place to go for systems work, and at Intel in the late 90's many ex-DEC engineers led the workstation work (e.g., Dileep B.).

Intel has been evolving physical addresses, too 5-level paging on Intel x86 https://software.intel.com/sites/default/files/managed/2b/80/5-level_paging_white_paper.pdf

Most interesting regarding deployed systems is the AS/400 single level store w/ 64 or 128 bit pointers. I ran into this while reading 'inside the as/400' https://www.amazon.com/Inside-AS-400-Frank-Soltis/dp/1882419669 book, Some CPU's have 96-bit physical addresses with the size hidden by the SLIC - system level interface code. IBM also has 80 bit VA and 64-bit PA on IBM https://www.ibm.com/support/knowledgecenter/ssw_aix_71/generalprogramming/address_space.html.

These pointer size ruminations led me to think of the more recent paper on the subject, namely the RISC-V paper and the architecture's support of 128 bit addressing. From https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.pdf:

"At the historic growth rate of the memory capacity of TOP500 champions, about 70% per year, a 64-bit address space would be exhausted in about two decades. To the extent that global addressability of such systems is desired, we contend that flat addressability is the best approach; RV128I provides a promising solution."

Andrew W. mentioned that the 128 bit binding was considering something of a joke when he described it at the 2016 coreboot conference https://www.youtube.com/watch?v=f0ykeMmqglI&feature=youtu.be (12:25). 

In the intervening 5 years, though, the 'joke' takes on some more gravity with the comment about needing to work on the base spec for 128 bits (minute 3:58 of https://www.youtube.com/watch?utm_content=152341011&utm_medium=social&utm_source=linkedin&hss_channel=lcp-7579420&v=lg33UqZ_en0&feature=youtu.be)

There are no known soft or hard core IP implementations of RV128 I could find on the web, although the https://bellard.org/tinyemu/ RISC-V system emulator supports the RV128IMAFDQC base ISA (user level ISA version 2.2, privileged architecture version 1.10).

But extra bits do not have to be used for addressing. There are potential security usages https://riscv.org/wp-content/uploads/2017/12/Tue1554-xbgas-JLEIDEL.pdf, or more fringe ideas like mapping ipv6 address to memory locations https://patents.google.com/patent/US8266238

Again, these are 128 bit pointers, not 128 bit data types. A lot of the SIMD/Vector ISA extensions have broken the 128 bit data type long ago. This is a "sizeof (pointer_in_128_bit_ISA) == 128" thing.

Speaking of RISC-V, I was interested to see the progress in the EDK2 RISC-V port https://fosdem.org/2021/schedule/event/firmware_uor/. Some of this work was inspired after my posting http://vzimmer.blogspot.com/2014/11/porting-to-new-architecture.html which led to position papers https://github.com/vincentjzimmer/Documents/blob/master/risc-v-uefi-talk-001.pdf https://github.com/vincentjzimmer/Documents/blob/master/risc-v-uefi-talk-004.pdf and standards/open source work.

I asked the Fosdem developer if he had considered porting the UEFI Platform Initialization (PI) Management Mode (MM) to the System Binary Interface (SBI) https://github.com/riscv/opensbi machine mode. This is work we did https://github.com/vincentjzimmer/Documents/blob/master/A_Tour_Beyond_BIOS_Launching_Standalone_SMM_Drivers_in_PEI_using_the_EFI_Developer_Kit_II.pdf 

in order to allow decoupling the SMM from the host firmware environment https://github.com/tianocore/edk2/tree/master/StandaloneMmPkg was originally done for loading SMM from the Firmware Support Package (FSP) with a prototype at https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64_smm. The work was then picked up by the ARM community who need to load the TrustZone-variant of MM during early boot (e.g., SEC or PEI). The architecture neutrality of MM software model could thus be applied to RISC-V, just as the original "SMM Framework" mentioned "xMI's" to cover by the x86 system management interrupt (SMI) on x86 and the platform management interrupt (PMI) on Itanium. 

Today, though, SBI is really a set of call interfaces similar to the DEC Alpha PALcode or Itanium SAL/PAL Code.  I mention both PAL and SAL from Itanium since some of the SBI are SOC-specific (e.g., ISA emulation) whereas others may map to the platform (e.g., debug console). The runtime of host firmware is always challenging, whether it's traditional SMM on x64 and UEFI runtime and the interpreted ACPI, or the IBM Opal runtime or device tree. As always the execution of runtime should be minimized in order to avoid impacting host OS / hypervisor resource management, with 'minion cores', Embedded Controllers, BMC's, and other SOC microcontrollers providing independent execution regimes.

Saturday, January 23, 2021

books and computers

Saturdays are interesting, especially working for a multinational company with colleagues across the globe. I may have shared this sentiment before, but I still recall the tale that resonated with me from a currency arbitrage trader https://www.investopedia.com/terms/c/currency-arbitrage.asp. The person mentioned that he was working whenever a market was open. Luckily Saturday is the one day without any market open so he would use that day to do laundry, go grocery shopping, and follow-up on other chores. Feels like the work life of many in Friedman's flat world :).  Thus stealing a few moments on the Saturday nadir of activity for a quick blog.....

I'll commence this blog with observations about books, starting with my most recent  https://www.apress.com/us/book/9781484261057

Ir is not quite small, weighing in at 930 pp.

It's the 7th physical book / printing I have in hand. It culminates a stack of dead trees spanning 3 editions of Beyond BIOS, two of the Shell, security, and embedded. Publishers of this stack range from Intel Press (shuttered 5 years ago) through De Gruyter https://en.wikipedia.org/wiki/De_Gruyter and into Apress. And I also had 8 different co-authors spanning employers past or present including Intel, Phoenix, Insyde, Google, ARM, retirement, Sage, and Amazon. I've been at Intel the whole course of the book runs, though. The mountain of paper is shown below.

[from top down]

Now for a bit of history of Intel and tech books, at least as far as I'm aware. Prior to Intel Press, Intel technical books were done through McGraw Hill in the 1980's. Below is one example from my nearby shelf.

Then in the 1990's there were McGraw Hill / Intel joint imprints, such as the RMX and 486SL books below. 

I especially like the the drop-e in the logo of those books which was removed in 2006 by Intel.

And in the 2000's Intel Press published both books https://openlibrary.org/publishers/Intel_Press https://www.intel.cn/content/dam/www/public/us/en/documents/white-papers/developer-reading-list.pdf and the Intel Technology Journal (ITJ). I still recall reading the first IT issue https://www.intel.com/content/dam/www/public/us/en/documents/research/1997-vol01-iss-3-intel-technology-journal.pdf when I joined the company in 1997. I was happy to have the opportunity to lead the creation of the only printing in 2011 
https://www.intel.com/content/dam/www/public/us/en/documents/research/2011-vol15-iss-1-intel-technology-journal.pdf. It made me feel like a small part of the technology history of the company.

In that 2011 issue I co-authored 3 of the papers, including networking and security

which was referenced in the Apress firmware security book, as shown below.
And luckily the Intel Technology Journal PDF's were all archived on Intel.com after Noggin.intel.com and Intel Press were closed down.

Another notable reference in the Apress security book was http://netlab.cs.ucla.edu/wiki/files/shannon1949.pdf

which excerpted some of the principles of cryptography

and had the citation

I regret that only this final Apress book had rich citations. The other books were a bit light on the references. I'm still amazed by the longevity of Shannon's work on information theory and security.

Speaking of Apress, the publisher is actually an imprint of Springer Verlag https://en.wikipedia.org/wiki/Springer_Science%2BBusiness_Media.  In 2009 I wrote a chapter for Springer

with original Beyond BIOS co-authors.

Outside of Intel presentations or patents, the 2004 "Update at Intel" article is the first of prose describing firmware. This was part of a series of articles posted on the Intel website about recent technology evolution. I still like the fact that it described the XScale ARM port I did in 2001 and had a Pentium 4 in the block diagram. This same XScale work was elaborated upon the 2006 Beyond BIOS book code fragment, being placed by a mobile internet device (MID) in the 2010 2nd edition of Beyond BIOS, and finally turning into a Intel FSP example in the 2017 3rd printing of the book. Interesting evolution of the platform across the decade and a half.

It's also the only publication with a 'drop-e' that I created, too.

I still fondly recall the CDSA and ACSFL update articles, but unlike the ITJ, these pages have not been archived on intel.com, the wayback machine of archive.org, or other computer history repositories of lore such as bitsavers.org. For work that never made it to open source, I wonder how much interesting technology history is lost every year? 

In the spirit of the written word, and despite questions of the demise of print https://www.stamats.com/think-print-dead-think-again/, it's nice to see that Grove, CEO when I joined in 1997, and Gelsinger, upcoming CEO this year, expressed both their technology and business insights via writing. 

[from top down]






Writing books is one way to scale one's knowledge that transcends the utility of (cough cough) blogs, streaming video and podcasts IMHO.

Regarding the writing process, I am not sure about how easy of a time either my co-authors or luminaies like Grove and Gelsinger had in writing their tech and business books, but I feel like the following when trying to get the pages out.

So much for this Saturday typing. Here's looking forward to market openings and meetings commencing tomorrow. 

Friday, January 15, 2021

memories from uw and cornell

This is something of a random blog posting. 

As the new year rolls around, I became thoughtful of the page of milestones. These include my time at the University of Washington here in Seattle https://www.cs.washington.edu/ getting my CS Masters during the 1997-1999 time frame. 

I spoke a bit about the UWCSE in http://vzimmer.blogspot.com/2018/06/ along with the now-closed https://www.livingcomputers.org/. Given the recent interest in retrocomputing https://www.nytimes.com/2021/01/08/style/retrocomputing.html the museum would be overrun with aficionados if it were open.

I frame many of my UW memories via the professors. These included John Zahorjan https://www.cs.washington.edu/people/faculty/zahorjan on computer performance. I recall one project with a classmate Amanda Barrett (then an employee at Teledescic, Macaw's attempt at a satellite communications network in the late 90's) on modeling different web server scheduling policies, such as Round Robin DNS (RR-DNS) using C++Sim. The most interesting part of the effort was the ability to drive the simulation with anonymized, real-life web traffic from Metacrawler by way of UW alum Brian Pinkerton alumni https://en.wikipedia.org/wiki/WebCrawler https://www.w3.org/Conferences/WWW4/Papers/169/.

The next professor I recall is Anna Karlin for algorithms https://www.cs.washington.edu/people/faculty/karlin. She taught my first class at UW. The take-away I have from that course was the value and extent of mathematical rigor behind algorithms. From my undergraduate and 5 years prior industry experience I saw algorithms more as rote recipes than evolve mathemtical objects.

Next up was the artificial intelligence course with Dan Weld https://www.cs.washington.edu/people/faculty/weld. Like the performance class above, my strongest impression was the project course. The specific project included writing a movie recommendation system for movies. We would create Java wrappers for websites, such as for the recently launched https://www.imdb.com/, to support queries written in Datalog https://link.springer.com/referenceworkentry/10.1007%2F978-0-387-39940-9_968. It would allow the end user to write queries, such as 'Show me all of the movies in Seattle starring Tom Hanks.' The downside of the system is that this work predated the semantic web and the website wrappers had to continually get updated based upon the changes in sites like IMDB. 

The other part I recall from the AI adventure is that my partner was a local Intel DuPont employee in another team. His manager was much more liberal about taking classes so he had the opportunity to work on the course during the work day. My management, who had initially replied to me when I requested funding for the masters project with 'why do you want to take classes, you are already smart enough?' didn't permit such liberties. So like my patent writing of the last 20 years, my masters work was always a late-night after-hours and predominately weekend activity.

From AI I recall taking a second algorithms class with Richard Ladner  https://www.cs.washington.edu/people/faculty/ladner. I still recall a quote from Ladner early in the quarter, namely "I cannot teach you everything about algorithms since the field is so broad and continually changing, but what I can do is teach you have to do research and learn on your own." The deep project work done in that class involving assessing recent publications has stayed with me. And the wisdom still holds true today, every field is continually changing. Sort of the academic analogy to the pre-Socratic Heraclitis quote "You cannot step into the same place in a river twice."

Another part of the UW journey was sorrow, too, including the passing of my advisor https://s3-us-west-2.amazonaws.com/www-cse-public/publications/msb/msb11.1.pdf

Just like my undergraduate journey, I didn't have the luxury to take so many courses, so I calculated the exact number of credits I needed to get my degree. For undergraduate urgency the timing was economic based, whereas for my masters it was lifestyle based (i.e., high pressure job with hardware power-ons, new-borne daughter, etc). As such, one way to complete the requirements was through research credits, and one effort involved working on a project with Susan Eggers  https://homes.cs.washington.edu/~eggers/. She was a huge influence on me in computer architecture, and after meeting her, some of the stories I late reach https://egc.yale.edu/how-job-yale-1960s-set-susan-eggers-groundbreaking-path-computer-science did not surprise me at all.

Since distance learning was a bit nascent in the late 90's, I still recall hurrying from DuPont, WA Intel site to the U District in Seattle. I tried to time my arrival such that when the street parking became free at 6pm I could find a slot.

And the old CS building Sieg Hall, ah......

Definitely quite a change from the new EE/CS building, especially the Amazon auditorium. I luckily managed to catch a couple of interesting talks there in the last couple of years, including Patterson preaching about RISC-V https://www.youtube.com/watch?v=mD-njD2QKN0 (and getting one of the single-page ISA descriptions printed on green paper) and David Bacon on the evolution of quantum computing https://phys.washington.edu/events/2019-12-10/cse-colloquium-quantum-computer-versus-supercomputer.

An interesting aspect of the university, versus industry, is that the rank of a professor is much more explicit, such as the laddering of associate versus assistant versus full versus emeritus professor, respectively. Compare this with the wild variability of job titles in the technology industry https://www.levels.fyi/, for example. A principal at one company versus a partner at another versus....although https://news.ycombinator.com/item?id=25758663 recently had an interesting discussion thread on the topic.

Speaking of partner title, I still recall one MS partner architect telling me that partner is the 'throw the other guy under the bus' job band. This spoke to the highly competitive nature of the job category since like many domains the higher you advance leads to few openings and broader expectations with the competition to advance and challenge to sustain the level being commensurately intense. 

Even in my early late teens I saw a glimpse into this. At Cornell I recall a fellow undergraduate who had interned at Goldman. He related tales of other interns sniping at each other openly during presentations each was required to make. The same calculus applies - exclusive job category with high compensation, thus some 'throw them under the bus' behaviors.

Speaking of Cornell working on my BS EE https://www.ece.cornell.edu/ece during the 1988-1991 window, a few memories come to mind. The first includes the luminaries who visited campus, such as Normal Mailer and Roger Penrose to give talks. Penrose, Kip Thorne, and other physicists were drawn to a department that still had Hans Bethe https://en.wikipedia.org/wiki/Hans_Bethe. This was the same physics department that hosted the Feynman lectures. And for literature Cornell was the abode of the likes of Vladimir Nabakov, too.

Just like UW the professors made some of the largest impacts. These include Dynkin for real analysis https://news.cornell.edu/stories/2014/11/mathematician-eugene-dynkin-dies-90, Terrence Fine on probability https://www.engineering.cornell.edu/faculty-directory/terrence-fine, and the father of information retrieval Gerard Salton https://en.wikipedia.org/wiki/Gerard_Salton for discrete math. Cornell didn't just send TA's to instruct undergraduates but instead offered access to world class researchers in their fields.

Moving from maths to engineering, Prof Torng https://news.cornell.edu/stories/1997/12/cornell-professor-honored-intel-corp-his-computer-chip-improvement taught the course on digital design. K-maps, Mealy-Moore machines, etc. Good stuff. 

And closest to home there was Professor Gries https://www.cs.cornell.edu/home/gries/gries.html class on computability theory. This started with computational complexity, big-O notation, and other rudiments, leading into Hoare triples, such as pre-conditions, post-conditions, and invariants.  I still remember walking down the hall of the computer science building and seeing a room filled wall-to-wall with silver-covered Springer-Verlag "Texts and monographs in computer science."

Beyond visiting speakers and professors I recall lots of lake-effect snows and winds during the winter, and beautiful changes of seasons and the rugged environment of Ithaca, New York. There was a common theme on T-shirts and car stickers of 'Ithaca is gorges' as a play on the terrain and 'gorgeous' scenery up upstate New York.

Since I was so far from home and living on a budget, I would only return back to Houston for events like Christmas or summer. I recall one thanksgiving holidays eating at gas station since I had forgotten to do grocery shopping ahead of time. Other times I would travel to visit my aunt in New Jersey by way of New York Port Authority. Port Authority was definitely a stark contrast from bucolic Ithaca, NY or suburban Houston. I recall one trek through Port Authority when there was a body in a wheel chair parked outside of the bathroom. A sheet covered the bulk of the person but the hands were protruding with what looked like the stiffness of rigor. The crowd in the bus terminal where walking around the body as if it were just another obstruction on the path of their daily routine. Another trick I learned going through Port Authority with my suitcase was to put my money in my shoe. I'd leave $5 in my wallet so that when someone invariably wanted to 'help me' find my connecting bus terminal and then requested a gratuity because "you know I could be doing much worse to make money", I could satisfy the request and not get rolled for all of my traveling money.

When I think of growing up in Houston, or the US Southwest, doing undergrad in Ithaca in the US Northeast, and now leaving in the US Pacific Northwest, I'm mostly covered the continental US. Heat in the SW, cold in the NE, and rain in the NW. I'm only missing living in the US Southeast, such as Florida. But after reading Thomas McGuane's 'Ninety-two in the Shade' https://www.goodreads.com/book/show/51598.Ninety_two_in_the_Shade in my youth, I wasn't so anxious to move to that area.

Saturday, January 9, 2021

innovation and invention redux

In reading Bezos' book 'invent and wander' https://www.amazon.com/Invent-Wander-Collected-Writings-Introduction-ebook/dp/B08BCCT6MW he mentioned a couple of different problem solving techniques. The first includes a skills-forward problem solving approach where a team leverages what it knows to create products. This is more common in the industry and represents an amortization of an established set of capabilities and perhaps a given moat.' This is in contrast with a customer-problem first approach where you may need to invent a solution or build a competency. Bezos cited the Amazon Kindle which represented an approach to a customer problem, namely handling their library. And in pursuing solution of this problem, Amazon had to acquire skills in hardware development, create new models of cellular downloads, and evolve screen technologies..

Reading this passage coincided with the recent update of my patent list, namely hitting the 450 milestone of issued US patents, viz.,  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&d=PTXT&Query=apt%2F1+and+in%2FZimmer-Vincent$

As always with invention, I am as excited by the problem being addressed as my collaborators and co-inventors, including the following parties:

Yao, Chaganty, Ma, Rangarajan, Poornachandran, Aggarwal, Mudusuru, Zimmer, Yarlagadda, Chan, Das, "Enhanced Secure Boot," Issued 1/5/2021, US Patent #10,885,199

This small incremental increase cannot stem the tide of getting pushed further outside of the top 100 https://en.wikipedia.org/wiki/List_of_prolific_inventors

I fear, but the absolute number of patents was never the figure of interest. It has always been about supporting business-driven innovation http://vzimmer.blogspot.com/2013/12/invention-and-innovation.html.

Speaking of numbers, https://link.springer.com/book/10.1007/978-1-4842-0070-4 passed 300k downloads, too, during this same week.

The downloads on this book are probably 10x those of https://link.springer.com/book/10.1007/978-1-4842-6106-4, which speaks to the power of the open access model. I see similar diminutive numbers on other pay-walled publications, such as the Simics fuzzing paper with small double https://ieeexplore.ieee.org/document/9218694 and single https://dl.acm.org/doi/abs/10.5555/3437539.3437751 digit downloads, respectively.

Beyond downloads, another interesting statistic is citations. https://scholar.google.com/citations?hl=en&user=9fW87_IAAAAJ has the broadest collection of citations, whereas https://dblp.org/pid/34/5641https://www.scopus.com/authid/detail.uri?authorId=26325201900https://dl.acm.org/profile/81464676924, https://www.semanticscholar.org/author/V.-Zimmer/46617443, and https://ieeexplore.ieee.org/author/37088526460 find differing subsets.

2020 was quite an interesting year. Let's see if 2021 offers the same vicissitudes. Hopefully these ramblings about invention and numbers auger well for 2021. As I heard once, put a number next to someones name on the internet and they will obsess or do what they can to increase it. Twitter followers, LinkedIn connections, video views...... Hopefully I don't subscribe to that numeric obsession.

Saturday, December 26, 2020

operating system vendors and firmware

The PC industry has followed an interesting arc, beginning with the hardware and firmware details of the original IBM PC http://bitsavers.org/pdf/ibm/pc/pc/6025008_PC_Technical_Reference_Aug81.pdf and the closed source Microsoft (MS) operating system MS/DOS https://github.com/microsoft/MS-DOS. The former allowed for the ability to have clones of the IBM PC, whereas the latter ensured some consistency in the platform design as compatibility with DOS, and then Windows, helped provide for the open platform that non-MS OS's like Linux today enjoy. 

Was the distinction between MS as an OS vendor (OSV) and the industry as a platform provider always so stark? In fact, the existence of MS-written firmware, as one example, has had various examples spanning the 90's up through today's news. 


To begin:

In the early days of Windows NT, including 3.51 and 4.0, Microsoft wrote the ARC boot firmware for their DEC Alpha and MIPS NT platforms. ARC stands for Advanced RISC Computing https://en.wikipedia.org/wiki/Advanced_RISC_Computing and the document http://www.netbsd.org/docs/Hardware/Machines/ARC/riscspec.pdf provided guidance on both platform hardware and firmware. A couple of MS engineers wrote the first ARC firmware and the ARC specification, along with IEEE 1275 Open Firmware (OF) https://www.openfirmware.info/data/docs/of1275.pdf, were considered as a solution for 'how to boot Itanium' during the early days of the IBI/EFI specification. 1275 came up because the PowerPC port of NT booted via OF. EFI ended up looking more like ARC, see similarity between the ARC Firmware Function Vector and UEFI System Table, although OF does have some advantages, especially for security https://www.cs.cornell.edu/~kozen/Papers/acsac.pdf

Another interesting aspect of the ARC Alpha firmware was that the NT NDIS miniport drivers from NT were embedded in the firmware for purposes of pre-OS networking, such as network booting. Other than boot loaders like U-Boot which liberally leverages portions of device driver code, this OS and firmware code sharing helps solve one of the main challenges of boot firmware, namely having to create a firmware version of a device driver for the block, network, and console services in the pre-OS and another variant for the OS runtime. 




Fast forward to the early 2000's. At that time there was a project called FlexGo    https://en.wikipedia.org/wiki/Microsoft_FlexGo which allowed for a metered, or subscription PC.  There was MS firmware integrated into the code morpher, or microcode-like firmware of the Transmeta device https://en.wikipedia.org/wiki/Transmeta https://www.extremetech.com/extreme/76602-amd-to-resell-transmetas-payasyougo-chip. For some of the standard PC's at the time, there was exploration of having the monitoring agent from MS as an additional handler in System Management Mode (SMM) of the BIOS




In the early 2010's, the industry was moving from a TPM 1.2 to 2.0. One of the learning's from the 1.2 era was that the specification for the commands lent themselves to various interpretations. As such, the TPM 2.0 specification was written in 'literate code' where the C based implementation of the commands could be extracted. The latter C code has formed the underlying implementation   https://github.com/microsoft/ms-tpm-20-ref for all of the integrated and discrete 2.0 devices. This code was born of the 'firmware TPM' work described in the technical report https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/msr-tr-2015-84.pdf




In the 20-teens, there emerged from Microsoft Project Mu for BIOS https://microsoft.github.io/mu/. Although this is officially referred to as a downstream fork of EDKII on tianocore.org, there are many unique aspects, especially features like DFCI in https://github.com/microsoft/mu_plus.

A more recent example includes MS writing the SMM supervisor for AMD SecureCore PC https://www.microsoft.com/security/blog/2020/11/12/system-management-mode-deep-dive-how-smm-isolation-hardens-the-platform/ variant mentioned during OSFC '20 'hallway chat.'

And for the broader industry MS wrote many SMM audit and checking tools in Mu to help prepare the OEM ecosystem for having their handlers running in the jailed context of the SecureCore PC SMm supervisor.




In the future, MS hardware Pluton hardware and firmware https://www.microsoft.com/security/blog/2020/11/17/meet-the-microsoft-pluton-processor-the-security-chip-designed-for-the-future-of-windows-pcs/ may be even more deeply integrated.


Beyond the long run of the MS examples above you can see a similar, albeit shorter in time, arc for Google, especially Google as an OSV with respect to ChromeOS. It begins with the Google Chromebooks leveraging coreboot + vboot  https://www.coreboot.org/ where Google employees are many of the upstream maintainers. 




More recently, the Titan/OpenTitan  https://opentitan.org/ has emerged. This is a root of trust with the CPU based upon RISC-V and the operating system based upon the Tock OS https://github.com/google/tock-on-titan written in Rust. Interesting stuff.


And you cannot have firmware without hardware, of course. Google Titan-M and the OpenTitan are one example.

For Microsoft, MS already has its XBox360 https://en.wikipedia.org/wiki/Xbox_360_technical_specifications and XBox One https://en.wikipedia.org/wiki/Xbox_One, which were custom PowerPC "Watermoose" and AMD "Jaguar" based SOC's, respectively.

There are also always rumors in the air for MS, such as recent one on ARM https://arstechnica.com/gadgets/2020/12/microsoft-may-be-developing-its-own-in-house-arm-cpu-designs/ and earlier one on custom designs like E2 https://www.theregister.com/2018/06/18/microsoft_e2_edge_windows_10/.

For Google we already have ample public details on their Tensor Processing Unit (TPU) https://semiengineering.com/knowledge_centers/integrated-circuit/ic-types/processors/tensor-processing-unit-tpu/ and the above-listed Open Titan first party silicon, but these are not general purpose system on a chip (SOC). Of course even Google has the rumor mill swirling on occasion with stories like "Whitechapel" https://www.theverge.com/2020/4/14/21221062/google-processor-pixels-chromebooks-whitechapel-samsung-qualcomm, too.


So how does the OS impact the firmware? Well, since the firmware is closely tied to the overall platform and hardware design, OS 'requirements' documents http://download.microsoft.com/download/7/0/e/70e74967-b0fe-477a-974f-c1ed16ee31df/windows8-1-hardware-cert-requirements-system.pdf and https://source.android.com/compatibility/10/android-10-cdd can dictate some of these choices. And even for more open firmware implementations like Chromebooks you can see the coupling https://www.chromium.org/chromium-os/2014-firmware-summit.

Monday, December 14, 2020

musings about firmware cultures

In a quick journey around firmware cultures in this posting, I'll talk a bit about the recent Open Source Firmware Conference (OSFC) 2020.

The Open Source Firmware Conference (OSFC) started in 2018. It was a broadening of the coreboot conference to include other open source firmware projects. Some examples of the earlier coreboot conference include the 2016 https://www.coreboot.org/Coreboot_conference_San_Francisco_2016 where Intel talked about the ‘then recent’ UEFI Payload project https://youtu.be/I08NHJLu6Us and Intel FSP 2.0 https://youtu.be/uzfiTiP9dEM. I was invited to give the keynote of the inaugural OSFC conference in 2018 https://2018.osfc.io/uploads/talk/paper/1/OSFC_Keynote-005.pdf  There common themes such as chipsec, Slim Bootloader, Min Platform, coreboot, and Intel FSP were noted.


Now have FSP SDK   https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64 mentioned in that keynote, too.

Fast forward to OSFC 2020 https://cfp.osfc.io/osfc2020/schedule/ and you see many of the same sentiments being reiterated. Intel talked about extending Intel FSP for programmable service engine support https://cfp.osfc.io/osfc2020/talk/TNTFYV/, a more modern configuration mechanism https://cfp.osfc.io/osfc2020/talk/AS7EZR/, and the efforts https://cfp.osfc.io/osfc2020/talk/VUNDSC/ to have a more reusable payload  https://github.com/universalpayload. From those talks we then go to the efforts to remove dependencies upon SMM, including the Platform Resource Monitor (PRM) https://cfp.osfc.io/osfc2020/talk/MCJASB/

Beyond those talks, Jiewen Yao co-presented on the Security Protocol and Data Model (SPDM) https://cfp.osfc.io/osfc2020/talk/ECQ88N/ along with Xiaoyu Ruan. SPDM is a new standard from the DMTF for device and host firmware security that is critical for upcoming security initiative support. openspdm is a sample implementation of SPDM specification. It will be used in multiple device and host firmware implementations including UEFI EDK II and possibly other platform firmware, such as a Baseboard Management Controller (BMC) based upon OpenBmc, etc.

Beyond SPDM, Jiewen also shared the background and efforts with Virtual Firmware for Intel Trust Domain Extensions (TDX) https://cfp.osfc.io/osfc2020/talk/CRKZB8/. This effort entails open source efforts to help scale enabling for TDX and provides a venue to discuss aligning enabling with other confidential computing efforts like AMD Secure Encrypted Virtualization (SEV). The TdShim is also used as a foundation for any service Trust Domain (TD) for TDX advanced feature in an EFI-light environment, such as the virtual firmware for a container or virtual TPM services. It bridges the gap between TD startup and applications running, and it enables the customers building their own use cases on top Intel TDX.

Andy Jassy during re:invent this year also spoke about how change in large companies is often driven by outsiders since long-time employees are often reluctant to replace what they've built in the past. And in the spirit of change, Rust was a topic of a few https://osfc.io/ talks this year, including the virtual hallway track discussion.

Specifically Jiewen Yao and I presented on Enabling Rust in UEFI firmware https://cfp.osfc.io/osfc2020/talk/SLFJTN/. This is a complementary talk to those by Google on enabling Rust in oreboot https://cfp.osfc.io/osfc2020/talk/SLFJTN/ and Rome https://cfp.osfc.io/osfc2020/talk/TBSHA8/, respectively. Although these are early days, there is definitely a groundswell of interest to evolve how critical infrastructure code such as firmware is written, especially given the needs for more robust code and efficiency of the developer workflow. And as an example of that sentiment, since OSFC is a virtual conference, the closest thing to the ‘hallway track’ was commentary in the sharing tool, including the following exchange on Rust


Open Source Firmware Conference 2020

Bret Barkelew6 hours ago
I agree with Ron that now I've worked with Rust it's like pulling teeth when I have to go back. ;)
J. Redpath5 hours ago
a sign of something good
Vincent Zimmer5 hours ago
yes. moving from C to Rust feels like the same dynamic of moving from assembly-based firmware to C 20 years ago.
Diego Rodríguez5 hours ago

In addition to that hallway track discussion above, there were other hallway discussions in the Facebook session about UEFI versus coreboot complexity.This reminded me of the culture of UEFI and coreboot, or as I sometimes think, a "windows-bios" versus a "linuxbios." By that I mean the EDK code is written in the style of Windows kernel code and coreboot is written in the style of Linux kernel code.

To begin, coreboot literally started as "LinuxBIOS", as mentioned in chapter 4 of https://www.amazon.com/gp/product/B01JC1LDTY/. EDKII history is described in the "Beyond BIOS" article https://www.intel.com/content/dam/www/public/us/en/documents/research/2011-vol15-iss-1-intel-technology-journal.pdf.  

The reality of the latter is that Ken Reneris, mentioned in http://vzimmer.blogspot.com/2018/10/ghosts-of.html, created the original IBI/EFI core. He was a OS/2 and Windows kernel/Hal veteran who joined Intel in '98 around the time of the initial IBI effort. Ken brought along the same Camel Case coding style as Windows kernel code, the Containing Record (CR) https://edk2-docs.gitbook.io/edk-ii-uefi-driver-writer-s-guide/8_private_context_data_structures/81_containing_record_macro macro from ntddk.h into efi.h, TPL's from Windows IRQL's, .inf's, and the build command-driven build of the original EFI sample which became the EFI Developer Kit's I and II. CR's are pretty interesting in that it allows for a 'public' interface in a structure to have some appended, implementation-specific instance 'private' information. This allows for C++ keyboard functionality for public/private to be emulated in C code.

Speaking of the legacy of ex-MS Ken, the prevalent use of GUID's in EFI, along with the 'protocols', or GUID-named API's, bear not a small resemblance to COM https://en.wikipedia.org/wiki/Component_Object_Model. Think iUnknown versus HandleProtocol, etc. but forging COM's C++ infrastructure in C.

Ron, on the other hand, notes that the original LinuxBIOS was derived from Linux, thus it has stutter-case/Indian Hill https://www2.cs.arizona.edu/~mccann/cstyle.html coding standard, basic make support, and Kconfig as LinuxBIOS became coreboot. coreboot also started out as fully-open, whereas EDKII slowly released more sources of the last 20 years.

Beyond coding standards, the EDK-based implementations of UEFI always vied to cover the entire boot flow, from the tuple of {reset, silicon init, platform init, OS bootload phase} as {SEC, PEI, early DXE, late DXE}. DXE is both platform initialization and the UEFI core. coreboot, on the other hand, supports the same tuple as {bootblock, romstage, ramstage, payload}. The payload for coreboot could always have been a full kernel, as CSM-like compatibility module like Seabios, or today even a EDKII-Dxe implementation in the core of the UefiPayloadPkg. 

The richness of the OS bootload phase in coreboot is separated from the basic silicon and board initialization. With the DXE phase doing both platform initialization and OS bootload, the complexity of the latter ends up encroached on the former. The OS bootload code is highly reused and rich, per the UEFI specification, whereas board initialization is a high traffic area where board specific changes often occur and is the venue to host a lot of the bring-up and debug experiences.

Popping up from my trip down memory lane, OSFC also had debates between MS and others on the chat channel about the distinction between the general purpose platform where the OS producer may be different from the platform producer, versus a more vertical platform with the firmware and OS provisioned under the same authority.

Or the distinction between a full feature platform that supports a plurality of shrinkwrap OS's versus doing the minimum and letting the OS do the rest.

Another big distinction between the two is that EDK grew up initially closed and any of the open elements were released under a permissive BSD license. whereas coreboot grew up open with the GPL license. I was curious about the value of the GPL in firmware and received the following comment from Marc Jones many years ago  via the question 'why hoard SATA bug fixes?' EDK BSD allows for snapping the open source instance and not redistributing changes, such as bug fixes, whereas the GPL of coreboot, Linux, and u-boot obligate the party changing the GPL code to redistribute their fixes.

Luckily, there are more than a few common points of alignment between EDKII and coreboot today.  These include EDKII-based UEFI Payload Package for shrinkwrap OS support, both communities are pursuing unit tests w/ cmocka, ACPI is the predominate runtime interface, etc.

From those present-day alignments there are also some similar trends, such as the oreboot from C-based coreboot and the RUST-on-edkII investigation versus full EDKII C code

Speaking of EDKII implementations, in addition to the PDF of some of the OSFC talks, the videos of talks for OSFC 2020 can be found at https://vimeo.com/showcase/osfc-2020.

Beyond the OSFC talks, one can find the recently-published "Understanding the Trusted Boot Chain Implementation" at the following links  https://tianocore-docs.github.io/edk2-TrustedBootChain/release-1.00/https://tianocore-docs.github.io/edk2-TrustedBootChain/release-1.00/edk2-TrustedBootChain-release-1.00.pdfhttps://tianocore-docs.github.io/edk2-TrustedBootChain/release-1.00/edk2-TrustedBootChain-release-1.00.mobi, and https://tianocore-docs.github.io/edk2-TrustedBootChain/release-1.00/edk2-TrustedBootChain-release-1.00.epub. These binaries are compiled from https://github.com/tianocore-docs/edk2-TrustedBootChain. This material is above-and-beyond the recent book https://www.amazon.com/Building-Secure-Firmware-Armoring-Foundation-dp-1484261054/dp/1484261054/ and was created in order to provide guidance to communities, such as the Trusted Computing Group and TianoCore, on consuming and producing the measurements in a more interoperable fashion.

I also just noticed another security related EDKII publication, namely an insightful analysis of PE/COFF image loading https://arxiv.org/pdf/2012.05471.pdf.  This is close to home for UEFI and EDKII. The work reminds me of the more generic studies like https://eprint.iacr.org/2019/564.pdf. As you may have guessed from my earlier blogs and writings, I'm a fan of more formality and rigor in the pursuit of future-looking designs and validation, respectively.