Re: [sw-dev] SBI extension proposal v2

[Paul Walmsley <paul.walmsley@sifive.com>]

On Tue, 5 Feb 2019, ron minnich wrote:

> While I respect the tremendous amount of work the OpenSBI authors have
> done, I agree with Benjamin and Luis.

There are a few key points that seem to be getting lost in this 
discussion:

1. OpenSBI is a sample implementation of the SBI interface, and is not the 
SBI standard itself

2. It is optional to implement the SBI, and it's likely that only certain 
types of platforms will do so

3. OpenSBI, from my point of view, consists of two distinct components:
	a. libraries that can be used as reference implementations by 
	   other early boot firmware; and
	b. sample early boot firmware that replaces riscv-pk

As far as I can tell, as long as the platform specification standards are 
written correctly, there's no conflict between SBI-based platforms and 
SBI-less platforms.

> There is a further issue that occurred to me doing their excellent
> FOSDEM talk, which is that nowhere in this has any kind of verified
> boot scenario been discussed, and if you don't get that thinking in
> from the start it is very hard to wedge it in later.

Verified boot seems almost completely orthogonal to OpenSBI's library 
implementation (3a, above).  U-boot, or Grub, or Coreboot, could reuse the 
OpenSBI libraries, but not the OpenSBI early boot firmware.  Then those 
other bootloaders can implement whatever verified/trusted/secure boot 
approach that they wish.

As 3b mentions above, the OpenSBI repository also contains sample early 
boot firmware.  That part of OpenSBI would clearly need to be modified to 
support some sort of verified boot.  However, no one to my knowledge is 
proposing to make the OpenSBI sample early boot firmware a RISC-V 
standard.  That part of OpenSBL is just a sample first-stage bootloader 
implementation - the same way that U-boot SPL or Coreboot romstage are 
sample first-stage bootloader implementations.

...

I personally am excited to finally be able to use U-boot's rich 
commandline interface and device drivers without needing to have riscv-pk 
(aka BBL) involved.  Those who are not doing active RISC-V Linux 
development may not be aware that the use of riscv-pk made it very 
difficult to use upstream-focused Linux DT data.  Even though I might have 
slightly different preferences for the current boot flow, their work 
removes a major obstacle from RISC-V Linux upstream development, and is a 
big step forward.


- Paul

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