Re: [sw-dev] SBI extension proposal v2

[ron minnich <rminnich@gmail.com>]

This conversation is in danger of devolving into a lot of firmware
inside stories, so I'll keep it short, because I doubt most people
even care, and I don't want to bore anybody :-)

Any of uefi/edk2/whatever is so full of defects that, at least in my
world, we would not take the road through edkii unless we had no other
choice.

But, given that people want things like uefi/edk2/abc for their own
needs, again, I suspect the "SBI standard" is not going to be one
implementation and it may not be a standard. The opportunity to make
that happen passed 4 years ago.

thanks

ron

On Tue, Jan 29, 2019 at 12:53 AM Alexander Graf <agraf@suse.de> wrote:
>
>
>
> On 28.01.19 23:23, ron minnich wrote:
> > On Mon, Jan 28, 2019 at 12:37 PM Alexander Graf <agraf@suse.de> wrote:
> >
> >> I'm fairly sure you know me about as well as I do know you ;).
> >
> > Apologies Alexandar, you're right. You're one of the good guys in this game.
> >
> >> The ususal answer I would have to that is to empower system owners to
> >> build their own firmware (which allows them to replace bits), but I can
> >> see how that doesn't always work for every case. I don't have a good
> >> answer yet, but I'm sure there will be discussions at FOSDEM about it.
> >
> > I wish that model worked. I've worked so hard to make it so for 20
> > years. But I know from long sad experience it does not.
> >
> > I wish vendors would not keep installing exploits in the firmware. But
> > I know from long
> > sad experience they will keep doing that.
>
> Well, any software has bugs. In a lot of cases the problems in firmware
> are not deliberate - they just happen because everyone does mistakes.
>
> That's why updatability *on every layer* is so important.
>
> > I wish it were as easy to install firmware as it is to install a
> > kernel. That's not
> > ever going to happen.
>
> In my book, with fwupd we're getting quite close. You can just deliver
> firmware updates via normal Linux distro update mechanisms. So if you
> want to maintain your own fork of firmware with your own keys etc, you can.
>
> > The one thing I know is that it is pretty easy to load a kernel of
> > choice, and for that
> > reason I want to allow the kernel to load the desired runtime firmware.
> > I don't like hardware that does not allow that.
>
> I think there are 2 messages here that I agree with:
>
>   1) Runtime firmware should never be interrupt driven
>
> That way we ensure that the OS is the caller - always. If runtime
> firmware needs an event mechanism, it should register it through the OS.
>
> I really like that requirement. It is critical for any real time system
> anyway. And at the same time ensures that you don't have random code
> doing things behind your back.
>
>   2) There must be a plan B when FW runtime is wrong
>
> So if I read things in your email correctly, you're basically advocating
> a typical ACPI model, where the kernel receives bytecode it executes
> itself and thus can measure and replace it.
>
> There are multiple problems with that:
>
>   a) You are running at a different privilege level, so you may not have
> access to the registers
>
>   b) ACPI interpreters are *huge*. One big complaint I've seen in the
> ARM world is when you get down to bare metal / partitioning hypervisors.
> You will suddenly need a giant ACPI interpreter in your safety critical
> domain, just to toggle clocks. And then another full framework for your
> guest interface.
>
> I think we're early enough in RISC-V to be able to mandate a few FW
> constraints though. In my book, all that needs is that a FW supplier
> needs to provide one out of 3 mechanisms:
>
>   a) (runtime) open source, user replaceable FW and/or
>   b) direct exposure to functionality done via runtime services using
> alternate methods (trivial SBI functions for direct register access for
> example) plus documentation and/or
>   c) runtime code is directly interpreted by OS
>
>
>
> If someone writes up a spec similar to SBBR that just mandates one out
> of those 3 mechanisms and mandates that M mode may not receive
> interrupts, I guess you would always get a system that you can unbrick /
> eventually trust.
>
> Now the really interesting question is what TEE looks like in such an
> environment. How would a TEE application interact with hardware when it
> can not get interrupts?
>
> Oh well, lots of food for thought for discussions at FOSDEM.
>
> > IOW, the barrier to entry for firmware, we've found, is very high for
> > most people. The barrier
> > to kernel is far lower. Ergo, I'd like to have it at least *be
> > possible* for a kernel to measure, disable, or replace
> > the runtime firmware it will use. Measurement is a minimum and
> > non-negotiable requirement. If a RISCV system
> > ever sets up a PMP such that firmware can not be measured, that system
> > should be assumed to be untrustable.
> >
> > This was easy before PMP. I am worried that it becomes impossible after it.
>
> It depends. If you build and sign FW yourself, I see little reason not
> to have lock-down mechanisms. At that point, you're trusting your own
> code after all and you have your own update mechanism in place too.
>
> >> Sweet. What if you want to support 10000 different types of servers? You
> >> write one (or many) driver(s) each?
> >
> > that code is going to be written in any case. Do we write for UEFI
> > (painful!) or Linux (painful--)?
>
> That's not really the question. It's the code vs binary model.
>
> Look back at the old ARM days in Linux where every *board* had its own
> .c file and there were a lot of hard coded #ifdefs scattered throughout
> the code base because people knew that the OS would only ever get built
> for one particular target.
>
> Well, fortunately that has changed. People are now building a single
> Linux binary for 10000 different targets. It was quite a lot of effort
> to get to that point, but it allows for much better scaling of manpower.
>
> I see a similar trend happening in firmware land. Take a look at André
> Przywara's presentation at FOSDEM. For usability reasons there is a
> certain desire to cover more than just a single target platform with a
> single binary.
>
> So while I agree that writing edk2 code is painful and writing Linux
> code is much less so, that's not the question.
>
> (Also, please don't call edk2 UEFI. There is so much in the UEFI spec
> and most people really don't care about most of the driver bits. You can
> use U-Boot just fine as UEFI provider and in fact you could even use
> Linux as UEFI provider with an appropriate user space that implements
> the services)
>
> >> Does that same kernel run on all the 10000 different types of servers I
> >> mentioned above?
> >
> > It runs on a huge range of servers, at this point every OCP server
> > we've tested, several proprietary servers from an unnamed company, the
> > Intel NUC, and chromebooks I've tried, as well as PC Engines boards.
>
> Is that the same source base or the exact same target binary? If it's
> the same target binary, the only way I can see this work is if you have
> runtime services in the form of a DSDT.
>
> > But, that said, the system needs to run part of coreboot or the
> > SEC/PEI part of UEFI; in the SEC/PEI case, that's a blob we will never
> > be allowed to replace, so it has to be assumed anyway :-(
>
> To be completely frank here, I don't see why someone as big as your
> employer can't replace whatever they like. Others seem to be able to?
>
> > And it relies on the early NON-runtime startup that the rom-based
> > firmware does. But our goal is to completely disable all UEFI runtime
> > services and SMM. runtime firmware services have proven to be too
> > large
> > a security problem to be allowed on x86.
>
> I think you'll be happy to hear that as part of the EBBR discussions we
> ended up with a UEFI ECR that will make it perfectly legal not to UEFI
> have runtime services:
>
>   https://pjones.fedorapeople.org/rt-unsupported-ecr-0.txt
>
> Though I perfectly consider UEFI RTS not the worst part of this puzzle,
> since they run in the same privilege level and they are only ever called
> by the OS.
>
> >> At least here we do agree (mostly) :).
> >
> > Well, TBH, I think your vision will probably be the one that will be
> > used, whether I like it or not :-)
>
> I'm not sure I have a conclusive vision yet :).
>
> > Looking forward to seeing you at FOSDEM!
>
> Same here!
>
>
> Alex

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