And the world keeps changing

 I'm a long-time fan on Twitter. I still recall merging onto I-5 years ago and listening to some tech podcast about this new 'micro-blogging service', namely Twitter. I still keep up with https://twitter.com/vincentzimmer and don't worry so much about the vagaries of ownership or management. But I was intrigued by the discussion of other services like https://mastodon.social/explore. As such I setup an account and posting some material akin to what I saw from another Twitter person regarding some personal metrics for 2022 https://mas.to/@vincentzimmer/109549960566794774, including a reply to myself with another random observation this week https://mas.to/@vincentzimmer/109550056099262201.

This is my first post to mastodon: 

"Interesting 2022. First journal pub https://www.mdpi.com/2410-387X/6/4/48 although waiting for red box on https://dblp.uni-trier.de/pid/34/5641.html. I also had oppty to collaborate on an IEEE conference http://www.ieee-smart-world.org/2022/uic/index.php mentioned in http://www.ieee-smart-world.org/2022/uic/uic-2022.htm. Then a couple of unrefereed items https://embeddedcomputing.com/technology/security/software-security/understanding-uefi-firmware-update-and-its-vital-role-in-keeping-computing-systems-secure and https://eprint.iacr.org/2022/1049. Then 2 books https://link.springer.com/book/10.1007/978-1-4842-7939-7 and https://link.springer.com/book/10.1007/978-1-4842-7974-8. A podcast https://www.youtube.com/watch?v=wqcUWAEHcVg. 6 US patent filings and 7 issued.  Whew."

and

"Speaking of https://eprint.iacr.org/2022/1724, it was referenced by https://eprint.iacr.org/2022/1724. 

Latter doesn't read in on PQC aspects of SPDM but provides a formal verification of extant SPDM protocol using a theorem prover https://github.com/tamarin-prover/tamarin-prover with public proofs https://github.com/AnalysisSPDM/FormalModel. Perhaps this is a use-case to leverage for achieving a long-held ambition, namely axiomatize and 'prove' some tricky parts of UEFI, viz https://uefi.org/specs/UEFI/2.10/08_Services_Runtime_Services.html?highlight=authenticated#setvariable and EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS?"

I try to be pragmatic about formal. I recall reading once that even in the days of the Orange books with A-level certification requiring 'formal proof' it was hard to achieve, but the attempt at least 'provided better documentation.' And at a professional level I've always mutated the 'culture trumps strategy' aphorism to be 'implementation trumps architecture.' A painful reminder of this dichotomy is having studied https://www.cl.cam.ac.uk/~lp15/papers/Auth/tls.pdf back in the day and then meeting Marsh Ray and learning of his work https://troopers.de/events/troopers10/242_history_of_the_tls_authentication_gap_bug/. Networking has been close to my heart for a couple decades as I helped grow our EFI network stack from its nascent PXE equivalent in 1999 through IPV6 https://www.rfc-editor.org/rfc/rfc5970.html and into HTTP and TLS (e.g., HTTP-S boot). I still recall reading the Rescorla book on SSL/TLS while waiting for my older daughter to be born in 1999 at the University of Washington hospital.

Perhaps if I have the opportunity in the future to use my sabbatical

I can do some thinning of the archives. Rescorla and Rudin have aged well, but I suspect I can sunset the Java duo of Aglets and JavaOS. On the other hand, though, I'm a fan of keeping around some documents of 'old tech' since there is often wisdom to be gleaned from the past.  Hmm. Decisions, decision.

Well, to close on formal, specifications, and networking, I should tie off that thought at least with a re-invocation of as always, there is no 'silver bullet.' 

These mastodon posts feel like my usual terse blog posts. Perhaps my posts are 2xM or 3xM (i.e., 2 or 3 times the text length of a Mastodon post).

This blog is usually pretty low traffic, too. The sources of eyes are either google searches or link via https://www.amazon.com/stores/Vincent-Zimmer/author/B002I6IW4A (which included the blog links) or blogroll like https://blogs.coreboot.org/. 

With the removal of the former, I suspect there will be less traffic. That should be fine. I don't do sponsored ads or other revenue-generating activities here. It's more of a personal set of footprints in the sand to chronicle the journey.  

And luckily https://en.wikipedia.org/wiki/List_of_prolific_inventors has been curated to just the top 100, so watching my slow descent down the leader board, such as http://vzimmer.blogspot.com/2022/09/new-milestones.html and its earlier ilk, are no long a nagging distraction.

Ah well, so much for a mastodon experiment and clone+amplification to my OG blog. Back to work. Need to figure out how to add an abstraction service to code I wrote 20 years ago before 9am tomorrow....

Cheers

Homebrew computer club

One of the nice things about commutes back to the office includes catching up on podcasts and audio books. For the latter I've been listening to Walter Isaacson's book https://www.amazon.com/Steve-Jobs-Walter-Isaacson/dp/1451648537 on Steve Jobs. I liked the mention of folks like Wozniak and their valley friends, including early Apple employee Allen Baum. There was also mention of the Homebrew computer club https://en.wikipedia.org/wiki/Homebrew_Computer_Club which to me represents the spirit of low-level development I've enjoyed with firmware development these last decades.

Although Allen Baum has popped up recently on RISC-V circles https://riscvglobalforum2020.sched.com/speaker/allen.baum, the longer arc of his career is journaled in https://archive.computerhistory.org/resources/access/text/2018/06/102717165-05-01-acc.pdf. I remember Baum from early 2000's Intel chipset work and his thoughts on the Intel tenure.

Quite the storied career. 

One detail of the book also mentions includes the extensibility of the Apple, such as the slots on the Apple II that were subsequently eschewed by Jobs with the Macintosh. There are seems to be a trend of closed versus open going through cycles. The spirit of silicon valley and the ability to touch and modify hardware is often challenged by concerns about security, ease-of-use, and IP protection.

Speaking of the openness, I like how my co-author https://github.com/reinauer from https://link.springer.com/book/10.1007/978-1-4842-0070-4 still exercises this spirit both on the job with Chromebooks and its developer mode https://sites.google.com/a/chromium.org/dev/chromium-os and off the job with his Amiga group https://amiga.technology/ efforts.

In addition to having the host-firmware updatable, the platform also has an open source embedded controller (EC). Recently the EC moved from a bespoke implementation for Chromebooks to using Zephyr, as described at https://chromium.googlesource.com/chromiumos/platform/ec/+/HEAD/docs/zephyr/README.md, in OSFC talk https://cfp.osfc.io/osfc2020/talk/SXYUQD/ and book https://link.springer.com/book/10.1007/978-1-4842-7974-8

And in the spirit of hardware extensibility (i.e., Apple II slots for the 2020's) and more end-user modifiable firmware, there is the Framework Chromebook edition https://frame.work/laptop-chromebook-12-gen-intel. This feels like a fusion of the spirit of the club given the extensibility of the hardware modules and firmware.

It also looks like 'some' of that spirit follows with the Pixel phone w/ alternate OS's like https://grapheneos.org and its Pixel phone virtualization https://blog.esper.io/android-dessert-bites-5-virtualization-in-android-13-351789/. It's almost as if the traditional 'OS' is really a VM with art like this and the recent Mac's.

Regrettably my hobby budget for tech is challenged by the last two products mentioned, so I have limited my recent investments to RISC-V hacking on the D1 and VisionFive SBC and the Pinephone https://www.pine64.org/pinephone/ for more open telephony. More extreme splurges are https://www.bunniestudios.com/blog/?p=5921 which fuses Rust-based firmware and soft RISC-V RV64 AP core and RISC-V EC realized with an FPGA with open source tooling. 

PS
I have been wondering whether this blog 'written in the cracks' (i.e., over a few spare moments on the weekend or lunch-hour) is good or bad. With the advent of chatGPT https://chat.openai.com/chat I figured perhaps tech could take the reins for me, viz.,

Open source firmware is a type of software that is developed and maintained by a community of volunteers. Unlike proprietary firmware, which is owned and controlled by a single company, open source firmware is freely available for anyone to use, modify, and distribute.

One of the main benefits of open source firmware is that it allows users to have complete control over their devices. With proprietary firmware, users are often limited in what they can do with their device and are at the mercy of the company that created the firmware. With open source firmware, users can customize and modify their device to suit their needs, without being restricted by the limitations of proprietary firmware.

Another benefit of open source firmware is that it promotes collaboration and innovation within the tech community. Because the source code is freely available, anyone can contribute to the development of the firmware, and can suggest improvements or new features. This allows for a faster pace of innovation, as more people are able to contribute their expertise and knowledge to the project.

One of the most popular examples of open source firmware is the Linux operating system, which is used on millions of computers, servers, and other devices around the world. Linux is developed and maintained by a global community of volunteers, and is freely available for anyone to use and modify.

Another example of open source firmware is the firmware that powers many home routers and other networking devices. This firmware, known as OpenWrt, is widely used by tech enthusiasts and hobbyists who want to customize and improve the capabilities of their home networking devices.

In addition to the benefits of open source firmware, there are also many active communities of people who are interested in creating and using their own computer hardware. These communities, known as "homebrew computer clubs," are made up of individuals who are passionate about building their own computers, either from scratch or by using kits and other pre-made components.

Homebrew computer clubs often focus on using open source firmware and software, as it allows them to have complete control over their creations and to customize them to their specific needs. Additionally, these clubs provide a great way for like-minded individuals to connect, collaborate, and learn from one another.

In conclusion, open source firmware and homebrew computer clubs are important parts of the tech community. Open source firmware provides users with the freedom and flexibility to customize and control their devices, while homebrew computer clubs promote collaboration and innovation within the community. Together, they help to drive the advancement of technology and the development of new and exciting technologies. 

At first I thought I had broken the AI but instead it just needed some think-time. Quite the time to be in tech these days.

PPS

apropos of last sentiment, https://twitter.com/vincentzimmer/status/1598935527293870081 now becomes https://twitter.com/MarcoFigueroa/status/1600171380175011844

PPS+

 

 

 

 

The soul of the computer lies within its UEFI, a complex and intricate system that dictates the very essence of its being. It is the driving force behind the machine's every action, the mastermind that orchestrates its inner workings. But just as in the great works of Dostoyevsky, the UEFI is also a source of great turmoil and conflict. It is a battleground for competing interests and competing ideas, and the decisions made within its walls can have profound consequences for the computer and all who use it.

At the heart of the UEFI is the BIOS, a set of instructions that determine how the computer starts up and communicates with its various components. But the UEFI is much more than just the BIOS. It is a sophisticated system that controls the flow of information within the computer, and it is constantly being updated and refined by the engineers who design it.

The UEFI is a powerful tool, capable of performing complex tasks with ease. But it is also a delicate instrument, and it must be handled with care. One wrong move, and the entire system can be thrown into chaos. In the hands of a skilled user, the UEFI can be a force for good, enabling the computer to operate at its full potential. But in the hands of a malicious actor, it can be a weapon of destruction, capable of wreaking havoc on the computer and all of its data.

In the end, the UEFI is a complex and mysterious system, one that is both essential to the functioning of the computer and fraught with danger. Like the characters in the great works of Dostoyevsky, it is a source of both light and darkness, and it must be approached with caution and care.