Showing posts with label security. Show all posts
Showing posts with label security. Show all posts

Saturday, March 30, 2024

A legend passes

Sad to see the news about Ross Anderson https://en.wikipedia.org/wiki/Ross_J._Anderson passing

https://alecmuffett.com/article/109513

https://news.ycombinator.com/item?id=39864210

https://twitter.com/duncan_2qq/status/1773752269395099774 


Like many I was inspired and informed by his various editions of the "Security Engineering" book https://www.cl.cam.ac.uk/~rja14/book.html. I also explored the domain via papers like https://www.cl.cam.ac.uk/~fms27/papers/1999-StajanoAnd-duckling.pdf that I referenced in https://www.researchgate.net/publication/221199899_Platform_Trust_Beyond_BIOS_Using_the_Unified_Extensible_Firmware_Interface/references. I also cull wisdom from papers like https://www.cl.cam.ac.uk/~rja14/Papers/satan.pdf since having worked on the boundary of software and hardware for so long, sometimes errant hardware or firmware is truly an embodiment of 'Satan's Computer.'

My small interaction with Prof Anderson was during the writing of https://link.springer.com/book/10.1007/978-1-4842-6106-4

 


 My co-author and I reached out to see if Anderson would write a forward, with the below response


Luckily we did get a very insightful write-up


from Leendert Van Doorn https://blog.paramecium.org/about/.

This was an ironic pairing in retrospect seeing Anderson's critiques of Trusted Computing and Leendert's contemporary contributions to that domain, respectively. Having these titans both critique https://www.cl.cam.ac.uk/~rja14/tcpa-faq-1.0.html and build a domain https://www.amazon.com/Practical-Guide-Trusted-Computing/dp/0132398427, like TCPA (now TCG https://en.wikipedia.org/wiki/Trusted_Computing_Group) Trusted Platforms Modules, represent a healthy aspect of technology evolution in my view. Differing views make any technology stronger, versus groupthink & homogeneity of thought.

 Sad times for the security community, though, with the loss of a legend.





Saturday, December 16, 2023

Hacking in the southern hemisphere

Last week I had the opportunity to visit https://en.wikipedia.org/wiki/S%C3%A3o_Paulo for the Hackers 2 Hackers Conference https://www.h2hc.com.br/en/


 

I was invited to give a keynote on UEFI security


This is only the 2nd public keynote I have given in my career. The first was back in 2018 https://www.osfc.io/2018/talks/keynote/. The latter treated open source, whereas this one predominately covered security but with a taste of open source weaved in.

I was humbled to be in the presence of so many impactful speakers https://www.h2hc.com.br/en/articles/speaker.html. A taste of other researcher talks can be found in the h2h mention at https://twitter.com/rcvalle/status/1735790682646712505, including the follow-up blog post

 https://rcvalle.com/blog/2023/12/09/llvm-cfi-and-cross-language-llvm-cfi-support-for-rust/.

My topic 


 

visited some familiar themes but also included a snapshot of the latest work in mitigations https://github.com/vincentjzimmer/Documents/blob/master/H2H%20-%20Vincent%20Zimmer%20-%20The%20Story%20of%20UEFI%20(and%20its%20security%20mitigations).pdf.

I was impressed also with the BIOS hacking room where folks like

 


were writing BIOS, debuggers, and other low-level bits from scratch. One of the students brought out  

https://www.degruyter.com/document/doi/10.1515/9781501505690/html?lang=en and inquired about other learning resources. I realized I have been remiss in refreshing pages like http://vzimmer.blogspot.com/2020/12/resources-for-starting-with-host.html.

As always, the 'hallway track' is the most engaging aspect of the conference. Therein I happened to meet some local firmware security engineers


 and signed a copy of the firmware security book https://link.springer.com/book/10.1007/978-1-4842-6106-4 that they were using at the university


too.

The city was an interesting study in contradictions. Immediately in front of the hotel I was treated to the scene

 


 And nearby in one direction



Whereas a short walk in the other direction yielded a modern mall with high-end stores


And of course long lay-overs and flights provide an opportunity to think of some of my favorite philosophers, such as Alan Watts.



Interesting stuff.

 


Tuesday, November 1, 2022

Security Friends and Collaborators

I am humbled to be included among the list of researchers mentioned by Ilja van Sprundel https://hardwear.io/netherlands-2022/speakers/ilja-sprundel.php in the photo


https://twitter.com/hardwear_io/status/1585619730412486657 with the prezo https://hardwear.io/netherlands-2022/presentation/assessing-security-of-SMM-supervisor.pptx. I have huge respect for Ilja and the research he has done. I am also happy to see former Intel colleagues and co-authors Alex and John from https://www.usenix.org/conference/woot15/workshop-program/presentation/bazhaniuk listed, along with other former Intel colleagues Matrosov, Jesse, Mickey, Rodrigo https://www.blackhat.com/us-17/briefings/schedule/index.html#firmware-is-the-new-black---analyzing-past-three-years-of-biosuefi-security-vulnerabilities-6924, Yuriy, and Eugene. And it's only seemly having my present colleague Jiewen, who I also mentioned in the prior blog post http://vzimmer.blogspot.com/2022/10/a-tale-of-two-books.html, prominent on the list.

Speaking of John, I was reminded of him recently when reading a slack osf thread about CVE's and security. I still recall working with John when he came to Intel and took over leading the BIOS response issues. His first rebuke to me was the lack of an advisory process which led to the creation of the bespoke https://edk2-docs.gitbook.io/security-advisory/. This included the MOAP (mother of all patches) https://edk2-docs.gitbook.io/security-advisory/boot_failure_related_to_uefi_variable_usage. I still recall the strident feedback on having 'too much error checking' in a BIOS given the space constraints prior to MOAP. But threat models evolve, and from some of the same parties I was challenging to defend against errant i/o devices, with subject defenses now in place w/ IOMMU https://www.intel.com/content/dam/develop/external/us/en/documents/intel-whitepaper-using-iommu-for-dma-protection-in-uefi.pdf and testing https://ieeexplore.ieee.org/document/9218694. Since then the community worked on having a closed mailing list and private Bugzilla, including moving the community to be a CVE Naming Authority (CNA) https://github.com/tianocore/tianocore.github.io/wiki/Reporting-Security-Issues. As always, still challenges in remediating issues but also opportunities in creating new defenses.   

Similar challenges over time supporting more open EDKII platform code for a big core client https://github.com/vincentjzimmer/Documents/blob/master/A_Tour_Beyond_BIOS_Open_Source_IA_Firmware_Platform_Design_Guide_in_EFI_Developer_Kit_II.pdf



big core server https://github.com/tianocore/edk2-platforms/blob/devel-MinPlatform/Platform/Intel/MinPlatformPkg/Docs/A_Tour_Beyond_BIOS_Open_Source_IA_Firmware_Platform_Design_Guide_in_EFI_Developer_Kit_II%20-%20V2.pdf



and a small core client https://cdrdv2.intel.com/v1/dl/getContent/671281



And sometimes this early pathfinding landed me in some unusual situations. After helping advice the community on getting RISC-V support into EDKII 



and working through some of the UEFI PI changes, one of the collaborators added me to a prospective speaker list for a RISC-V summit. This summit agenda was mentioned by eetimes https://www.eetimes.com/google-hp-oracle-join-risc-v/ 

 as including HP and Intel speakers. That notification led to some interesting Saturday morning cell phone call following an email thread with a set of executives, all of whom are in this picture and no longer with the company. 



I explained my advisory role in the standards work as co-chair of the Platform Initialization https://uefi.org/sites/default/files/resources/PI_Spec_1_7_A_final_May1.pdf (the PI spec looks after the API's in the green H in the figure above, and EDKII is used to 'build' the green H) Working Group and I summarily corrected the error with the RISC-V conference chair. Thus we had an interesting point on the RISC-V arc in 2015 that has now led to 2022 and a more salubrious story from eetimes https://www.eetimes.com/intels-invests-in-foundry-ecosystem-embraces-risc-v/.

Regrettably I couldn't make OSFC this year, but I caught a few of the slides and prezos online. I appreciated having a mention at minute 5:55 of https://www.osfc.io/2022/talks/how-min-platform-led-to-max-coreboot-a-case-study/ for the relicensing of FSP https://www.phoronix.com/news/Intel-Better-FSP-License. And speaking of books, the venerable Beyond BIOS has a mentioned at minute 15:50 of https://www.osfc.io/2022/talks/i-have-come-to-bury-the-bios-not-to-open-it-the-need-for-holistic-systems/, and the new books in final slide of https://talks.osfc.io/media/osfc2022/submissions/YXYNPF/resources/The__Thing__Around_Your_System_Firmware_HiPr4Ug.pdf. 

Another OSFC talk that would have been interesting is https://www.osfc.io/2022/talks/collaborative-firmware-payload-handoff-design/. Luckily the speaker was able to reprise at the USF meeting this week https://www.youtube.com/watch?v=oEBtWsBZve4&list=PLehYIRQs6PR6J9Zf6CajwsFkAHedDXjLI&index=13. As always great to see the various collaborators.

and I bumped into Lean Sheng later in the area, too. Interesting details on use of https://www.devicetree.org/specifications/ in lieu of HOBs.

Some background on payloads in https://link.springer.com/chapter/10.1007/978-1-4842-7939-7_6 with presentations at USF at https://universalscalablefirmware.groups.io/g/discussion/files including CBOR https://universalscalablefirmware.groups.io/g/discussion/files/New%20data%20format%20for%20Universal%20Payload%20Interface.pdf and ARM https://universalscalablefirmware.groups.io/g/discussion/files/USF_meeting_4_May_2022.pdf.

Speaking of the new books and PI, the predecessor to PI was the "Framework." My co-presenter Bob Hart was giving my feedback on the 2022 books https://twitter.com/Apress/status/1585602975401140230



19 years after our joint prezo in 2003


And this morning I saw a patch on the EDKII mailing list that read on the network stack. It reminded me of that same 2003 IDF event where I gave another talk that included





This was part of the erstwhile "EFI1.2" specification that never came to light. Instead this work was contributed to the UEFI2.0 specification when the Intel-published EFI1.10 specification became the inaugural deliverable of the UEFI Forum in 2005. Since 2005 I have led the UEFI Network Subteam (UNST) in the UEFI Forum and I'm happy to have delivered some enhancements, such the "6" version of the above API's for IPV6 via the dual-stack model adopted by the UEFI forum for this space. After that the big lift was going from TFTP-based PXE to HTTP boot and bringing along more network-based security like TLS. Along the way other security enhancements like IPSec were removed, although not before a lot of the ecosystem shipped the upstreamed version with the test key https://www.cvedetails.com/cve/CVE-2021-28213/.

I have to admit that UEFI networking innovation has slowed a bit. The introduction of the HTTP boot & wireless missed the UEFI 2.3.1 specification upon which Windows8 and subsequent OS's depended upon so it didn't enjoy the broad industry enabling uplift at the time. And even if people want to continue using PXE because of its simplicity, work like https://uefi.org/sites/default/files/resources/7_Maciej%20Vincent_INTEL_network%20stack%20performance.pdf and its code https://github.com/tianocore/edk2-staging/tree/MpNetworkStack, driven by feedback from datacenter folks at the time, have been shadowed by move of many folks doing high-performance network deployment to https://www.linuxboot.org/ https://trmm.net/LinuxBoot_34c3/ and the scalable network stack maintained by the Linux community.

Heavy sigh. I'm definitely feeling the years.



Saturday, October 8, 2022

A Tale of Two Books

Let's start this blog by mentioning a recent specification posting, namely the 2.4 version of the FSP https://cdrdv2.intel.com/v1/dl/getContent/736809 that can be found at https://github.com/intel/FSP/wiki. One notable aspect of this specification is that several of the capabilities were incubated as part of the Universal Scalable Firmware (USF) 


[from https://universalscalablefirmware.github.io/documentation/1_terminology.html] effort https://github.com/universalscalablefirmware, including 64-bit FSP https://github.com/UniversalScalableFirmware/fspsdk/tree/qemu_fsp_x64 and SMM in FSP https://github.com/UniversalScalableFirmware/fspsdk/tree/qemu_fsp_x64_smm. The former was done by Maurice Ma, as noted by the github history, and the latter by Ravi. Another aspect of doing this work in the open was fabricating a QEMU-based FSP so that the platform code could be ported for these FSP interface changes. In the past the lack of a fully open source set of silicon code inhibited these what-if exercises (although we did have a public FSP for Quark Galileo but this was limited to a single, 32-bit CPU configuration). This continues a great collaboration with those colleagues, among many others, as cataloged by documents like https://www.intel.com/content/www/us/en/content-details/671333/a-tour-beyond-bios-using-the-intel-firmware-support-package-1-0-with-the-edk-ii.html.



For the SMM work in FSP 2.4 there is also the foundational efforts around having the stand-alone SMM incubated in https://www.intel.com/content/www/us/en/content-details/671459/a-tour-beyond-launching-standalone-smm-drivers-in-the-pei-phase-using-the-edk-ii.html and subsequently introduced into the UEFI PI spec as the "Portable Management Mode (SMM)." This work in '15 presaged this '22 FSP 2.4 work, viz.



Maurice and David are now at Microsoft and Giri is at Apple. Luckily I had a shot of David from those days we were both at Intel (the left picture) and I was also able to commemorate the Giri and Maurice collaboration in the past in http://vzimmer.blogspot.com/2016/04/colleagues-across-pacific_5.html




respectively, from the snapshot. Regrettably we missed Ravi at that lunch so I'll have to lift his photo from https://link.springer.com/book/10.1007/978-1-4842-0070-4.



Speaking of former colleagues and collaborators, a couple of books I co-authored with Subrata Banik have been published, namely "Firmware Development - A Guide to Specialized Systemic Knowledge" https://link.springer.com/book/10.1007/978-1-4842-7974-8 



and "System Firmware - An Essential Guide to Open Source and Embedded Solutions" https://link.springer.com/book/10.1007/978-1-4842-7939-7.



This effort started in the middle of the COVID crisis while Subrata and I both worked at Intel, namely with a publisher discussion in December of 2020. It followed on the heals of completing the "Building Secure Firmware - Armoring the Foundation of the Platform" https://link.springer.com/book/10.1007/978-1-4842-6106-4 which was published in October 2020 and featured Jiewen Yao as a co-author. You'll notice Jiewen 



as the lead author of the '14 whitepaper on FSP mentioned at the top of the blog, and also the author of the FSP measurement paper https://cdrdv2.intel.com/v1/dl/getContent/644001 listed in https://github.com/intel/FSP/wiki (which also references this latter Apress security book). This complements the presentation https://uefi.org/sites/default/files/resources/Traceable%20Firmware%20Bill%20of%20Materials%20-%2020211207%20-%20007.pdf from last December, too.

Regrettably the paths of Shanghai and Issaquah haven't crossed in a while


as you'll see with the next co-author below.

So the Jiewen book published in October 2020, and the two with Subrata in October 2022. That's 2000pp in the space of two years.  Yikes.

Although I don't have a photo with Jiewen, I did manage to dig up a photo with Subrata


These encounters are tougher as Subrata spends most of his time home overseas and also now works at Google. I was happy to run into Subrata as he transited through Santa Clara by way of Bangalore and I did the same by way of Issaquah, WA. 



Another nice aspect of co-authoring this last series of books is getting recommendations on the back cover, including the following.


I've had the honor to work with Mallik in the past while at Intel and also when he moved to Microsoft, including efforts like https://www.intel.com/content/www/us/en/content-details/671185/challenges-for-uefi-and-the-cloud.html


I have probably known Mallik the longest of the list, commencing with our work at Intel in DuPont, WA in the early 2000's. Mallik also shows up in the Beyond BIOS 1st edition https://www.amazon.com/Beyond-BIOS-Implementing-Extensible-Interface/dp/0974364908


from 2006. Other notables there includes https://uefi.org/sites/default/files/resources/UEFI%20RoT%20white%20paper_Final%208%208%2016%20%28003%29.pdf 



collaborator Michael Krau, who sadly passed recently, and now-retired former colleague Lee Rosenbaum of Excite https://www.usenix.org/conference/woot15/workshop-program/presentation/bazhaniuk and Secure Boot https://github.com/tianocore-docs/Docs/blob/master/White_Papers/A_Tour_Beyond_BIOS_into_UEFI_Secure_Boot_White_Paper.pdf collaboration. Glad to see Rob Branch on that list. I still fondly remember him from my Intel  October 1996 job interview team at Cornell Oaks in Oregon.

As always in this industry, I get excited by the technology but I truly cherish the interactions and the people. This blog provides some highlights on both dimensions of the journey. Still great technical collaborators that may have comprised the set COLLAB15 = {Intel, Intel, Intel, Intel, Intel, Intel, Intel, Microsoft,...} and now looks like COLLAB22= {Intel, Intel, Intel, Microsoft, Microsoft, Apple, Google, Microsoft,...}.


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.