USENIX ATC '21/OSDI '21 Joint Keynote Address-It's Time for Operating Systems to Rediscover Hardware

Very interesting. This reminds me a ton of L4, with its message passing style. I'm curious if it was inspired by L4. It's a great talk, and my only disappointment was that I was hoping to hear about what comes after. After watching the OS talk that Cantrill references [0], I really want to know the answer to "what does an OS that runs across a bunch of heterogeneous chips look like?" Having Hubris be just a single-node OS was a bit of a let down, so I will be staying tuned for the sequels. [0] [this video] EDIT: Went to go read the docs and: "The operating system that originally made this point was L4, and Hubris’s IPC mechanism is directly inspired by L4’s"

Plenty of good links here already. I'll just add that booting is enormously complex, and starts well before any of the dozen comments so far. I skimmed many of them (not all) and they all tell pretty much the same story whether on real hardware or virtual. But modern real hardware first boots a Management Engine (or BMC, or T2, or similar), which prepares things and starts subsystems like hardware controllers, before releasing the CPU where the "OS" finally boots, blissfully unaware that it is running on an abstraction. Watch [this video] from about 10:00 to about 20:00 for a decent super high level overview. These two are also good for a deeper understanding. [link] [link] They both cover UEFI, even though the focus is on T2. I know that's well beyond what you were asking for, but the boot process goes well beyond GRUB.

I'd say the computer architecture can vary _greatly_ and there are a bunch of cores in modern SOC's that kind of break the assumption of how a computer works. I recently listened to this: [this video] Cache coherence, accelerators, various takes on pipelining, ISA extensions. There are many many things that change all the time. Not even touching the SW glue stuff that changes. I don't know the history of react and what is going on in modern browsers, but I suspect there are OS constraints, evolving web standards, extra capabilities, evolving browsers that shape and force the framework to adapt. I am doubtful people change it just for the sake of it.

I feel like this generally applies to all software developers. Software and its systems have largely evolved through accretion and that creates a strong network effect and eventually, a taller application stack. We're continually making everything more complicated because it's just easier to use other people work, especially when the barrier to entry for that work is low, i.e: Web/JS. As a slight segue, I recently came across Timothy Roscoe's Usenix talk[1] on OS development on HN and I'm starting to think that a complete rebuild of modern computing might occur when the limits of the old OS architectures become too burdensome, at which point there could be an opportunity to "fix" the application stack and try something simpler. I sincerely hope the OS's of the future do not look like Linux or even attempt POSIX compliance. [1] [this video]

> Maybe we could do all the "smart" stuff in the OS and application code, and just attach commodity dumb flash chips to our computer. Yeah, this is how things are supposed to be done and the fact it's not happening is a huge problem. Hardware makers isolate our operating systems in the exact same way operating systems isolate our processes. The operating system is not really in charge of anything, the hardware just gives it an illusory sanboxed machine to play around in, a machine that doesn't even reflect what hardware truly looks like. The real computers are all hidden and programmed by proprietery firmware. [this video]

I'm not a RISC-V expert, primarily relying on open-source firmware community knowledge and the opinion of such figures as Ron Minnich, but AFAIK, most firmware for production RISC-V deployments is closed-source, so we can't say if vendors use OpenSBI implementation or some modified version for their malicious purposes. If I need to be corrected, please point me to products that state how they transparently use SBI. There is evidence of transparent use of SMM in coreboot. SBI is not the only RISC-V TEE. There are also other concepts, like MultiZone [1] and PMP-based Keystone [2], advertised as trusted execution environments The openness of specification only matters a little here - UEFI specification about management mode is also open. But IBVs screwed us many times [3] by implementing low-quality SMIs that could elevate privileges, and the spec does not guarantee that implementers follow it. Lack of tooling makes compliance difficult - it slowly changes with various startups seeing that as an opportunity (e.g., Binarly, Eclypsium?). My point is that SMM as TEE is not a unique x86 feature, and other significant architectures have similar mechanisms. OS has a means of figuring out that it was in SMI, so it is not entirely hidden but still has superpowers. In the CNC world SMI latency is measured from OS [4]. Trusted execution environments are hammers and can be used for a good purpose in a transparent way and for malicious purposes. Further typically depends on the trustworthin

Linux on Android doesn't multiplex or protect software principals from each other. It did for a brief time, but that led to massive vulnerablilities. Because Linux view of hardware (nice symmetric system with homogeneous cores running single OS with shared memory address space) was different from what was the actual state. For that reason hardware was abstracted away from Linux and it's only used to run Linux programs. It's not containerized. It's isolated to an enclave where damage it can do is minimal. Android OS is essentially a ball of propietary firmware mud. With Linux programs and Dalvik JVM. For more: [this video]