[TUHS] kernel boots kernel in 1977

Dan Cross crossd at gmail.com
Thu Sep 19 10:23:16 AEST 2024


On Wed, Sep 18, 2024 at 8:11 PM George Michaelson <ggm at algebras.org> wrote:
> Not to be "that guy" some of this can be read as "the whole
> ring/protection model is a myth" because doing a boot into a new
> executive demands "writing" state into parts of the system which
> people believe by a phenomenal act of faith are "protected" against
> that.

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.

> Virtualisation makes much of this latent "protection rings are a bit
> of a myth" concrete.

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.

> Maybe I misunderstand some of this. I can believe that UNIX-like
> things try to work irrespective of what chip designers do underneath
> to construct things like TPM, and talk to it in the limited ways
> necessary.

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.


More information about the TUHS mailing list