[sw-dev] SBI extension proposal v2

[olof@lixom.net (Olof Johansson)]

On Sat, Nov 10, 2018 at 8:46 AM ron minnich <rminnich@gmail.com> wrote:
>
> At Google and other places, we've been struggling now for years with
> overly complex firmware that is implemented incorrectly, enabling
> exploits and other bad things. The list of things vendors get wrong in
> firmware, both enabling exploits and enabling others to enable
> exploits, is long and it continues to this day. There is an
> unbelievable amount of money out there all involving firmware
> exploits, very little of it involving nice people.
>
> I'm currently working on deleting all use of the x86 version of M
> mode, i.e. SMM. There are many proposals out there for deleting SMM
> from the architecture. I've also shown at a talk in 2017 how we could
> redirect SMM interrupts back into the kernel. We're also removing all
> use of callbacks into UEFI on x86. We're almost there.
>
> Which is why I'm a bit unhappy to see this (to me) cancerous growth in
> proposals for M- mode code. PPP in firmware? Really? multiple serial
> devices? really? We've been here before, in the 1970s, with something
> called the BIOS. If you're not familiar with it, go take a look, or
> you can take my word for it that these proposals implement that idea.
> We spent over 20 years freeing ourselves from it on x86. Why go back
> to a 50 year old model on a CPU designed to be in use for 50 years?
>
> My early understanding of M mode was that it was an Alpha PALCode like
> thing, enabling access to resources that were behind a privilege wall.
> I did not like it that much, but I was OK: it was very limited in
> function, and the kernel could replace it, or at least measure it. I
> also accept that every cpu vendor uses m mode like things (e.g. ARM
> TF) for reasonable purposes and also (let's be honest here)  for
> dealing with chipset mistakes. But that does not mean you need to
> recreate BIOS.
>
> The SBI should be hard to add to, deliberately. It should be used only
> when there are no possible alternatives. It needs to be open source
> and held in common. It should be possible for a kernel to replace or
> at least measure it. And, further, there needs to be some work done on
> why you add to it, and why you don't, with bias against adding to it.
> This proposal works against those ideals, as it explicitly enables
> vendor-specific forks of the SBI. Sure, this can happen, but why make
> it so easy?

There's a tension between letting people do the messy things that real
hardware sometimes needs without polluting higher layers in the
software stack, and letting them do too much of things that _should_
be handled in the upper layers. I have yet to find a solution that
doesn't need tweaking over time, the pendulum tends to swing back and
forth into "too far" in both directions sometimes.

The case of console is in this case pretty simple: It's intended for
early boot for very simplistic environments (before the rest of the
kernel is up, etc). Keeping the SBI console around beyond early boot,
and somehow trying to optimize for it for those use cases is a
misdirected effort; that's what native drivers are for.

Having to do fine-grained arbitration of device ownership between
firmware and kernel at runtime is usually error prone and awkward and
best to avoid.


> p.s. For interleaving debug and console output firmware, use the
> oldest trick in the book: ASCII is 7 bits. Since console out is 8
> bits, reserve 128 values for console out, and 128 for debug stream,
> and if the debug stream needs 8 bit for some words, you know what to
> do. It's very easy and doesn't require that we add multiple UART
> support to SBI.

Sure, it helps for 2 channels. And then beyond that you need a more
complex protocol. Either way, it's not a problem we need to solve here
and now.


-Olof