Showing posts with label Measured Boot. Show all posts
Showing posts with label Measured Boot. Show all posts

Tuesday, September 24, 2024

Reflecting on my time at a tech company (aka 'Retiring from Intel')

I've queued up some blog drafts over the last couple of months but I haven't been able to generate the energy to finish them. They just didn't seem to have enough bulk to them.

So why posting now and with this 'new' content?  

Well, I want to share that I have elected to retire from Intel after 27.5 years. My last day will be September 30. While I'm moving on to the next chapter of life, I'll always cherish the time I spent at Intel. 

And in fact it is with no small amount of temerity I write this message, especially after receiving so many soulful and impactful farewell messages recently from Intel colleagues also opting into this retirement package.  I'm somewhat 'late' in penning my message, I'm afraid (at this point in time I haven't sent out the broad bcc'd "I'm leaving" email).  And then there's my all-time favorite parting message I captured from Sham at the end of the https://vzimmer.blogspot.com/2023/05/open-platforms-snapshot-may-2023.html posting that I could never hope to emulate. 

But emulate I won't. In fact, I'll write this as I do most of my postings, sort of a rambling message to myself; on this sentiment I'm apparently not alone given quote of another 1.5 decade blogger "I keep this blog for me to write, not necessarily for others to read." https://www.jonashietala.se/blog/2024/09/25/why_i_still_blog_after_15_years/. For this particular post I couldn't figure out where to insert a 'TL;DR' since I sometimes think that could be the title or theme of this whole blog series :) I only regret that I won't have a reason to author a successor to https://vzimmer.blogspot.com/2024/02/27-or-anniversarynext12-ai-runtime.html

So for more of the TL 'too long," rewind the clock 32.5 years to my first five years post-undergrad in industry prior to Intel.  In those early days of 1992 back in Houston I was introduced to BIOS and embedded firmware development using Intel technology, from the i8051 through i80186 … and culminating with the P6. Beyond the data sheets, I also immersed myself deeply in Intel driven specifications like PCI and I2O (although forgotten by PCI SIG and intel.com, many still live on at https://bitsavers.org/pdf/intel/). These experiences ranged from poring over the black cover data public tomes of data books to the yellow-cover NDA documents, while continually being intrigued by what was happening at Intel via reading reports on the company in print periodicals like EE Times; this was the early 90’s prior to the internet going big.

Who knows? Maybe some of the work I contributed to at Intel, whether papers or books or specifications such as mentioned in https://vzimmer.blogspot.com/2021/01/books-and-computers.html, might end up at bitsavers some day, say Beyond BIOS https://www.amazon.com/Beyond-Bios-Implementing-Extensible-Interface/dp/0974364908 will have a URL like the RMX book http://www.bitsavers.org/pdf/intel/iRMX/iRMX_III/Real-Time_and_Systems_Programming_for_PCs_1993.pdf?

Given my early exposure to Intel, imagine my delight in getting recruited by Intel to lead the development of Itanium firmware for the Merced CPU in late 1996 and joining the Intel High-End Server Division (HESD) in February 1997 in DuPont WA. The Intel recruiter told me that I could ‘go to Hillsboro for Xeon or Dupont for Itanium.’ I wasn’t familiar w/ any place in the PNW so the obvious choice was to join the Intel 64-bit wave! Prior to joining Intel, I still recall my Compaq manager saying when I served notice “I guess you’re going to Portland Oregon” when in fact I was heading to Washington state. Commencing in ’97 I was now part of the mission to help create the technology behind those great products and standards I’d admired so much.  

Since then, I truly realized the saying of Steve Jobs 'The only way to do great work is to love what you do,' and I've truly loved working alongside such talented and dedicated individuals in this work. That was the missing link from my pre-Intel days, namely the broad experience with Intel employees.

Speaking of people and technology and standards, now more than half my life, or these last 27.5 years at Intel, have more than exceeded my hopes, but it’s the people with whom I’ve collaborated, learned, and grown I appreciate the most.  Thank you all for creating a positive and inspiring work environment. From co-creators of the SAL+NuBiOS & SAL+AMI ‘Salami’ firmware for Merced in HESD, the Workstation Product Group (WPG) Kittyhawk native C code that booted Intel P3 on 840 Rambus and Merced 460GX w/ either the AMI 630 ‘furball’ or the EFI sample as the late-stage payloads. Then off to Microcomputer Software Lab (MSL) in MD6 to work on the hit series of scaling EFI from 0.92 to today’s UEFI 2.11, along with “Tiano” that yielded EDK->EDKII and the Intel Platform innovation Framework for the Extensible Firmware Interface (e.g., “Framework”) specifications that have become the UEFI Platform Initialization (PI) specifications of today. This latter work spanned orgs from MSL to EPG to SEG to SSG to SATG to DEG to my final home here in CCG. I guess the only platform group I missed was embedded, although I enjoyed collaborating with those folks from ACSFL in the late 90’s to today’s slim bootloader.

I suppose I can date the badges by BDE or ADE ('Before drop-e' or 'After drop-e') https://vzimmer.blogspot.com/2014/01/advances-in-platform-firmware-beyond.html.

It’s open source platform code like slim bootloader, coreboot, and EDKII features/platforms that have occupied the last 10 years of scaling the Firmware Support Package (FSP), ….. along with the primary mission of FSP to have a clear business boundary between Intel owned versus customer codes. With this last decade also including contributing to NIST 800-193 platform firmware resiliency and recovery.  And and and ….

...and booting.  Measured boot, UEFI Secure boot, ipv6 boot/netboot6, HTTP boot, boot-from-Wifi.....Sometimes I'd use 'booting from a sneaker' as a variant of the Toaster or Fabrikam sort of pedagogic fake device, but given Bluetooth and smart accessories/shoes I suspect this one will fall into the 'life imitates art.'

And I could take a whole detour on security and friends long past. Someone said I was the final member of the below bench to exit. John of PSIRT, Yuriy of threat research, Kirk of all-things-SMM security, ... Zimmer as the UEFI security guy. I still recall a colleague saying 'bring boxes of the Intel Press Beyond BIOS and Shell books. The visitors will love them.' Given the muscle ache from both lugging them down to Portland and back to Seattle I couldn't help but think of the Harold Ramis quote in Ghostbusters that 'print is dead.'  Even those many years ago no one wanted those bulky dead-tree texts.


Beyond the tech milestones, I still recall a few words of wisdom from a now-retired colleague. One was ‘the best architecture is sometimes knowing what to leave out’ (I heard it but didn’t necessarily always practice it) and the other was ‘I don’t know why people don’t get it, but BIOS can be a great career.’  And a great Intel career it has been. Another was ‘the higher leadership ascends you’ll find the more impactful decisions they have to make with successively less information.’  So my take away is that you should take it easy on the bosses, especially in tough times.

And there is my 3-tuple of advice I sometimes give others and myself:  ‘business first, team second, and career third.’  To me this means focus on the business priorities first, even if they transcend your team’s charter. Next help develop and foster a strong team environment for the mission to collaborate on these business challenges.  And a distant third is your career.  I don’t mean to imply career growth is unimportant but more that if you focus on the business priorities and the team, a well-managed company will acknowledge your efforts.  

Also, observe where the interesting problems are being worked and good team cultures exist. Given that insight, when given the opportunity to engage in such focus areas and collaborators it may help your career long term.  And 'keep learning.' This may sound a bit strange coming from me since a boss recently said ‘...and if you don’t want to keep learning then just “retire”.  I personally hope to do both, but the exhortation to 'keep learning' is golden irrespective of one's employer or employment state or age or.....

And given this is a wrap-up sort of blog, I've probably repeated a few themes mentioned before. Some are quite important, though, such as 'it's the people that matter.' Projects and tech come and go. The people are the key invariant of value. For example, sometimes folks think I get excited by books and patents, but it's the co-authors and co-inventors that thrill me. I may forget a book chapter or set of independent claims, but I'll never forget the rich set of colleagues with whom I toiled shoulder-to-shoulder on these endeavors. And these endeavors match my triad of biz/team/career in that they were all done to help further a business strategy, secondarily they entailed team collaboration (sometimes co-authors outside of team or company), and at the end of the day, they may have helped (or hindered) my career arc. As long as I hit #1 and #2, though, I'm at peace.

Other wisdom? Don't bash other technology. I still regret writing 

twenty years ago in  https://www.researchgate.net/publication/377810413_TechnologyIntel_Magazine_-_Advances_in_Platform_Firmware_Beyond_BIOS_and_Across_all_Intel_R_Silicon. You win by being good, not by belittling the competition. And the fact that the PC industry for 20+ years had shipped on this 'monolithic', 'space constrained' BIOS rebutted my argument And to be honest, Tiano in 2004 wasn't the exemplar of software quality and stability.

I find a kindred soul in Prof G's advice that 'work life balance is a myth' https://www.raconteur.net/talent-culture/scott-galloway-work-life-balance-work-from-home but the part I perhaps erred on is ignoring the qualifier 'when you are young.' I have kept this unbalance through 3+ decades :) But it has been a great trip and I can see doing more when there are opportunities to dent some more https://www.goodreads.com/quotes/950437-we-re-here-to-put-a-dent-in-the-universe-otherwise.

I not sure what the next phase of the journey will be, but I couldn't help but laugh when reading this cartoon from the New Yorker recently. I sort of put my own spin on it, although some may say it reads well in its original.


And I sure have quite a reading backlog to attack (see background of posts like https://vzimmer.blogspot.com/2021/11/books-old-age.html). 

Regarding timing of this event, my Fidelity advisor said 'you can retire but there is the risk of you getting bored.' And a retiring Intel security Fellow opined 'you are too young to retire.' In retrospect I realize that I may be a bit junior to many of the 'retirement' cohort I see exiting since I dove head-first into tech w/o MS+PhD or military or ...et al hang-time. But given the exponential arcs of so much happening in tech and the richness of the world, I suspect I can find many a palliative to the specter of boredom (more 'dent' opportunities - see above).

Speaking of 'fellow,' that was definitely a milestone I had hoped to achieve in my quarter-century tenure at Intel. I try not to be sour grapes and think of the externally-hired-in fellows who only had to align with Professor Galloway's 'it's easy to fall in love with someone for an hour' when comparing external versus internal promotions. Instead I'd say Intel offered many open doors for me and perhaps I simply stumbled into the door jam? It was never aspiring toward the fellow role just for the sake of the title. Instead, I view achieving a fellow promotion as both an acknowledgement of the observed fellow-level impact plus the ability to have more insight into and ability to help advise the business (i.e., a bigger platform to help make those 'dents in the universe').

Regarding that out-of-reach cohort, I did have a chance to leave a small mark for system software next to the Fellows and Senior Fellows, as chronicled in https://vzimmer.blogspot.com/2021/07/patents-and-co-inventors.html and https://vzimmer.blogspot.com/2022/09/new-milestones.html. Recall the century-milestones I related of:

From https://levels.fyi

If not fellow, I have at least tried to level up to my 'Senior' taxonomy this year, though, by applying for senior member status of the ACM https://awards.acm.org/senior-members/award-recipients?year=2024&award=159&region=&submit=Submit&isSpecialCategory= 

and the IEEE, respectively


I just made it into 'senior member' under the 30 year milestone of my time with IEEE, for example. So I'm exiting this tech company as a pure-play 'senior' (e.g., Intel Sr. PE, Sr. member ACM, Sr. member IEEE), it seems. What's next on the 'senior' theme?  More senior moments undoubtedly, sliding into senior citizen-hood, ....?

So now to prepare for the next months. One colleague who left from another tech company years ago into Intel told me it took him 2 years to get over leaving his last shop. And another colleague who left Intel for a FAANG company a couple of years ago told me that you fade away quickly from people's memories at Intel, easily within 2 years (2 mos., 2 days, 2 hrs?). So I guess the overlap is 'getting over' job.last and being forgotten by colleagues.last :)

Time.  Time.  As I sit on 12 weeks of accumulated sabbatical (closing in on 16) & a vacation free recent couple of years, I suppose the universe with this 'enhanced retirement package' has finally figured out a way to make me close my Intel laptop lid. And close it I shall. 

In closing, my personal tell is that once I’m done with the meat of a conversation I start philosophizing too much.  And on that note it’s time to end this conversation since my philosophizing has eaten the word budget on this post more than usual.

Thank you all and good-bye,

Vincent

PS if you ever need to contact me, my info is at the top of https://sites.google.com/site/vincentzimmer/cv


Saturday, February 2, 2013

32 versus 64 bit and measuring UEFI Secure Boot

This blog begins with a discussion of the execution mode of the pre-operating system (OS) and the operating system run time (RT).   This is a question that comes up often, so I wanted to given some overview and history.

32v64 - The OS view of the world
We'll being with the OS-visible portion of the pre-OS, or the UEFI boot services (BS) environment.  For today's 64-bit (aka x64) operating systems, you need a 64-bit kernel to be booted from 64-bit UEFI firmware.  Or BS and RT execution modes need to match the kernel execution mode.  Similarly, a 32-bit OS kernel needs a 32-bit RT and 32-bit BS.  For example, x64 (aka x86-64, EM64T, AMD64, Intel64....) Ubuntu or Windows8 need to have x64 UEFI.

On this point UEFI differs from 16-bit PC/AT BIOS where you can boot 16, 32 or 64-bit kernels.  In 1982, BIOS was 16-bit, as was Microsoft DOS.  The I/O subsystem of DOS was the BIOS, so the DOS run time calling into the 16-bit BIOS int-calls worked out well.   DOS was single-threaded, BIOS calls are blocking, and everyone was happy.  This worked through Windows3.1 where DOS was still effectively the kernel.  The tension in this model appeared with 32-bit OS's where the kernel would 'thunk' or make down-calls into BIOS when necessary, alongside the 32-bit native driver model with VxD's.   With NT and beyond, though, the kernel would have native drivers such that the BIOS was only used for booting.  Same story for Linux with its pure native drivers.

And on the point of booting, the first stage OS loader would typically stay in 16-bit mode in order to read the kernel from disk or network using 16-bit BIOS calls.  Then the kernel would trampoline into 32-bit mode in order to run the native OS kernel.  When x64 came on the scene in the mid-2000's, this trampoline process was extended to go from 16-to-32-to-64 bit mode.   

The notable point on PC/AT BIOS and OS run times today is that modern OS kernels do not invoke 16-bit services after the initial loader.   This is distinct from EFI/UEFI with its 'runtime' (RT) services which are by-design intended for OS kernel invocation.

Specifically, UEFI, on the other hand, took a different path.  The original EFI 1.02 specification in 1999 had an IA32 (aka x86) binding that was 32-bit only.  EFI antedated the relase of x64.  EFI1.02 continued having only the IA32 binding.  When x64 became public, it was still prior to 2006 and the standardization of EFI as UEFI.  Intel owned the EFI specification at the time and pondered how to address support of x64.  One side of the EFI house advocated today's behavior where the firmware Instruction Set Architecture (ISA) mode == kernel ISA mode, whereas a smaller group was in the camp of a modal solution.  

Enter the '2-headed firmware.'   The idea of the firmware having two modes or 'heads' was to forever keep EFI as 32-bit and having the ability for a 32-bit or 64-bit set of run time services to be published from the firmware for the kernel (32 or 64) to call.'  

The requirement for the kernel to match the firmware begins with the ISA mode of the EFI RT.  To support run time services, the kernel maps the EFI run time and directly calls into it from ring 0.  Since the EFI run time is defined to be the same as the EFI boot services in the EFI system table, RT and BS must be the same.  This leads to the model where if you want to boot a 64-bit OS, you need 64-bit firmware.   Modern OS eschew 'thunking' or down-calling into 32-bit mode from a 64-bit kernel, unlike the practice of doing this from user mode (e.g., WOW64 in Windows and capability binary support in Linux).

So back to the 2-headed BIOS versus the pure 64-bit firmware.  Both solutions were built, but it was quite tricky to implement the 64-bit RT.  We ended up with building a shim that invoked an SMI so that the bulk of code shared between 64-bit and 32-bit RT was handled by the Framework SMM DXE code (i.e., SMM driver model prior to the UEFI PI).  The 64-bit EFI was cleaner since the mode of EFI is also the mode of DXE, our EFI core.  And with the UEFI 2.0 specification in 2006, the 64-bit work was contributed and became one of the central features of the industry-owned specification.

For a refresher on UEFI versus PI, check out Beyond BIOS http://www.amazon.com/Beyond-BIOS-Developing-Extensible-Interface/dp/1934053295/ or chapter 3 of Hardware Dependent Software http://www.amazon.com/Hardware-dependent-Software-Principles-Wolfgang-Ecker/dp/9048181283/.

After all of the that, you can see why ACPI and its static tables and interpreted AML byte-codes are the preferred run time interface to the platform for PC/AT BIOS and UEFI systems today.  The co-location of the UEFI RT with the kernel in ring 0 and some of the vagaries listed above in implementation argue for not growing the corpus of UEFI RT capabilities.

32v64 - The platform construction view of the world
You will note above some discussion of DXE along with the EFI ISA mode work.  Just as the UEFI RT dictates the UEFI BS mode of operation, the UEFI BS mode dictates the Driver Execution Environment (DXE) mode of operation since the Framework and UEFI Platform Initialization (PI) DXE forms the core of the EFI and UEFI interface sets, respectively.   The same holds true for Framework and PI SMM in the DXE is the SMM loader, so the ISA mode of DXE boot service-time became the mode of the SMM DXE.   Once the die was cast for 64-bits, almost everything in the pre-OS became 64-bit.

"Almost everything" was the case because there are a couple of modes of operation prior to DXE, namely the SEC and PEI phases.  These two phases commence after a processor reset.  Even with the advent of x64, Intel Architecture CPU's still commence operation in 16-bit mode.  As such, the SEC phase mode switches to the PEI mode of operation.  PEI can execute in 32-bit or 64-bit mode.  Some of the complexities of 64-bit long mode entail larger binaries and having to run with paging enabled.  These can be covered by budgeting for the flash space for larger code images and setting up ROM'd page tables with the AD bits pre-set so that page fault walkers don't panic trying to update read-only PTE's.  The advantages of having the ISA mode of PEI and DXE match also include having codes from PEI that can be passed into DXE and re-used, such as the PE/COFF loader and the report status code logic.  The latter is especially important in that prior to loading the DXE architectural protocols, a HOB proxied report status code pointer can be used to update the boot progress during the grey period between PEI hand-off and DXE start up.  32-bit mode, on the other hand, can run in physical mode without paging.  Since such PEI execute in place (XIP) codes rarely need greater than 32-bit addressing and need to be penurious on code size and data usage because of cache-as-RAM size limitations, today PEI implementations are typically 32-bit and the final PEI, or the DXE IPL PEIM, will mode switch to 64-bit as part of invoking DXE Main.

So in summary, the ISA mode of the firmware and the OS kernel is not so simple of a story, and the story is again distinct from the ISA mode of the early PI phases of execution.

So enough on 32-bit and 64-bit.   

Note (3/4/14):  Matt Fleming has an experimental patch treating booting a 64-bit Linux kernel on a 32-bit UEFI platform https://lkml.org/lkml/2014/3/4/242 

UEFI Secure Boot - Measuring Policy
The other thing I wanted to mention was a recent publication on MSDN, namely the Trusted Execution Environment (TrEE)  EFI Protocol and measurement updates, which can be found at http://msdn.microsoft.com/en-us/library/windows/hardware/jj923068.aspx.  This publication is important because the language toward the end around PCR[7] logging of the UEFI 2.3.1c PK, KEK, and DB/DBX addresses one of the architectural gaps of scenarios that employ both measured and secure boot.  Recall that the paper "UEFI Networking and Pre-OS Security" at https://noggin.intel.com/content/uefi-networking-and-pre-os-security-0  describes the relationship of measured and secure boot.  Specifically, on page 94 of the same, "...Measured Boot must include the Allowed, Forbidden, KEK, and PK variables (databases) in its measurements of a Secure Boot-configured platform."  As a result, the measurement language in the TrEE protocol provides a solution for recording the state of the UEFI Secure Boot enforcement policy.