[TUHS] Re: kernel boots kernel in 1977

On Wed, Sep 18, 2024 at 8:11 PM George Michaelson <ggm(a)algebras.org> wrote: I'm not sure that I completely buy that. The act of replacing the kernel is, of course, a privileged operation. In some abstract sense, this is little different than triggering a reboot via a system call: in both cases, the system as we know it goes away and is replaced by something else. Similarly, even in the cold-boot case, very early on in the machine's lifecycle the kernel image is found and loaded into memory for execution. What's the difference if it's a bootloader that does that, or the kernel itself? Indeed, from the perspective of the newly booted kernel, the prior execution of the machine can be regarded as a single, perhaps exceptionally long, boot loading phase. How so? Virtualization doesn't all of a sudden mean that (guest) userspace can scribble all over (guest) kernel memory, let alone the host. The deluge of recent speculation bugs notwithstanding, the separation between user and executive is still very much intrinsic to the proper operation of modern computers. Yeah, we have seams between the host OS and the actual computer mediated by firmware, but given the state of that firmware, the present situation is borderline untenable. That's not to say that interfaces are bad, or that they're not useful, but the interfaces that we presently have are not good. E.g., https://www.usenix.org/conference/osdi21/presentation/fri-keynote At work, we've taken this to heart; the first x86 instruction when our CPUs come out of reset is actually sitting in code we wrote, and we boot directly into the operating system. https://vimeo.com/756050840, https://github.com/oxidecomputer/phbl, and https://rfd.shared.oxide.computer/rfd/0284 are interesting references. - Dan C.