Having worked with devicetrees and hated it, I don&#x27;t like this idea. I don&#x27;t like the modern world of ARM and embedded where you have hardcoded firmware images for every single device. I like the x86 model, where you have a one size fits all boot disk which just loads different drivers. You don&#x27;t <i>port</i> your OS to a new computer, you just write drivers for the new hardware parts. And your hardware describes itself to the OS.<p>Granted, UEFI is grotesquely complicated. Probably you could replace most of it with a EEPROM that has a mapping of device ID to memory address, and some instructions how to speak to the embedded controller (basically, ACPI).<p>Unfortunately, UEFI&#x2F;ACPI or simliar seems to be going nowhere in the ARM world, so it doesn&#x27;t seem installing Windows&#x2F;Linux is going to be as easy on ARM as on x86 anytime soon.

For what it&#x27;s worth, a holistic system only allows the user to bring their own code only above some layer. For Unix systems of ye olden days, that would be your C source code that you compile. For Chrome OS, that&#x27;s gonna be websites and extensions. For Oxide, it seems like that is going to be VM images.<p>But it&#x27;s important to note that these days, there will always be somebody who wants to bring their code in at a lower level. And the immediate reaction of all vendors is &quot;But why would you want to do that?&quot;. Why would you want to bring your own Unix flavor to our hardware? Why would you want to run Linux executables on Chrome OS? Why would you want to run a different hypervisor on Oxide racks?<p>Those people will exist. And layers like BIOS and UEFI allow system vendors to say &quot;Eh, sure, we don&#x27;t think that what you&#x27;re doing is wise, but whatever, here&#x27;s a standard way we&#x27;ll allow you to use&quot;. Holistic systems don&#x27;t have these standards. They are only usable as their creators intended. And not everyone will agree with their creators intentions. But the work required to refit them to fit another purpose, which the hardware is very fit to do, but the software fights against, is usually too high, and you&#x27;ll be better off using something that is worse, but left you an avenue to customize it for your purpose easily.<p>My main takeaway from this talk, is that we need some standards for phase-based booting, as there is some very cool improvements that could be done with it. But I see no need for holistic systems as described in that talk, I just see a need for better, more transparent systems. And a system doesn&#x27;t have to be holistic to be transparent, or good.

Literary tangent: The title seems to be an allusion to Shakespeare. &quot;I come to bury Caesar, not to praise him.&quot; Except, the entire purpose of Antony&#x27;s funeral oration is to praise Caesar. His intent was to defend Caesar&#x27;s legacy and shift public opinion against Caesar&#x27;s assassins.<p>Watch here: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=0bi1PvXCbr8" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=0bi1PvXCbr8</a>

Those summary paragraphs feel like they were written in a deliberately obfuscated style; not exactly a good first impression.<p><i>Rather than have one operating system that boots another that boots another, we have returned the operating system to its roots as the software that abstracts the hardware: we execute a single, holistic system from first instruction to running user-level application code.</i><p>...also known as single-purpose firmware for an embedded system. I&#x27;m in agreement with the other comment here that this is not a good idea. Standardised interfaces like what the BIOS provides lets the OS not be tied to subtle differences in hardware.

Link to the other talk he references in this talk<p><a href="https:&#x2F;&#x2F;youtu.be&#x2F;36myc8wQhLo" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;36myc8wQhLo</a><p>And yes, this is (as ever) a call to arms on fixing a massive security problem we all have.

Sounds kind of horrible. PCs have a level of compatibility that is basically unheard of anywhere in tech.<p>Through whatever historical accident, the IBM PC is... pretty amazing. Things are standardized. Stuff just works. We can choose our OS. We don&#x27;t have a ton of fragmentation. Distros aren&#x27;t niche community things developed for specific hardware.<p>If you can make a single OS image that runs on any device of any manufacturer, the way that one Linux distro runs on almost any PC with any combination of parts, great.<p>But removing layers of abstraction seems like it could easily lead to incompatibility. I&#x27;d much rather have proprietary blobs everywhere than incompatibility.

One of the things that bugged me about this presentation (and, to a similar extent, with Oxide as a whole) is the assertion that the only way we can have safe and trustworthy systems is if each and every component is trustworthy. This is, obviously, a true statement—if we manage to wrangle every component of a system and put it under the control of safe and secure software, we have a really secure system. I don&#x27;t, however, believe that this is the only way (or, in fact, even the most realistic). Rather, I think we will (for better or for worse) go straight in the opposite direction and end up treating the entire system as an autonomous sea of untrustworthy cores. SGX, for all of its flaws, I think got the nearest to this because it bootstrapped trusted compute in an environment where it couldn&#x27;t even trust DRAM to not change underneath it. Assuming that every other system agent is hostile lets you use random proprietary garbage without needing to fully control every single core and microcontroller on the platform. It is truly a pain in the ass to program this way but it is, fundamentally, something we can do.<p>This, of course, isn&#x27;t to say I wouldn&#x27;t <i>love</i> to have a system where we can run our own open implementation on every bit of the platform, but rather that I don&#x27;t believe <i>we ever will</i>. Oxide has made it pretty far, no doubt, and it&#x27;s an incredible feat but as Bryan mentioned, their staff is literally reverse engineering hardware and finding completely undocumented <i>cores</i> in the things they&#x27;re putting in charge of their platform. Hell, most companies I&#x27;ve been at hardly even know the full capabilities of their shipped silicon (did we slap a chicken bit on that? did we fuse off that performance analysis module for production runs? did we fully remove that one feature that didn&#x27;t verify before our tapeout deadline? did we backport that one bug fix to all relevant generations? and on and on) and so its many times not even a case of companies being over protective but rather people not being able to even reason about these complex systems.<p>Both Bryan and Roscoe raise the question of who is at the helm of the ship and each find a different monster steering. The truth is that nobody is actually in control on these SoCs because nobody has the last word or some distinct power that cannot be compromised with some other random power. SoCs are not hierarchical; they&#x27;re ridiculously complex systems of federated power, and we really need to treat them as such.

I expected to like this talk much more than I actually did.<p>Basically what they did is do a reverse engineering and replay attack on a boot sequence that is already so convoluted that the company that built it didn&#x27;t think that would be possible.<p>Good for them but all this work will be wasted if the next hardware version comes around and needs a different boot sequence. They basically nailed themselves to a specific version of a specific hardware platform that AMD is replacing as we speak (the next iterations are called Genoa and Bergamo and are expected this and next year respectively.<p>I was hoping this would feel like a breath of freedom, but it really feels like a few rebellious nerds trying to prove something, but not actually proving it. The talk feels to me like they actually proved the opposite. We are already too far down the path. You will never be able to, say, boot Windows on this hardware.<p>Can you boot a stock Linux on this hardware, or will you be dependent on patches from them?<p>As a Linux user I love the idea. As a PC user I never asked for UEFI or the Management Engine. I should be all for this. But somehow I&#x27;m not.

I was somewhat disappointed that there was only one &quot;need&quot; for holistic systems presented: the fact that correctable DIMM errors were getting eaten by underlying firmware. While I don&#x27;t necessarily disagree with the speaker&#x27;s premise, I&#x27;d have at least liked to see more than one example of why this is important - I can&#x27;t say that I&#x27;ve walked away with a good idea of why that is. The fact that correctable versus uncorrectable DIMM errors were differentiable tells me that there already _is_ an interface that allows propagating both up to the OS, and that the firmware of the system just wasn&#x27;t fully implementing it.

Really good talk by Bryan Cantrill (co-founder of Oxide Computer COmpany) on the problems with closed source firmware and the need to move away from BIOS and EFI and how they booted their own x86 AMD custom board system all made with open source firmware and without using AMD&#x27;s firmware.