Vincent Zimmer's blog

Tuesday, April 12, 2022

1000. Lies, #$(@ lies, and statistics

It was with some regret that I learned a colleague I admire is retiring. After our last meeting he shared the following picture from osfc 2018 that he took while we were in Germany.

https://2018.osfc.io/speakers/vincent-zimmer.html with the prezo https://2018.osfc.io/uploads/talk/paper/1/OSFC_Keynote-005.pdf

Speaking of osfc, my most recent osfc prezo https://talks.osfc.io/osfc2021/talk/HYZL3U/

mentions some upcoming books https://www.amazon.com/Firmware-Development-Specialized-Systemic-Knowledge/dp/1484279735/ and https://www.amazon.com/System-Firmware-Essential-Embedded-Solutions/dp/1484279387

Speaking of books and the arc of history, my co-author on the UEFI Shell and Beyond Bios books Mike Rothman shared w/ me his recent fan-driven wikipedia page https://en.wikipedia.org/wiki/M._A._Rothman. On that page I noticed the assertion "He holds over 1000 patents worldwide." This made me curious about how the page author ascertained that number.

As folks can see from the link, Mike has elected to spend his after-hours on writing sci-fi and fantasy books, whereas my spare hours continue on tech books, patents, etc. Given our split in paths, I was curious how close I was to 1000 given his claim above.

To begin my search, I found the old-ish https://goodip.io/iq/assignee/intel-corp where I note that neither Mike or I are listed. Most of the folks there are microarchitecture and process technology. And given it's an old page, I suspect their #'s are much larger and wouldn't imply Mike or I entering that top 10 international.

For the next examination, from my earlier analysis http://vzimmer.blogspot.com/2021/07/patents-and-co-inventors.html I note that Rothman was in the high 200's on US patent grants (https://en.wikipedia.org/wiki/List_of_prolific_inventors at 284 now).

Given that data, so how does the 1000 number come about?

Perhaps there is some confusion about espacenet, namely the link cited in the above wikipedia page https://worldwide.espacenet.com/searchResults?DB=EPODOC&IN=%22Michael+Rothman%22+or+%22Rothman+Michael%22 which lists 737 results for Mike. Regrettably 737 includes US applications and issued, so it's not so easy to glean international issued/granted from that #.

For example, my variant of above link is https://worldwide.espacenet.com/searchResults?DB=EPODOC&IN=vincent%20zimmer&ST=advanced&compact=false&locale=en_EP and lists 1265 items. I don't believe that's correct for me, either, for global granted patents.

So what is the truth?

I finally did some digging on my list and came up with the following #'s from my granted patents over the past 25+ years -

All patents (US + world) - 1037 as of 4/11/2022.

This means 459 US patents granted and 578 non-US patents granted.

The details of US and non-US grant numbers include:

11,074,085

11,249,748

10,761,951

11,061,692

10,929,146

10,852,988

10,649,918

10,382,489

10,251,060

10,564,986

6,633,964

10,262,140

10,031,993

7,392,371

ZL02825773.1

1485797

1068972

1485797

6,848,046

ZL02809670.3

10296798

1075718

10-0729793

7,260,848

7,103,529

ZL02819232.X

10297273

10-0692346

10,601,955

10,540,193

10,180,800

10,768,863

3382593

602018012850.6

3382593

10,546,156

10,474,473

10,503,523

10,394,295

10,552,613

6,978,018

7,243,353

6,775,728

ZL02822826.X

60217394.9

1449077

7,200,758

ZL200380105401.3

10393456

2410819

244483

4855679

5551130

I277904

7,127,579

7,254,676

ZL200380103263.5

2409747

4220469

I242746

7,143,277

7,543,048

7,974,416

9,026,773

10,275,598

ZL200380104038.3

2411989

2421612

I238357

7,320,052

8,130,960

8,842,837

6,996,641

6,993,608

7,082,523

7,263,605

8,108,665

ZL200380105211.1

10393859

2411498

I237790

7,080,246

7,421,431

7,653,808

7,583,591

7,231,512

7,681,027

7,222,258

7,284,136

7,107,440

7,549,055

8,010,799

8,364,974

9,710,647

7,134,125

7,395,420

8,281,116

7,082,509

7,136,994

7,107,441

7,174,451

7,051,215

ZL200480016970.5

602004041688.6

1634170

I247489

7,934,209

7,318,171

ZL200480005327.2

2414318

1077117

222852

I261748

7,444,667

7,222,339

7,328,340

ZL200480018100.1

7,475,233

ZL03156077.6

7,188,238

7,200,772

7,587,750

7,134,007

ZL200480018034.8

602004042829.9

1636696

4242420

1636696

7,730,205

7,478,141

7,082,527

7,483,974

7,146,512

7,107,388

7,159,105

7,243,167

7,478,176

7,380,136

7,434,231

7,562,230

8,127,150

ZL200480037167.X

121324

I280022

7,299,354

7,370,324

7,162,626

7,275,152

7,165,170

7,181,610

7,539,854

7,194,612

7,174,447

7,751,584

7,127,600

7,206,931

7,185,188

8,001,348

8,161,258

8,583,888

7,930,378

7,222,062

7,143,280

7,174,471

I265405

7,353,339

ZL200480038646.3

I292095

7,207,039

7,448,030

7,162,629

7,496,961

7,334,120

7,120,778

7,321,990

7,185,190

7,302,593

7,281,243

7,263,579

7,984,237

7,350,072

7,203,808

7,398,401

7,318,150

7,552,419

7,234,054

7,363,482

7,853,742

ZL200580013217.5

602005041610.2

1749266

4601665

1749266

7,421,533

7,739,527

7,269,768

7,048,877

7,290,178

7,340,616

7,788,460

7,370,188

7,543,166

8,943,346

7,310,725

7,364,087

7,243,222

7,246,224

7,281,124

7,653,727

ZL200580006193.0

602005047030.1

1727625

4664966

10-0855803

ZL200580006194.5

1728376

4579969

10-0831437

7,117,083

7,426,542

7,406,591

7,310,742

7,290,166

7,698,487

8,082,470

7,594,124

8,225,101

8,751,813

7,558,966

7,430,683

7,757,231

5042848

10-0984203

7,472,208

7,840,736

7,506,149

8,245,019

ZL200580017448.3

602005028329.3

1761837

4774049

7,711,965

9,135,470

9,654,464

9,942,219

ZL200580033440.6

602005047110.3

1805572

I314684

7,826,835

ZL200510132102.X

602005048479.5

1825703

4575958

10-1018213

7,181,293

7,305,544

8,745,364

7,366,891

7,383,450

7,373,551

7,694,298

ZL200580042442.1

4579298

10-0914077

7,281,127

7,752,428

7,660,913

7,409,575

8,862,785

9,891,929

8,286,169

7,451,301

7,581,037

7,293,184

7,278,006

ZL200580044889.2

602005040792.8

1839140

4802197

5167387

10-0907722

1839140

7,434,102

7,673,128

7,412,619

7,543,179

ZL200780009846.X

112007000688

I333144

7,617,400

7,398,382

602006049588.9

1856886

ZL200680005313.X

7,542,467

8,024,477

7,716,464

7,352,621

8,806,224

7,493,460

ZL200680032817.0

602006006846.8

1922617

7,373,537

7,441,112

8,046,576

8,862,862

9,465,623

7,543,287

ZL200680018961.9

4796625

10-0937062

7,734,934

7,580,701

8,032,117

7,870,373

7,774,846

7,516,336

8,195,968

8,595,526

9,158,362

7,478,196

8,327,192

7,647,474

ZL200680035585.4

602006024610.2

1934746

502011902004677

1934746

8,656,487

ZL200680035170.7

7,640,553

7,523,323

8,407,489

8,631,259

ZL200680033757.4

ZL201110308278.1

602006003912.3

1924909

1166389

7,480,791

ZL200680033756.X

7,793,127

7,584,374

7,634,629

ZL200680042498.1

I336039

7,631,206

7,461,299

7,725,747

7,555,641

7,660,977

ZL200710126426.1

10-1048914

7,930,728

7,370,175

7,716,421

I341464

ZL200780020629.0

7,889,685

7,840,398

8,368,711

8,786,622

9,448,828

7,818,558

8,082,431

ZL200710192949.6

5001773

7,886,190

7,685,376

7,721,080

7,406,560

8,266,238

7,765,440

8,510,859

ZL200710153796.4

9,235,707

602007038961.5

1906333

4775744

10-0989977

8,302,082

7,900,058

7,668,945

8,312,509

ZL200710170164.9

602007033774.7

1918815

4793733

5512610

10-0938305

1918815

2906661

2442348

10-0966398

1034453

7,594,077

7,987,458

7,941,624

9,384,039

7,673,126

7,788,475

7,945,841

7,779,244

7,822,960

7,596,714

7,689,817

7,627,718

ZL200710300216.X

8,688,965

ZL200810087275.8

7,987,348

ZL200810100361.8

ZL200810144638.7

8,984,265

ZL201410090626.6

602008052166.4

1975836

9,158,920

ZL200810127383.3

2017765

602008057777.5

2017765

7,747,846

7,761,701

8,452,950

7,890,811

7,882,341

7,818,560

8,645,965

10,585,702

ZL200810190343.3

7,900,033

7,987,349

9,047,491

7,827,371

8,458,726

7,793,090

7,873,846

8,402,262

8,185,886

8,391,913

8,649,818

7,831,858

7,900,084

8,583,908

7,962,738

ZL200810183979.5

5376928

8,839,356

ZL200810182279.4

2065800

602008054660.8

2065800

4896946

5410500

7,917,689

8,522,236

7,802,042

8,001,308

8,214,573

8,327,415

8,539,200

7,779,305

8,516,092

8,635,664

8,103,908

8,549,356

8,499,202

9,047,468

8,161,299

8,527,787

ZL200810188957.8

ZL201210028149.1

5636559

7,984,286

8,127,312

8,321,931

8,078,862

8,356,168

8,255,721

7,865,775

8,561,138

2207122

5350528

10-1208257

8,201,239

8,909,940

8,631,186

8,990,486

602009034009.3

2141625

ZL200810188988.3

2479666

10-1134816

8,910,169

ZL200910246861.7

2169514

602009056487.0

2169514

5532271

10-1114648

8,694,761

8,296,553

ZL200911000115.6

2189901

602009058867.2

2189901

5368947

8,296,528

8,086,839

7,953,916

8,463,972

8,832,454

ZL200910217300.4

2204755

2461264

2204755

2461264

2204755

5198422

10-1410078

10-1556818

8,151,027

602010032793.0

2239662

5497923

8,219,851

8,806,231

ZL201010621015.1

9,489,029

602010004816.0

2367091

5026579

10-1245442

2367091

9,015,268

ZL201110120401.7

5370897

10-1264521

ZL201180047970.1

8,539,245

2011285762

ZL201180048112.9

2601588

5705983

10-1518207

I467383

9,063,836

2011286271

ZL201180036850.1

2598997

5512892

10-1473119

I537967

8,522,066

9,098,300

ZL201110188572.3

5307196

10-1306395

8,312,258

ZL201180045466.8

602011036292.5

2596423

5540155

10-1407835

2596423

I482084

8,429,387

9,015,455

ZL201280037871.X

2729896

602012060184.1

2729896

5767751

10-1626397

9,367,327

I542992

8,370,667

ZL201180062019.3

5705996

10-1524961

I497289

8,499,141

ZL201180047390.2

602011021494.2

2601587

5607250

10-1370176

I521441

8,566,613

ZL201110153786.7

2395449

5301609

10-1312832

2510952

176870

8,479,017

2011271088

ZL201110165535.0

2397959

5394441

10-1276409

8,181,176

ZL201110179065.3

602011024271.7

2397943

5345652

10-1331311

8,739,177

ZL201110165550.5

602011002306.3

2398199

5275407

10-1444984

2398199

8,428,929

8,965,749

ZL201180046973.3

602011021514.0

2622533

5715256

5860504

10-1453266

I530872

8,977,871

ZL201080070815.7

ZL201610451692.0

5701399

10-1510028

8,607,040

2011329330

ZL201180055215.8

2641168

5606633

10-1512252

I524205

8,688,812

2011305211

ZL201180002816.2

5497190

10-1366913

I454924

8,386,618

ZL201180045848.0

2619679

602011059899.6

2619679

5657799

10-1465923

I482091

8,590,040

I499977

I564801

ZL201180075088.8

2761468

I468938

ZL201180075454.X

9,958,926

ZL201180074963.0

I512492

9,298,607

ZL201180075333.5

I566966

9,900,448

ZL201180076030.5

10-1646425

ZL201180076131.2

2798562

I476630

I515602

I599908

9,210,148

9,686,281

ZL201180049417.1

2798559

10-1359841

8,892,858

ZL201180075848.5

2795989

5890037

I477169

9,686,364

ZL201280071805.4

2831792

602012073987.8

2831792

10-1643072

9,251,347

ZL201280072136.2

2831788

5951879

10-1701014

9,507,937

9,262,178

2013215466

ZL201380007287.4

5893173

10-1609385

9,292,463

10,002,002

ZL201280075426.2

8,832,494

9,075,751

ZL201380004524.1

10-1618535

ZL201280075397.X

9,141,802

9,589,138

6096301

10-1775800

9,824,226

10,762,216

9,098,282

9,460,483

6105077

I502541

5,940,587

69838343.5

1038227

73695

ZL201380072535.3

6017706

10-1733903

9,311,177

602013022122.7

2959417

9,323,541

10,205,750

ZL201480008747.X

2973147

602014043689.7

2973147

ZL201380081151.8

10-1891420

9,832,172

ZL201380073058.2

2973139

6050528

10-1759411

9,223,983

9,563,775

2974123

602013061098.3

2974123

9,378,371

9,600,671

ZL201380079814.2

9,495,177

9,880,859

ZL201510093595.4

9,384,352

9,524,219

ZL201380079912.6

9,411,601

9,912,474

ZL201380080001.5

3063620

6272991

10-1861724

9,996,142

ZL201380077715.0

9,286,097

10-1915695

10,310,865

11,068,276

9,626,196

10,228,954

ZL201580009451.4

6316978

10-1891423

ZL201480076013.5

3120238

6466476

10-1920980

10,289,425

10,684,865

9,413,765

9,781,117

ZL201580010585.8

3123337

10-1823888

I556130

10,146,657

ZL201580010934.6

6297715

10-1931007

10,049,216

ZL201580003846.3

10,025,934

10-1802800

I601070

9,645,864

11,182,172

ZL201580003799.2

6152493

10-1826769

10-2219122

9,773,110

10,140,449

9,594,927

10,366,237

ZL201580042636.5

I546699

9,785,801

10,831,934

ZL201580028293.7

10-2244645

I570589

9,703,346

3158452

ZL201480079261.5

3161710

6481900

10-1881788

9,870,475

ZL201480079192.8

3161657

6396502

10-1896373

10,169,047

9,740,492

10,331,453

ZL201680011606.2

3274895

602016058368.2

3274895

9,589,155

ZL201580044960.0

I582637

ZL201580061649.7

3231129

10,389,788

9,817,673

10,592,254

10,185,547

ZL201680030406.1

9,525,675

ZL201580076833.9

10,372,491

9,626,227

10,067,805

ZL201680012778.1

3274827

6689873

10,430,589

ZL201680011476.2

10,496,974

ZL201680009786.0

10,747,884

9,836,307

ZL201680030403.8

3314416

9,612,887

10,445,154

6768710

ZL201580080108.9

10,664,573

10,223,187

9,858,412

ZL201680030338.9

3314444

ZL201580082636.8

9,691,278

9,998,284

10,218,508

9,769,169

10,069,826

10,432,627

9,798,641

ZL201611053849.0

6363153

10,061,424

9,977,682

10,776,524

10,496,388

10,158,671

10,776,283

10,635,607

10,581,815

10,592,670

Issuing bodies/countries beyond US above include Europe, WIPO, Japan, South Korea, China, Malaysia, Germany, India, Taiwan, Netherlands, Ireland, Poland, United Kingdom, Mexico, France, Singapore, Spain, Sweden, Finland, Italy, Australia, Brazil, ...

And another rub in my accounting is that some patents are done w/ McAfee, although the # is small.

Since my global patent isssued # is now greater than 1000, maybe I'll avoid doing this analysis again since I doubt I'll ever bump into another big milestone like 1500 or 2000.

And for Mike's 1000 issued, given I am > 150 ahead of him on US grants and he only has a handful of non-joint filings, I suspect he's not at 1000 global issue yet, especially since I have barely tipped that #. But I don't think I have the energy to dig into Mike's actual #. Maybe Mike's wikipedia fanbois can do that recon. Given this twisted path of analysis, thus the blog title https://en.wikipedia.org/wiki/Lies,_damned_lies,_and_statistics.

fin (97)

PS (4/24/2024) - my total # is now 1081 issued patents worldwide w/ Intel

Tuesday, March 29, 2022

Synthesize it?

I was happy to see the public SIMICS announcement https://community.intel.com/t5/Blogs/Products-and-Solutions/Software/The-Public-Release-of-Intel-Simics-and-More/post/1372402, including mention of the UEFI boot based upon the QSP work I got started https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/SimicsOpenBoardPkg. Also a good time to revisit what it will take to get https://ieeexplore.ieee.org/document/9218694 into SIMICS.

The posting also provided details on the SIMICS Device Modeling Language (DML) https://github.com/intel/device-modeling-language. Now that DML is open perhaps I can explore releasing the DML-to-TSL models from Termite2 https://github.com/termite2/Termite described in the https://www.intel.com/content/dam/www/public/us/en/documents/research/2013-vol17-iss-2-intel-technology-journal.pdf article. At the time of the Intel Technical Journal article we were prohibited from releasing the DML, thus hampering having a public demonstration of the full DML + UEFI device specification to working EDKII source code.

I have to admit that opacity of the information wasn't the biggest problem, though. The real issue was in the readability of the machine-generated code.

Similar to issues with 'certified code' like Certikos https://github.com/npe9/certikos. Coq proof to hard-to-read C code. And even if you can read the code, the idea is to do maintenance on the proof and not the auto-generated C code. seL4 tries to do proof on C code which is more aligned with today's development process. And given works like below were published in 1979, it's apparent that these issues are not trivial to solve

Perhaps the same semantic gaps exists with hardware design language innovation. The Scala based Chisel looks promising, but the SiFive folks mentioned in a Seattle training that their cores are optimized Verilog. This is an instance of the broader question of High Level Synthesis (HLS) to get more efficiency. At some point maybe economics will win. Good enough will prevail in the same fashion that we see the prevalence of Python even though it is wildly inefficient relative to C/C++/Rust compiled languages.

Synthesis from specification is definitely at the other extreme of today's copy-paste-modify approach to software development. I recall pushing the min-core, a stripped set of EDKII packages. The subset of sources helped with cognitive complexity but unless delivered alongside some additional business value, such as unit-test coverage, but the effort was deemed worse than existing code since latter had years of evidence-of-use.

I should add copy-paste-modify development (CPMD) acronym to my other sarcastic takes on Test Driven Development (TDD), such as Promotion Driven Development (PDD), Fear Driven Development (FDD), or....

Regarding such development anti-patterns, I still recall a comment about writing firmware in Rust will be 'too hard.' Seems to be a trade-off of difficulty in initial creation of critical code written in an 'easy' language like C and then mitigate the lack of rigor at compile time with field patching & updates. I look forward to when Rust practices like https://highassurance.rs/ can reach the same level of assurance and provability as ADA Spark.

Thursday, February 24, 2022

25 or Anniversary.Next^10 and early '22 rumblings

In the spirit of work anniversary posts, here's the successor to http://vzimmer.blogspot.com/2021/02/24-or-anniversarynext9-and-128-bits.html. This post signals the 25th year of working at Intel and 30 years in the industry.

Since I am so sporadic in blogging, I'll begin with some touches on recent work in the project Universal Scalable Firmware (USF) https://github.com/universalscalablefirmware. I described some of this work at https://talks.osfc.io/osfc2021/talk/HYZL3U/ and it was earlier picked up at https://www.phoronix.com/scan.php?page=news_item&px=Intel-USF-Firmware, too. The effort builds upon earlier work in FSP https://link.springer.com/book/10.1007/978-1-4842-0070-4 https://www.youtube.com/watch?v=uzfiTiP9dEM https://www.phoronix.com/scan.php?page=news_item&px=Intel-Better-FSP-License, including adding more traceability https://uefi.org/sites/default/files/resources/Traceable%20Firmware%20Bill%20of%20Materials%20-%2020211207%20-%20007.pdf. It also builds upon earlier OSFC-described work in https://cfp.osfc.io/media/osfc2020/submissions/SLFJTN/resources/OSFC2020_Rust_EFI_Yao_Zimmer_NDK4Dme.pdf and https://2018.osfc.io/uploads/talk/paper/1/OSFC_Keynote-005.pdf.

As always, the hallway track of the last OSFC was the most interesting. Regrettably with COVID this hallway track was a group chat session. I recall some interesting feedback, including 'binaries foster proprietary software development,' 'big companies realize they need to be open but the strategy often fails in middle management,' and 'big companies eventually do open source but some of the original drivers within the company get tired and leave.' As always, it's valuable to process all input and realize the lens through which it is delivered.

Beyond the business side, I appreciated the reference to Roscoe's recent OSDI talk https://people.inf.ethz.ch/troscoe/pubs/2021-07-16-OSDIKeyNote-Handout.pdf cited by one of the OSFC attendees in that 'hallway track' chat session. This talk really resonates with me and others working in this space at many levels. It includes how platform orthodoxy to 'just run a Linux OS' dictates platform architecture and the rich set of programmable compute elements and firmware in a modern platform. The latter has not been so visible historically to the broader research community but it has been the vocation of many of us for decades. I welcome the increased focus of academics in this domain since the ratio of security research attack talks to defense and academic research is deafening.

The above talks and research show that a career in the firmware space never ends. It's a journey with many fascinating stops and definitely the need to always learn and evolve. I still recall my first BIOS job in the 90's prior to Intel where one of the senior engineers said 'if you know MS DOS and how to debug a PC/AT BIOS you'll always have a job.' Hmmm.

Fast forward to February 24, 1997 with the bushy-haired, suit-wearing engineer who showed up in DuPont, WA http://vzimmer.blogspot.com/2017/02/this-one-is-for-20-or-anniversarynext5.html.

As I look at the things I've worked on, I am reminded of the quote regarding an ethos of 'missionary versus mercenary' when applied to your career. I know that it is something of a luxury to entertain that dialectic since extreme poverty would most likely preclude making that choice. In fact, I recall my father, who grew up as an orphan, reminding me 'money may not buy happiness, but lack of money can surely buy unhappiness.' As such, I believe there is a balance, and once the basic survival needs are requited, deciding which side of the fence you live on is key. Today's frothy job market and extreme compensation packages brings this dynamic up in stark contrast. But in general an interesting thought about career motivations. I fall on the side of missionary.

I do have to say that this is one of the most exciting times to be in the technology industry. From my early career visiting FTP sites on dialup modems with a 286 to today having multi-core, multi-gigabyte machines and the world-wide-web with its online videos, books, papers, and source repos like Github.

I became excited about Intel in the mid-90's reading about the company in magazines like EETimes and working on Intel technology, like bringing up a BIOS on a 430HX platform. When I was recruited to Intel to lead the 64-bit Merced/Itanium BIOS work, I was part of a 31% growth wave 1996 - 1997 https://www.chiphistory.org/chc_upload/content/pdf/19/1506018723/1506018723.pdf.

Along the way many colleagues have left for other companies, retired or passed away. In addition, my role afforded me the opportunity to work with many parties outside of Intel, whether it be a direct customer, community and government agency. From each I have learned various lessons. These include the perils of arrogance, especially when people confuse correlation versus causation (i.e., something that happened versus their making it happen).

I do recall one director who always seemed interested in the technology. I asked him why he took the management track. He recounted a tale of working as a compiler engineer at Burroughs early in his career and devoting himself to the project. One day an executive came in and cancelled the overall project. At this point the then-junior-software-engineer thought "I want to be the guy on that side of the table." He the then hung up his coding spurs and pursued an MBA. I admired this manage a lot and recall driving to Oregon for his retirement event. After decades at Intel and many projects he had set up a table with a placard in front of his various projects with a quote about his most memory impact. For UEFI I thought the card would say 'changed the ecosystem' but instead it said 'told the team to stop selling.' Less learned - check.

Another memory from that director included transitioning one of our internal product efforts from legacy BIOS to EDK. There was a heated debate in a forum, including a VP telling my boss 'our customers are not asking for this," with my boss replying loudly 'how can you lead on a strategy if you wait for the customer." This is a variant of https://www.businessinsider.com/steve-jobs-quote-misunderstood-katie-dill-2019-4

Some people say give the customers what they want, but that's not my approach. Our job is to figure out what they're going to want before they do. I think Henry Ford once said, 'If I'd ask customers what they wanted, they would've told me a faster horse.' People don't know what they want until you show it to them. That's why I never rely on market research. Our task is to read things that are not yet on the page.

that I've seen quoted with various degrees of verity.

I've been on this project long enough now, namely joining the EFI team in 1999 and having it re-org'd around me multiply, that I encounter people explaining to me why something I created was done. That's a good thing in my opinion since it shows people are thinking deeply and passionate about the subject.

Speaking of done, I have enjoyed the opportunity to work various endeavors after I was recruited out of Compaq in 1996 and ended up joining the company in February 1997. The path included creating the first 64-bit Itanium BIOS and powering on first workstation. The delay in Merced, and not yet having children, afforded me the opportunity to drive to the University of Washington in Seattle and take courses for my Masters of Science in Computer Science. Toward the end both the birth of my daughter and power-on's made this a tough road to follow. The experience with Itanium afforded my first glimpse into moving 'beyond BIOS', whether it was 64-bit SAL and the PC/AT BIOS atop it for late POST, moving to the workstation effort with the clean-room Kittyhawk code base written in C.

After that I moved to the EFI effort in 1999, helping deliver content from the EFI 1.02, EFI 1.10, EFI 1.20 (never shipped but a subset donated to UEFI 2.0), UEFI 2.0 through UEFI 2.9. EFI was always the higher level pre-OS OS or boot load environment, but other that the plat driver directory, it was decoupled from the underlying platform initialization. To that end, the Kittyhawk effort may have donated some interesting concepts, but the "Tiano" program with with the "Intel Platform Innovation Framework for the Extensible Firmware Interface" (aka. 'the Framework') provided a set of building blocks, including PEI, HOB's, DXE, Data HOB, CSM, SMBUS, HII, SMM, etc.

The Framework specifications informed the creation of the Tiano codebase, which consumed the original EFI sample to become the EFI Developer Kit (EDK). EDK led the charge for the early to late 2000's and was then replaced by the EFI Developer Kit II (EDKII). The latter introduced more modularity via Packaging, PCD's, base libraries, etc.

The EDK and EDKII code bases were posted to sourceforge originally and the latter is now actively maintained on Github. Most of the 10+ Framework specifications (sans data hub and CSM) were donated to the UEFI Forum, along with Framework-related patents, to become the UEFI Platform Initialization (PI) specification. The PI packaging specification was borne of the EDKII work and also donated, as was the UEFI Shell. Ironically the EFI Shell was conjured up in a few days to support the Itanium power-on, but it took on a life of its own thereafter.

Speaking of patents, Intel has afforded me the opportunity to work at various layers of the stack and get exposed to a plurality of problem statements. And it is the problem statements that are key to ideation in my opinion. One good problem can yield a wealth of patents. And the patents of course have to meet at least the criteria of novelty and value to my employer. The latter reminds me of the quote that 'if you are working on something that the business doesn't care it it's called a 'hobby.'' No time or budget for hobby-patents.

So for projects, patents, papers, books, standards .... the most memory aspect has always been the collaborators. Technology comes and goes, but people and relationships are the most important. From working on the original Itanium BIOS and simulation and then hardware, to Tiano first booting on the 815 (writing the C-based PEI core and platform PEIM's), to porting EFI to Intel's XScale in 2001, to porting EDK to x64 via both the 2-headed BIOS and 64-bit DXE, to ...

And on standards, from the Framework specifications (PEI, SMM - and getting an IAA for Tiano in 2004), PI 1.0-1.7, .... Collaborating on NIST 800-147 (and getting an IAA for scaling signed updates in 2012), NIST 800-193 (and today's drive for platform resiliency), Open Compute Project https://cdrdv2.intel.com/v1/dl/getContent/671185, network booting (clean-room network stack, IPV6 certified stack, RFC 5970 https://www.rfc-editor.org/rfc/rfc5970.txt, HTTP & WiFi boot), UEFI secure boot & signed updates, EFI TCG measured boot https://cdrdv2.intel.com/v1/dl/getContent/671466...... I have tried to journal some of these things at https://sites.google.com/site/vincentzimmer/cv over time versus citing the same sources here.

I apologize in advance if the reader has gotten this far. This is the 14th year of posting to this blog site and I suspect this entry may win the prize for being the most incoherent. I guess the 24x7 Work From Home (WFH), or is it 'Living At Work' (LAW), lifestyle is bearing down on me, as is the backlog of time off I've yet to use. At Intel we accrue an 8-week sabbatical every 7 years, or a 4 week one every 4 years. I took my first sabbatical in 2004 with my wife and small daughters, including an Alaska cruise, etc. Fast forward to 2011 and I fell off a ladder 2 days into that sabbatical, leading to 2 surgeries and rehab during those 2 months (although I recall 1-hand typing out my articles for https://www.intel.com/content/dam/www/public/us/en/documents/research/2011-vol15-iss-1-intel-technology-journal.pdf during those final weeks of that sabbatical).. So not so much fun in '11. Fast forward to 2018 eligibility - I continued to delay during the 3 year window, which was then extended to 4 year window, which is now extended to August '22 for expiry. Given the latter extension I am now eligible for both my 8 week and a 4 week. Add that to 4 weeks of potential vacation in '22, and I'm sitting on a potential of 4 mos. time-away. And in tech when is there an amicable time window to jump off this bullet train for a breather.....

Going forward, I see huge opportunities in the firmware space. These include some of the technology aspects of USF that allow for evolving the different layers of the stack at different rates. This includes safer languages and more rigor in testing/validation. https://twitter.com/veorq/status/1496177874264641536?s=20&t=SQKLjCN9DIykwSgU0pK6_Q reminds me of the ever present need. I am intrigued by the work described in https://www.amazon.science/blog/a-gentle-introduction-to-automated-reasoning. As an ironic twist of fate, the mention at the bottom of the page

A fun deep track:
Some algorithms found in the automated theorem provers we use today date as far back as 1959, when Hao Wang used automated reasoning to prove the theorems from Principia Mathematica.

seems invisible on the internet, at least the PDF. Luckily my pack-rat nature for books afforded me an ex-Lib edition of IBM Tech Journal from 1960

I regret that my fellow-travelers in the journey for more formal BIOS evaluation https://www.usenix.org/system/files/conference/woot15/woot15-paper-bazhaniuk.pdf are now retired, off to Eclypsium, or in the case of one of my heroes Mark Tuttle, off to the above listed Amazon Reasoning Group (ARG). I feel like we only scratched the surface in this space. Or maybe just a Quixotic question for a computing science Archimedes "Give me a lever long enough and a fulcrum on which to place it, and I shall move the world."

fin

Thursday, December 16, 2021

wither network boot?

I thought about pre-OS networking recently after giving a talk to other engineers about the value of EQ + IQ recently. For the latter, what I called "Technical IQ" in http://vzimmer.blogspot.com/2013/03/a-technical-career-path.html, I use the T-shaped model https://careeredge.bentley.edu/blog/2015/04/21/how-gaining-t-shaped-skills-will-give-you-an-edge/. For this model networking was in the depth or vertical bar of my T since evolving the EFI network stack from a simple legacy PXE & UNDI thunk wrapper in 1999 to the native mode implementation in the early 2000's, certifying a clean-room IPV6 stack, and further into scalable use cases with wireless and HTTP boot a half decade ago. In the late days of 2021 perhaps it's not as prominent in the vertical bar but it's an important capability nevertheless.

As part of this survey, this blog is an elaboration upon some arbitrary points on the timeline of UEFI firmware network boot history, in the spirit of older postings like http://vzimmer.blogspot.com/2013/02/anniversary-daynext-arch-ps-and-some.html. This latter posting mentioned the 1.2 work https://github.com/vincentjzimmer/Documents/blob/master/EFIS001_100_2004.pdf, including

client authentication w/ EAP https://www.semanticscholar.org/paper/Cloud-Net-Booting-Beyond-BIOS-Using-the-Unified-Zimmer/8f158dd172ca406095d051cc9bb5a7f5cc09435b and the folly of trying to create bespoke authentication methods.

This same work was described in the 2009 https://github.com/vincentjzimmer/Documents/blob/master/SAM6560.pdf paper https://dblp.uni-trier.de/rec/conf/csreaSAM/Zimmer09.html?view=bibtex in 2009, the same year as Berkeley Cloud paper that it cited https://www2.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.pdf. At the time is was becoming increasingly obvious that a HTTP-based boot was necessary. We in fact left provision for the same in https://tools.ietf.org/rfc/rfc5970.txt.

Page 97 of https://www.intel.com/content/dam/www/public/us/en/documents/research/2011-vol15-iss-1-intel-technology-journal.pdf notes the full move to standard network authentication protocols.

Another place I captured some history of pre-OS UEFI networking was in https://github.com/vincentjzimmer/Documents/raw/master/A-Quick-History-of-UEFI-Networking.pdf. This was just a quick background that I ultimately integrated into https://github.com/vincentjzimmer/Documents/blob/master/UEFI-Recovery-Options-002-1.pdf in 2016. This folds in advances such as UEFI wireless support and HTTP boot that I led through the UEFI Network (UNST) & Security (USST) subteams https://uefi.org/sites/default/files/resources/UEFI_Plugfest_VZimmer_Fall_2016.pdf, respectively, in the early portion of that decade. Commercial usage of HTTP boot was described by HP enterprise, too

https://www.uefi.org/sites/default/files/resources/FINAL%20Pres4%20UEFI%20HTTP%20Boot.pdf.

Although https://www.uefi.org/sites/default/files/resources/UEFI_Plugfest_VZimmer_Fall_2016.pdf updates after wireless UEFI boot, the suggested next paradigm of pre-OS network bootstrap of 'NVME over Fabric UEFI boot' has been evolved in the NVME standards group versus my UNST in UEFI https://linuxplumbersconf.org/event/7/contributions/737/attachments/531/944/LPC_2020_-_NVMe-oF_Boot_from_Ethernet_-_Final.pdf. I discovered that working the standard closer to the subject matter experts is best, just as I created the EFI TCG Protocols http://people.eecs.berkeley.edu/~kubitron/courses/cs194-24-S14/hand-outs/SF09_EFIS001_UEFI_PI_TCG_White_Paper.pdf in the Trusted Computing Group versus the UEFI Forum.

At other times it is satisfying to see evolution of requirements that support important use cases. There has been a spate of activity in enabling https://csrc.nist.gov/publications/detail/sp/800-193/final over the last several years, including the low level infrastructure code like https://github.com/vincentjzimmer/Documents/blob/master/A_Tour_Beyond_BIOS_Capsule_Update_and_Recovery_in_EDKII.pdf. The idea therein entails having the platform having some degree of fault tolerance on the system board firmware and device firmware.

Beyond 193, though, there are scenarios where the operating system can become corrupted, such as infamous https://www.tomshardware.com/news/malware-shamoon-virus-security-disttrack,16988.html. There are some early thoughts about options here https://www.it-scc.org/uploads/4/7/2/3/47232717/requirements_for_recoverable_systems.pdf that happen to nicely match some of the OS recovery infrastructure defined in https://github.com/vincentjzimmer/Documents/blob/master/UEFI-Recovery-Options-002-1.pdf, especially figure 7 of the latter mapped to figure 2 of the former

which not surprisingly bear resemblance to

During that effort above on OS recovery it was noted that although we defined UEFI network support in the UEFI standard and some infrastructure for the same in https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/Supplicant.h, great support for multi device and protocol was available in https://ipxe.org. In fact, ipxe has historically been a favorite of datacenter operators using firmware based networking, including the ipxe scripting https://ipxe.org/scripting. In fact after talking with some hyperscalers in the mid 2000's, I tried to create a 'safe shell' subset to use .nsh in lieu of ipxe scripting for deployment w/ UEFI network stack to provide coequal, and in the limit script-compatible behavior between ipxe and UEFI. This didn't work out for various technical and community reasons.

This usage of ipxe in the pre-OS speaks to the challenge of OS-absent networking. There has always been a complain that UEFI didn't solve one of the fundamental systems problems, namely needing to write drivers twice: once for the boot environment, and once for the OS. Vertically integrated folks like Intel UEFI Apple Macs can have a OS kernel engineer and firmware engineer who is a domain expert do both, but in the horizontal industry where the OS providers and platform provider are different business entities, this is more difficult. And historically the OS folks eschewed using firmware at runtime, even for safe mode, which led to deprecating UNDI at runtime.

In the past some of the DEC Alpha platform manufacturers wrapped Windows NT NDIS drivers in the Arc firmware, but this was only the port level, datagram interface. The higher level networking primitives had to be curated for each domain (pre-OS, OS runtime). Other challenges in pre-OS networking include security - the support of packets on the wire (or air with wireless) are a huge attack surface since the incoming packets are ostensibly attacker-controlled data. The use of hardware VPN's can ameliorate some of this concern for deployments in the traditional enterprise, but the world of borderless/zero trust architectures moots that argument.

One potential approach to more robustness may include using language-based security, such as Rust and implementations such as smol https://github.com/smoltcp-rs/smoltcp? In the early 2000's I explored with Linux kernel EFI maintainer Matt Fleming on some options about encapsulating Linux in the pre-OS for the network stack and then returning to the UEFI environment to boot the downloaded image. There were a lot of intricacies about state of the platform in absence of exit boot services and other blockers that put that exploration on the shelf. At the time there were already a lot of usages of embedding Linux in the flash as the boot environment, but it was a one-way gate from UEFI. UEFI->Linux. Never a UEFI->Linux->UEFI->Final OS.

It is nice to see that latter use-case having been re-invigorated in the last few years with https://www.linuxboot.org/ in the datacenter. Instead of UEFI netboot->Linux or the chain loading of UEFI netboot->ipxe->Linux, you have the platform firmware, UEFI or coreboot or slimboot or....based, directly launch Linux and its integrated networking support from the system board flash.

In addition to the interesting works Trammel Hudson has done in firmware security, I am happy to see his work in this space of using Linux for pre-OS networking https://trmm.net/LinuxBoot_34c3/. This includes a recent patch to run interleave UEFI and Linux execution, or the design point Fleming and I explored years ago, viz.,

The other historical irony I have to mention about LinuxBoot and firmware relates to a conversation I had on the showcase floor at the Ubuntu Developer Summit in Oakland, CA 2012. My colleague brought Mark Shuttleworth over to have a conversation, ostensibly about UEFI secure boot and some of the other recent features I had been working on in this space. Shuttleworth nodded his head in response to the overview and then left me with the single question: "Why don't you just use Linux as the firmware to boot the operating system?" Of course supply chain, horizontal industry COTs, .... and the myriad of other social, technical and business reasons from my confirmation bias vantage of working on UEFI and EDKII didn't really empower me to have a quick answer :)

So we mention LinuxBoot above which obviates the need for the UEFI network stack in some use-cases, especially Cloud. That doesn't mean that UEFI networking isn't important. In fact enterprise and client devices still deploy the capability today, and it definitely has challenges, including performance and robustness. On the former, we noted some of the glass jaws on the polled UEFI driver model and its impact on perf in https://uefi.org/sites/default/files/resources/7_Maciej%20Vincent_INTEL_network%20stack%20performance.pdf and the associated implementation using LWIP and multiprocessing https://github.com/tianocore/edk2-staging/tree/MpNetworkStack. For security we can go beyond just the forklift upgrade of a Rust port and near-term isolate the network stack drivers in ring 3 or user mode https://github.com/jyao1/SecurityEx/tree/master/UserModePkg or put into a VM https://www.intel.com/content/dam/develop/external/us/en/documents/a-tour-beyond-bios-launching-vmm-in-efi-developer-kit-ii-0-819978.pdf. In fact after the 2007 paper laying the ground work for UEFI secure boot in SAM07 https://www.semanticscholar.org/paper/Platform-Trust-Beyond-BIOS-Using-the-Unified-Zimmer/0bd3bdeb6dcadf088137e13c00adc7e4390fa0de was 2008 https://www.semanticscholar.org/paper/System-Isolation-Beyond-BIOS-using-the-Unified-Zimmer/cf0261fe8d8dc078fb389dc04a56188695581949 including VMM and rings for firmware.

Firmware device interrupts http://vzimmer.blogspot.com/2015/06/guids-revisions-interrupts.html, ring isolation, multiprocessing, etc all seem to argue for just diving into a full operating system, but a deft hand can still apply some of these design precepts into pre-OS firmware. Driving change is hard, though. I recall a quote from a colleague about another engineer 'he spent a lot of time working on a problem that engineers (at the company) didn't want solved.' In other words, a good business problem isn't enough. For various historical and / or cultural reasons the existing engineering community may not want to pursue a solution. A mental model I sometimes use for this engineering reluctance is WWI/WWII. Leaders who came up in some technology era understand the guardrails and technologies for success there - mapping to WWI they are great trench builders and trench warfare combatants. And the ultimate example of trench warfare skills was the Maginot line https://en.wikipedia.org/wiki/Maginot_Line.

Technology changes. Say going from mainframe to mini, mini to PC, PC to Cloud/post-PC, anything to mobile, ...... A phase and its successor may represent a different corpus of technology or business constraints. Let's call one of these transitions going from a WWI to WWII based technology environment. When WWII commenced, airplanes just flew over the Maginot line. Just like your real competition is yourself professionally, not others, the way to leverage this insight is to avoid trying to leverage your trench-digging skills when the world war precepts have changed, and more importantly continually evolve skills and practices. As for the sentiment in the quotation above, a technologists should take a constructive approach that includes providing data on the environment change and technical options that can inform the organization of potentially evolve the bench from WWI to WWII class readiness.

OK. Enough on this topic of the past. If there are any more postings in '22 they will catch up to more recent events and commentary in the firmware space.