Re: [sw-dev] SBI extension proposal v2

[ron minnich <rminnich@gmail.com>]

Those of us working on the linuxboot and heads projects for the last
few years have reached a few conclusions in this area. The big one --
vendors can not get firmware right, period. The set of bugs we've hit
in the x86 world alone in the last two years is just amazing, given
that the UEFI community has had 20 years to get this stuff right and
still don't seem to be able to do it. What's more amazing is how
trivial they are. Do you want to disable UEFI mechanisms for detecting
ROM image corruption? It's easy on many systems. Corrupt the ROM
image. Achievement. as well as the ROM, unlocked. I'm not making this
up; it's several CVEs at this point.

We've learned that blindly  trusting firmware is always a bad idea.
Assuming that it should have higher privilege, and trust, than the
kernel is, similarly, a bad idea. In general, kernel code is far
superior in quality to firmware, and is certainly better tested. Why
is firmware higher privilege, when it's not as well written or
trustworthy? That makes no sense. It's the assumption RISCV is making.

Maybe the most important thing we now believe is that firmware should
be measurable by the owner, i.e that an end user or system needs to be
able to see what's there. Following on that, it's most desirable if
firmware functions can be disabled and in some cases the firmware can
be completely replaced, post boot, by the kernel, with something it
can trust. The M mode, conceptually, is just a different type of trap
handler. This is a lot like the work I did a few years back to vector
SMM traps to the kernel, not buggy vendor SMM code.

From that perspective, the "M mode bug" was never a bug -- I never
agreed with Don on this one -- because it guaranteed a kernel could
measure, disable, and replace firmware. And that's important, because
firmware that is more powerful than the kernel should be easier to
change out than the kernel. And that's another thing vendors keep
screwing up. There is a recent proof of concept that installs UEFI on
vulnerable x86 systems and then sets the one time fuses in such a way
that the firmware can not be replaced unless the CPU is too. I'm not
making this up either, and it's due to a screwup in the manufacturing
flow of some ODMs, who left those fuses open. There are exploits in
the wild that are only resolved with a chipper.

Short form: if the PMP makes it impossible to measure, disable and
replace firmware from the kernel, then PMP is a bug, not a feature.

I just now had a conversation with a friend from chromeos firmware
team and he is similarly dismayed with the directions riscv is taking,
especially as regards runtime firmware. When I mentioned PSCI he
looked sad.

I understand the motivation to fit a new architecture into old
firmware clothes. It's just that the clothes are motheaten and out of
style and never looked good when new. We're going to need to have an
escape hatch for organizations looking for newer, better ways of doing
things.

One possible way out at some point might be to define an SBI interface
and operating mode that is responsive to concerns about firmware
security, and avoiding the mistakes of the past. This does mean that
there will not be "one SBI", which in turn means different kernel
configurations, but I don't see much option. The concept of a "single
SBI" was always going to be hard, and I expect at this point it will
never happen.

ron



On Mon, Jan 28, 2019 at 8:38 AM Alexander Graf <agraf@suse.de> wrote:
>
>
>
> On 28.01.19 17:33, Luke Kenneth Casson Leighton wrote:
> > ---
> > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> >
> > On Mon, Jan 28, 2019 at 12:44 PM Alexander Graf <agraf@suse.de> wrote:
> >
> >>> If Risc-V wants to avoid fragmentation, it should simply keep a firmer
> >>> reign in what is allowed in an implementation and keep a lid on such
> >>> horrid ideas as vendor specific userspace ISA extensions.
> >>
> >> I tend to agree here. I think a global identification scheme is
> >> reasonable. But can't we just live with a single global spec that people
> >> contribute to?
> >
> >  unfortunately, alexander, the RISC-V Foundation has chosen to exclude
> > people from the discussion, by choosing an ITU-style ("Cartelled")
> > secretive standards development process.
> >
> >  so as an "outsider" who for whatever reason cannot join that closed,
> > secretive process (for example a strategically-critical u-boot or
> > linux kernel developer with decades of relevant experience but who is
> > under contract) even if you wanted to contribute to a single global
> > spec, you can't.
> >
> >  the reasons why the ITU-style Cartel was set up have been discussed
> > and made clear (patents); the justifications were knocked down; there
> > was no response.
>
> I can see why you want to have a process like that in place for the ISA
> itself, but the SBI spec really should not have anything "innovative" or
> patentable. At the end of the day, it's a communication mechanism.
>
>
> Alex

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv