Showing posts with label Grove. Show all posts
Showing posts with label Grove. Show all posts

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. 
https://www.amazon.com/Intels-Architecture-Designing-Applications-McGraw-Hill/dp/0079113362


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.






in its many translations:  English, Chinese, Portuguese, Japanese, Spanish, and Russian.

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, the CEO 




when I joined in 1997, and Gelsinger, upcoming CEO this year, expressed both their technology and business insights via writing. 

[from top down]

https://www.amazon.com/High-Output-Management-Andrew-Grove/dp/0679762884

https://www.amazon.com/Only-Paranoid-Survive-Exploit-Challenge-ebook/dp/B0036S4B2G

https://www.amazon.com/Juggling-Act-Bringing-Balance-Family/dp/1434768740

https://www.amazon.com/Physics-Technology-Semiconductor-Devices-International/dp/0471329983

https://www.amazon.com/Programming-80386-John-H-Crawford/dp/0895883813



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. 

Tuesday, October 27, 2020

Silicon valley, innovation, and logos

As we near the end of SeptemberOctober I realize that I haven't updated this blog in a bit. Sometimes my entries are inspired by recent events or material I bump into, such as https://spectrum.ieee.org/tech-history/cyberspace/todays-internet-still-relies-on-an-arpanetera-protocol-the-request-for-comments. This format is refreshingly simple when I compare the effort in curating the https://www.rfc-editor.org/rfc/rfc5970.txt versus some of the more painful processes in other venues.

Speaking of ipv6, I remember visiting Facebook in 2011 or 2012 to help with some UEFI ipv6 network boot issues. Since we didn't retrofit IPV6 boot to legacy PXE, datacenter folks going all ipv6 https://www.datacenterknowledge.com/archives/2010/06/10/facebook-deploys-ipv6 UEFI was the only game in town for deployment. I still recall the rough, open interior of the Facebook campus https://www.theregister.com/2011/02/08/facebook_in_menlo_park/, but the best memory was when I was leaving. My host walked me through a courtyard and a recall passing a building with a windowed corner office where I saw Zuckerberg leaning back in a chair in his T-shirt with a phalanx of suited men standing in front of his desk. It was as if a king of yore was holding court with his many knights and vassals. Fascinating stuff.

People may decry the "Fall of silicon valley" https://www.robrhinehart.com/the-fall-of-silicon-valley/, but from my first trip there in 1997, to that 2012 trip, to the training session http://www.chromium.org/chromium-os/2014-firmware-summit/2014%20Chrome%20OS%20Firmware%20Summit-%20Overview.pdf at the CHM https://computerhistory.org/, to my last trip to Intel HQ last year....



including catching a glimpse of Grove http://vzimmer.blogspot.com/2014/02/anniversary-day-next-next.html 




Speaking of Grove and his collected wisdom



such as "disagree and commit," there has always been a battle to enforce this, including folks who might "disagree and de-commit." Regrettably, for '20 a new one has crept in. namely, "agree and ignore. But as always, a culture is only as strong as the folks who continually fight to uphold it. 

Regarding values I now find myself often using the triple of 'business first, team second, and career third' to explain to engineers the priority they should use in their career. Namely, focus on solving business problems first, even if the issues are outside of your organization. Next ensure that you have a healthy team and support your organization. Finally, worry about your career. Mistakes often happen when engineers put their career's as a first priority. In the latter case it may yield a small local victory but in the end is corrosive to both the business and the team.

In addition, the I found the value of 'always leaving' to be of interest from the Google culture https://www.oreilly.com/library/view/software-engineering-at/9781492082781/. It doesn't mean that you should always be switching jobs but instead it argues that employees always ensure that they provide sufficient documentation and collateral such that they can 'leave' a role for a more important mission and easily have someone take their place. Someone once remarked "I guess that I have job security since my code is so complicated." That's not demonstrating 'always leaving' but instead a more pernicious 'always nesting.' And in fact the reply to that person was that such a type of code will lead to disruption because long term the business cannot sand for that state of affairs.

Beyond Grove's book and recent musings in the Google text, some of the insights from Amazon are quite interesting. These include the role of PE's in their organization https://deloitte.wsj.com/cio/2020/09/16/at-aws-engineers-drive-architecture-shape-products/ to the Builders' Library https://aws.amazon.com/builders-library/?cards-body.sort-by=item.additionalFields.customSort&cards-body.sort-order=asc. The latter is interesting in that it solves many problems - a scalable way for PE's to mentor, and by providing the material publicly, demonstrates the expertise and competence of their technical leads to customers along with their internal population.

Beyond 'ignoring' and other things, I do like the quote "Innovation takes something that people use and improves upon it. "from the above-cited "Fall of Silicon Valley" article. I should reprise my thoughts http://vzimmer.blogspot.com/2013/12/invention-and-innovation.html on this topic. 

On the subject of improvements, we are also trying to enhance the workflow across many different firmware technologies, such as slimboot, coreboot, and PI-based implementations like EDKII - the span of which we discuss a bit in chapter 1 of https://www.springer.com/us/book/9781484261057, too. This work includes an effort to allow for interoperability between these environments via a more standardized 'payload' We have a draft specification at https://universalpayload.github.io/documentation/spec/spec.html and various implementations of payloads, including Linux https://github.com/universalpayload/linuxpayload and EDKII https://github.com/universalpayload/edk2, alongside various bootloaders like slimboot https://github.com/universalpayload/slimbootloader and coreboot https://github.com/universalpayload/coreboot to invoke the payload. The latter will grow to EDKII Min Platform, Oreboot, and the former to U-Boot and potentially Skiboot or Hostboot.

In addition to curating works on the universal payload above, the earlier-promised 'FSP SDK' mentioned in slide 20 of https://2018.osfc.io/uploads/talk/paper/1/OSFC_Keynote-005.pdf is being developed in https://github.com/universalpayload/fspsdk.

Regarding additional improvements, we continue to explore Rust for firmware, including the talk https://www.youtube.com/watch?v=dCu0-frSURE and presentation https://uefi.org/sites/default/files/resources/Enabling%20RUST%20for%20UEFI%20Firmware_8.19.2020.pdf. We elaborate on these points in chapter 20 of the upcoming https://www.springer.com/us/book/9781484261057, too. 

In addition to improving code through language based security, the boothole vulnerability led to some interesting exchanges on Twitter https://twitter.com/vincentzimmer/status/1290377140223934465, including a curation of the various defense-in-depth activities underway for EDKII https://github.com/jyao1/SecurityEx/blob/master/Summary.md. This work is something that the tianocore infosec https://github.com/tianocore/tianocore.github.io/wiki/Reporting-Security-Issues can help drive, along with tightening up the CVE allocation process https://cve.mitre.org/news/archives/2020/news.html#September182020_TianoCore_Added_as_CVE_Numbering_Authority_CNA. Writing CVE's appears to be as much art as science.

The NSA also weighed in on UEFI Secure boot usage in https://www.nsa.gov/news-features/press-room/Article/2347822/nsa-releases-cybersecurity-technical-report-on-uefi-secure-boot-customization/, including https://trustedcomputinggroup.org/wp-content/uploads/TCG_EFI_Platform_1_22_Final_-v15.pdf. The latter has an interesting list of contributors who have moved on - Lee and Wooten and Springfield retired, Shiva at HPE, Bill at Amazon, Monty at GE....

I guess that I've been on this project too long. I even saw a reference in the TPM dev miniconference to figure from https://people.eecs.berkeley.edu/~kubitron/courses/cs194-24-S14/hand-outs/SF09_EFIS001_UEFI_PI_TCG_White_Paper.pdf. This was before Brogan became master of Mu https://github.com/microsoft/mu_tiano_platforms and when I had a lot more hair.

Ironically I even find people who sometimes try to explain to me the intent behind some thing I created 20 years ago. Recently it was some nuance of the PEI infrastructure. I didn't have the heart to tell them that I invented the item in question, wrote the initial implementation and the specification on the topic, too. Or mention why the Terse Executable (TE) image has the 'VZ' signature. I just smiled and nodded by head. Ah, youth.

As a final thought, the Intel logo change inspired a trip down memory lane http://vzimmer.blogspot.com/2014/01/.

The new logo https://images.anandtech.com/doci/16063/20200902172826_575px.jpg



is pretty compelling.

And on that I think I'll close on this, a happy note.

Happy & safe continued quarantine to those in geo's with restrictions.


  

Monday, March 21, 2016

Open Compute 2016

I just returned from the Open Compute Project (OCP) U.S. Summit 2016 in San Jose. I gave a talk on firmware updates http://ocpussummit2016.sched.org/event/68u5/towards-a-firmware-update-standard. The talk has also been posted to Youtube  http://www.youtube.com/watch?v=3yGbwUwwjxc. I This talk builds upon the background provided at the 2015 OCP and UEFI PlugFest, respectively, as described in the "UEFI and the Cloud" posting https://firmware.intel.com/blog/uefi-and-cloud.

For this talk we laser-focused in on the firmware update topic. I received feedback, such as "Good message this morning, glad you guys are interested/passionate about OCP from a FW ecosystem sanity perspective."

The material has a home at http://www.uefi.org/sites/default/files/resources/OCPsummit2016_Towards%20a%20Firmware%20Update%20Standard.pdf, but it should get posted to the OCP website shortly.

One of the messages we wanted to provide is that the UEFI Capsule interface is both a host-based API. From the UEFI specification we have the interface to send a capsule (from http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf)
 and then the EFI System Resource Table (ESRT) to detect what are the capsule-updatable elements (from http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf).
 Beyond the API we have the envelope or data payload (from http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf):

All of these elements are brought together in the graphic from the prezo and former white papers (from figure 5 of https://firmware.intel.com/sites/default/files/resources/UEFI_Plugfest_2015_Challenges_in_the_Cloud_Whitepaper_0.pdf):


Our advocacy in the 2016 talk was that even if the update is delivered out-of-band, say via a service processor, the data envelope should be the same. Imagine an independent hardware vendor (IHV) curating an update blob. Why tax the IHV to create separate blobs for different delivery paths?

Going forward we will work with other standards bodies like the DMTF http://www.dmtf.org/, along with OCP opencompute.org and the UEFI Forum uefi.org, to harmonize these efforts. And along with the standards work engage with open source upstreams like tianocore.org to have a robust implementation. And given https://github.com/tianocore/tianocore.github.io/wiki/Coreboot_UEFI_payload it would be great to have co-equal support in both firmware ecosystems, including coreboot.org.

PS
Sad news today about Andy Grove https://newsroom.intel.com/news-releases/andrew-s-grove-1936-2016/.  It reminds me of my early days at Intel, including the signed copy of his man of the year issue I received as a new employee at Intel http://vzimmer.blogspot.com/2014/02/anniversary-day-next-next.html.