SBI extension proposal v2

[Atish Patra]

Hi,
I have updated the proposal based on feedback received on previous
version. This version has a better scalable SBI Function ID
numbering scheme. I have adopted markdown formatting for github docs.

If you prefer a github interface, it's available here as well.

https://github.com/riscv/riscv-sbi-doc/pull/12

Looking forward to your feedback.

Regards,
Atish
------------------------------------------------------------------------

## Introduction:
This is a proposal to make SBI a flexible and extensible interface.
It is based on the foundation policy of RISC-V i.e. modularity and
openness. The proposal tries to introduces very few new mandatory SBI
Functions, that are absolutely required to maintain backward
compatibility. Everything else is optional so that it remains an open
standard yet robust.

The current RISC-V SBI only defines a few mandatory functions such as
inter-processor interrupts (IPI) interface, reprogramming timer, serial
console, and memory barrier instructions. The existing SBI documentation
can be found here [1]. Many important functionalities such as power
management/cpu-hotplug are not yet defined due to difficulties in
accommodating modifications without breaking the backward compatibility
with the current interface.

The proposed design is inspired by Power State Coordination Interface
(PSCI) from ARM world. However, it adds only two new mandatory SBI calls
providing version information and supported Functions, unlike PSCI where
a significant number of functions are mandatory. The version of the
existing SBI will be defined as a minimum version(0.1) which will always
be backward compatible. Similarly, any Linux kernel with a newer feature
will fall back if an older version of SBI does not support the updated
capabilities. Both the operating system and SEE can be implemented to be
two way backward compatible.

## SBI Calling Conventions (TODO)
There are some suggestions[3] to distinguish between SBI function return
value and SBI calling sequence return value. Here are the few possible
discussed ideas.

1. Return a single value, but values in the range {-511, -1} are
considered errors, whereas return values in the range {0, 2^XLEN-512}
are considered success.

2. Every SBI function call may return the following structure
```
struct valerr {
long value;
long error;
};
```
According to the RISC-V ABI spec[4], both a0 & a1 registers can be used
for function return values.

3. Introduce an extra argument that can return error by reference.
```
/* Returns the CPU that was started.
* @err indicates an error ID if one occurred, otherwise 0.
* @err can be NULL if no error detection is required.
*/
int start_cpu(int cpu_num,..., Error *err);
```
Both approaches (2 & 3) will work, but there will be two versions of
existing SBI functions to maintain the compatibility.

## SBI Functions:

A SBI function is an individual feature that SBI interface provides to
supervisor mode from machine mode. Each function ID is assigned as per
below section.

#### SBI Function ID numbering scheme:
A Function Set is a group of SBI functions which collectively implement
similar kind of feature/functionality. The function ID numbering scheme
need to be scalable in the future. At the same time, function validation
check should be as quick as possible. Keeping these two requirements in
mind, a hybrid function ID scheme is proposed.

SBI Function ID is u32 type.

```
31 24 0
-----------------------------------------
|O| | |
-----------------------------------------
Function Set | Function Type |
```
Bit[31] = ID overflow bit

Bit[30:24] = Function Set

Bit[23:0] = Function Type within Function Set

The Function set is Bits [31:24] describing both function set number and
overflow bit. In the beginning, the overflow bit should be set to
**zero** and the function Type per function set can be assigned by left
shifting 1 bit at a time. The overflow bit can be set to one **only**
when we need to allocate more than 24 functions per function set in
future. Setting the overflow bit will indicate an integer function type
scheme. Thus, there will more than enough function IDs available to use
in the future. Refer appendix 1 for examples.

Here are few Function Sets for SBI v0.2:

| Function Set | Value | Description
|
| ------------------- |:------:|
:--------------------------------------------|
| Base Functions | 0x00 | Base Functions mandatory for any SBI
version |
| HART PM Functions | 0x01 | Hart UP/Down/Suspend Functions for
per-Hart power management|
| System PM Functions | 0x02 | System Shutdown/Reboot/Suspend for
system-level power management|
| Vendor Functions | 0x7f | Vendor specific Functions|

N.B. There is a possibility that different vendors can choose to assign
the same function numbers for different functionality. That's why vendor
specific strings in Device Tree/ACPI or any other hardware description
document can be used to verify if a specific Function belongs to the
intended vendor or not.

# SBI Function List in both SBI v0.2 and v0.1

|Function Type | Function Set | ID(v0.2) |ID (v0.1) |
|---------------------------| ------------------|:------------:|:---------:|
| sbi_set_timer | Base | 0x00 000000 |0 |
| sbi_console_putchar | Base | 0x00 000001 |1 |
| sbi_console_getchar | Base | 0x00 000002 |2 |
| sbi_clear_ipi | Base | 0x00 000004 |3 |
| sbi_send_ipi | Base | 0x00 000008 |4 |
| sbi_remote_fence_i | Base | 0x00 000010 |5 |
| sbi_remote_sfence_vma | Base | 0x00 000020 |6 |
| sbi_remote_sfence_vma_asid| Base | 0x00 000040 |7 |
| sbi_shutdown | System PM | 0x02 000000 |8 |
| sbi_system_reset | System PM | 0x02 000001 |- |
| sbi_get_version | Base | 0x00 000080 |- |
| sbi_get_function_mask | Base | 0x00 000100 |- |
| sbi_get_function_count | Base | 0x00 000200 |- |
| sbi_hart_up | Hart PM | 0x01 000000 |- |
| sbi_hart_down | Hart PM | 0x01 000001 |- |
| sbi_hart_suspend | Hart PM | 0x01 000002 |- |
| sbi_hart_state | Hart PM | 0x01 000004 |- |

#### Function Description

This section describes every newly introduced(in v0.2) function in
details. Please refer to [1] for any v0.1 functions.

```
u32 sbi_get_version(void):
```
Returns the current SBI version implemented by the firmware.
version: uint32: Bits[31:16] Major Version
Bits[15:0] Minor Version

The existing SBI version can be 0.1. The proposed version will be at 0.2
A different major version may indicate possible incompatible functions.
A different minor version must be compatible with each other even if
they have a higher number of features.

```
u32 sbi_get_function_mask(u32 ftype)
```
Given a function set type, it returns a bitmask of all functions IDs
that are implemented for that function set.

```
u32 sbi_get_function_count(u32 ftype, u32 start_fid, unsigned long count):
```

This is a **reserved** function that should only be used if overflow bit
in SBI function ID is set.

Accepts a start_Function_id as an argument and returns if
start_Function_id to (start_Function_id + count - 1) are supported or not.

A count can help in minimizing the number of the M-mode traps by
checking a range of SBI functions together.

```
int sbi_hart_up(unsigned long hartid, unsigned long start, unsigned
long priv)
```
Brings up "hartid" either during initial boot or after a sbi_hart_down
SBI call.

"start" points to a runtime-specified address where a hart can enter
into supervisor mode. This must be a physical address.

"priv" is a private data that caller can use to pass information about
execution context.

Return the appropriate SBI error code.

```
int sbi_hart_suspend(u32 state, unsigned long resume_entry, unsigned
long priv)
```
Suspends the calling hart to a particular power state. Suspended hart
will automatically wake-up based on some wakeup events at resume_entry
physical address.

"priv" is a private data that caller can use to pass information about
execution context. The SBI implementation must save a copy so that
caller can reuse while restoring hart from suspend.

Return the appropriate SBI error code.

```
int sbi_hart_down()
```
It powers off the hart and will be used in cpu-hotplug.
Only individual hart can remove itself from supervisor mode. It can be
moved to normal state only by sbi_hart_up function.

Return the appropriate SBI error code.

```
u32 sbi_hart_state(unsigned long hartid)
```
Returns the RISCV_POWER_STATE for a specific hartid. This will help make
kexec like functionality more robust.

```
void sbi_system_reset(u32 reset_type)
```
Reset the entire system.

## Return error code Table:
Here are the SBI return error codes defined.

| Error Type | Value |
| -------------------------|:------:|
| SBI_ERR_SUCCESS | 0 |
| SBI_ERR_FAILURE | -1 |
| SBI_ERR_NOT_SUPPORTED | -2 |
| SBI_ERR_INVALID_PARAM | -3 |
| SBI_ERR_DENIED | -4 |
| SBI_ERR_INVALID_ADDRESS | -5 |


## Power State
A RISC-V core can exist in any of the following power states.

| Power states | Value | Description
|
| -------------------
|:------:|:---------------------------------------------|
| RISCV_HART_ON | 0 | Powered up & operational.
|
| RISCV_HART_STANDBY | 1 | Powered up but at reduced energy <br>
consumption WFI instruction can be used to achieve this state|
| RISCV_HART_RETENTION | 2 | Deeper low power state. No reset <br>
required but higher wakeup latency|
| RISCV_HART_OFF | 3 | Powered off. Reset of the core
required after power restore|

**_TODO_**:

We probably also need deeper hart power states or system-level power
state reporting at some point, and non-HART components (caches, memory,
etc). Likely aligned with platform specs, once those start to show up.

## Implementation
Currently, SBI is implemented as a part of BBL. There is a different SBI
implementation available in coreboot as well.

Alternatively, a separate open BSD/MIT licensed SBI project can be
created that can be used by anybody to avoid this kind of SBI
fragmentation. This project can generate both a firmware binary (to be
executed directly in M mode) or a static library that can be used by
different boot loaders. It will also help individual bootloaders
to either work from M or S mode without a separate SBI implementation.

## Conclusion
This proposal is far from perfect and absolutely any suggestion is
welcome. Obviously, there are many other functionalities that can be
added to this proposal. However, I just wanted to start with something
that is an incremental change at best to kick off the discussion. The
aim here is to initiate a discussion that can lead to a robust SBI
specification.

## Reference:

[1]
http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf

[2] https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.md

[3] https://github.com/riscv/riscv-sbi-doc/pull/9

[4] https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md

## Appendix

1. Overflow Reserved bit example.

Let's choose function set type as Hart PM (0x1)

Function1 : 0x01 000001<br>
Function2 : 0x01 000002<br>
Function3 : 0x01 000004<br>
.<br>
.<br>
.<br>
Function24:0x01 800000<br>

At this point in future, Let's say we need more function IDs for Hart
PM. The scheme can be switched to an integer scheme by setting the
overflow bit.

Function25: 0x81 000001<br>
Function26: 0x81 000002<br>
Function27: 0x81 000003<br>
Function28: 0x81 000004<br>
.<br>
.<br>
Function34: 0x81 00000A<br>
.<br>

[Luke Kenneth Casson Leighton]

On Sat, Nov 10, 2018 at 2:42 AM Atish Patra <atish...@wdc.com> wrote:

> ## Conclusion
> This proposal is far from perfect and absolutely any suggestion is
> welcome. Obviously, there are many other functionalities that can be
> added to this proposal. However, I just wanted to start with something
> that is an incremental change at best to kick off the discussion. The
> aim here is to initiate a discussion that can lead to a robust SBI
> specification.

very cool, atish.

i would very much like to see the optional addition of multiple
serial lines, by adding a getchar and putchar function that takes just
one extra argument: the serial line index.

there are a lot of different uses to which mult-serial lines may be put:

* boot message separation from console login
* boot management separation from other purposes (u-boot/coreboot)
* virtual /dev/ttyS0-3
* clean UPS reporting and management
* remote virtual machine power management (power-on / off)
* simple bog-standard multiple virtual login consoles
* separation of debug messages (stdout/stderr) to ease debugging and
development
* remote and virtual OpenOCD and kernel debugging without disrupting
the main serial console
* PPP serial links.

this latter is one that i am particularly interested in, as i would
like to be able to boot a full GNU/Linux OS on spike, given the lower
barrier to entry in making modifications and experimenting with spike
than it is with qemu.

if spike were able, through a multi-serial SBI interface, to have a
PPP serial line, it would be possible to run a root NFS (or other
network block device) without having to sacrifice console access. it
would be possible to create an initramfs from a lower-capability
system like buildroot, containing PPP, enable it, and pivot-root out
to a full stock GNU/Linux OS such as debian or fedora.

so there are huge benefits, reducing the development barrier to entry
into RISC-V experimentation and debugging, and opening up a much wider
range of capabilities and possibilities for machine and virtual system
management.

l.

[David Abdurachmanov]

On Sat, Nov 10, 2018 at 3:42 AM Atish Patra <atish...@wdc.com> wrote:
>
[..]

> 2. Every SBI function call may return the following structure
> ```
> struct valerr {
> long value;
> long error;
> };
> ```

[..]

> int sbi_hart_suspend(u32 state, unsigned long resume_entry, unsigned
> long priv)

A small nictpick, but could we have consistent typing/language in the document?
I see you use "long", and even mix "int" and "u32" in a single definition.

If I look into PSCI I see:
```
SMC32 uint32
SMC64 uint64
entry_point_address
```
which leaves less interpretation for my eyes. For example, "long" can be
32-bit or 64-bit long depending on a few things and thus easier to make
mistake interpreting the spec.

I would suggest to use (u)int32/(u)uint64/friends and something
similar to SMC{32,64}
if needed.

david

[Andrew Waterman]

Note, however, that the same spec is meant to be used for both RV32 and RV64 systems, so some degree of type parameterization is necessary.

david

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Sat, Nov 10, 2018 at 3:31 PM Nick Kossifidis <mi...@ics.forth.gr> wrote:

> The current SBI says that console_getchar/console_putchar are for the
> debug
> console but on Linux we use them for the main console on earlyprintk.

... yeah exactly. and what if something goes wrong, you want to be
able to interact over openocd without interfering with that
earlyprintk, particularly during that critical first bringup phase of
real-world silicon?

> I
> think it's misleading and we should at least have an argument to chose
> between the main console and an optional debug console, or rename
> them to debug_console_getchar/debug_console_putchar and
> main_console_getchar/
> main_console_putchar.

i initially thought of proposing that, however:

(1) the API already exists with "single console". it would therefore
be disruptive to change that

(2) if adding something called debug_console_{get/put}char, it might
as well take advantage of the opportunity to be extended and made
generic, and have the extra argument added

> However I don't think that argument should be the serial line. Different
> vendors may use different serial lines for the main console / debug
> console,
> the caller doesn't know which serial line maps to which console, so the
> SBI
> should be more abstract and use something like a console id where e.g. 0
> is
> main console an 1 is debug.

yes, it should [have]: my feeling is, it's a little late in the game
given that it's almost certainly baked into pre-existing hardware, by
now, so the next best thing is a new function call.

l.

[ron minnich]

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?

see https://github.com/riscv/riscv-sbi-doc/pull/12 for other thoughts.

Also, I've had discussions with some security folks in our firmware
community about the fact that the PMP can be used in a way that the
kernel can not measure the SBI, since SBI might read-protect itself.
This is a real step backwards, FYI. Not sure if it can be changed at
this point.

ron
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.

> --
> You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
> To post to this group, send email to sw-...@groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAPweEDz-7oRg2UWPkvTDdfi36Z4PQLAuLdL3-Sy-kmkGEJ%3D44A%40mail.gmail.com.

[Samuel Falvo II]

on sat, nov 10, 2018 at 8:46 am ron minnich <rmin...@gmail.com> wrote:
> 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

i'm inclined to agree with the overall sentiment of the concerns
raised herein (omitted for brevity), but i feel that it might go a bit
too far.

the bios has its roots with cp/m, i think we all can agree with this,
and there the bios was well-matched to its task: booting cp/m.
nothing more, nothing less.

you had i/o routines for teletype output, keyboard input, paper tape
input, and punch output. as well, you had basic primitives for
reading and writing sectors on mass storage devices. and, unless you
were porting cp/m itself to a completely new platform, you never had
to *really* worry about the physical constraints of those mass storage
devices. maximum number of sectors and tracks were about the extent
of things. you never had to call back into anything, either.

in other words, bios was a *library*, not a *framework.* it was
*deliberately* designed and scoped to just deal with booting into a
cp/m environment.

originally, the pc bios was built the same way -- it was what you used
to boot pc-dos (nee ms-dos).

only *later* did massive api changes get lumped into the bios. things
like protected memory support, acpi power mode settings, etc. all but
required changing the bios away from being a library and into more of
a framework/miniature os unto itself.

i think the real lessons to be learned here are:

1) the bios interface was dictated by the demands of booting and
running a preferred (though not the only) os. in other words, the
*os* dictated the bios interface. bios literally was what one would
call a "hal" (hardware abstraction layer) these days. the fact that
others have technically used bios to boot into other, non-sanctioned
oses over the years is, technically, an abuse of the interface that
just happens to work.

2) bios was strictly a library. the maximum extent to which bios was
a framework stopped firmly at loading in the master boot record and
dispatching control to it. from then on, you were utterly on your
own. note: no security hoo-haw here. no signed anything. no pe
executables. no rom-filesystems. no dedicated uefi partitions. et.
al. just read in 512b to 1kb of raw binary blob, and run it. that's
it. from then on, bios was a library first and always. anything we
come up with for an sbi must, in my opinion, behave the same way.

oh, btw, before people get the idea that uefi allows per-partition
filesystems, please note that os/2 used "micro-filesystem drivers" to
achieve this same effect with nothing more sophisticated than the
partition table located in a dos 3.3 mbr. don't drink the uefi
kool-aid.

3) corrallary to (2): because bios was just a library, you could throw
it away en mass at any time (and after booting into the os of your
choice, it frequently was). you could, if you were clever enough with
page tables and the like, even replace the bios with your own image if
you wanted to. this speaks to what ron has discussed in prior threads
over the concerns of not being able to replace m-mode software.

4) support for multiple devices is not necessarily a bad thing; just,
don't go hog wild with it. there's no need to support 256 possible
serial ports, for example. ok, you have a debugger interface, a
resident console, and maybe one more for auxiliary purposes (for
example, my kestrel-3 design so far needs *two* serial interfaces to
the host pc, one which is the user's console, and one which is used to
access mass storage). each of these devices should have their own
read/write interface, thus making it impeccably clear in the source
code what it is you're trying to do. no need to "open" things.

my point here is, going back to the needs of the *os* and not the bios
for bios' sake, the interface exposed by the bios should match the
overall expectations of the os you're booting. in my case, i *need*
two serial interfaces for my prototype computer to function: ergo, it
makes perfect sense for my firmware to provide support for two serial
interfaces. for the linux, this need not be the case; maybe only one
interface is required.

> 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.

i'm reposting this block of test because i agree completely with it,
and want to point out that it doesn't contradict what i wrote above.

> 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.

another option is to use escape sequences preceding each output.
escape byte 1 would mean "future bytes are sent to the debugger",
while byte 2 would mean "future bytes are intended for console
output." this gives you support for all 8-bits (if your debugger
interface happens to be binary), with the occasional overhead of
escaping escape bytes.

trivial to implement both on the receiving and transmitting sides,
possibly even simpler than the bit-7-target-address approach above.
the only disadvantage is that it's stateful; but if you have a serial
connection reliable enough to use with a binary debugging interface,
it'll almost certainly be reliable enough for this too.

--
samuel a. falvo ii

[Samuel Falvo II]

Sorry for being all lower-case; I composed my text in Vim, and when I
copied it to the clipboard, I must have issued a command that
lowercased everything accidentally.

On Sat, Nov 10, 2018 at 9:41 AM Samuel Falvo II <sam....@gmail.com> wrote:
> i'm inclined to agree with the overall sentiment of the concerns
> raised herein (omitted for brevity), but i feel that it might go a bit
> too far.

--
Samuel A. Falvo II

[Luke Kenneth Casson Leighton]

On Sat, Nov 10, 2018 at 4:46 PM ron minnich <rmin...@gmail.com> wrote:

> Which is why I'm a bit unhappy to see this (to me) cancerous growth in
> proposals for M- mode code. PPP in firmware?

no, ron, absolutely not, that would not make any sense at all:
getting what is otherwise a userspace pppd into firmware would be a
nightmare as it would require a huge amount of POSIX support dragged
in with it.

it would be ppp running in spike userspace (buildroot in an
initramfs), where the linux kernel would have absolutely standard ppp
modules compiled up, the serial data drops down to spike over the
proposed modified SBI, which, on having support for the proposed
addition, will take an extra command-line option "spike
--serial-line-0-redirect-cmd='pppd'" which gets it into the host, and
the guest spike OS gets network in a dead straightforward fashion, for
very little in the way of code and ABI modifications.

it's a cut/paste job, for goodness sake, in the pre-existing SBI
implementations, just adding an extra argument.

it's real simple, and has absolutely nothing to do with the [crazed!]
idea of porting a userspace ppp POSIX daemon into u-boot/coreboot. i
mean, you *could* do it but you'd be insane to consider it, and there
are better options for the more complex systems... which don't *have*
to use the proposed idea.

the alternative to achieve the same desired goal is to re-wire all of
the u-boot/coreboot source code and use some form of serial line
"framing" protocol, to emulate multiple virtual serial lines over the
single SBI console. and rewrite openocd to support it. and. and.
and. and.

that's a lairy nightmare waiting to happen, and, on early debug of
real silicon where you're hand-programming the PLL and the serial
port's outputting crap because you've no idea of the baud rate, you
wouldn't see ASCII characters if you got it right, you'd see framing
crap instead and couldn't plug in simple minicom, it'd have to be a
*modified* version of minicom. etc. etc. etc. etc.

> 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.

naah. see above. it's a lot more complex and fragile than that.

l.

[Olof Johansson]

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

[Luke Kenneth Casson Leighton]

On Sat, Nov 10, 2018 at 5:39 PM Samuel Falvo II <sam....@gmail.com> wrote:

> on sat, nov 10, 2018 at 8:46 am ron minnich <rmin...@gmail.com> wrote:
> > 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
>
> i'm inclined to agree with the overall sentiment of the concerns
> raised herein (omitted for brevity), but i feel that it might go a bit
> too far.

it's also not an appropriate argument. nobody sensible would port a
POSIX pppd from userspace into boot-level firmware. the argument also
ignores the dozens of other advantageous potential use-cases.

l.

[Luke Kenneth Casson Leighton]

On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <ol...@lixom.net> wrote:

> 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.

spike (which is only around 7,000 lines of code) doesn't have native
drivers, and qemu is too heavy-duty to consider adding custom
extensions and experimental research onto.

with nothing in spike *other* than the serial console, it's the only
way in and out.

l.

[Samuel Falvo II]

On Sat, Nov 10, 2018 at 9:43 AM Luke Kenneth Casson Leighton
<lk...@lkcl.net> wrote:
> it's also not an appropriate argument. nobody sensible would port a
> POSIX pppd from userspace into boot-level firmware. the argument also
> ignores the dozens of other advantageous potential use-cases.

Regrettably, if it's one thing we've all learned from PC clone
manufacturers and BIOS vendors, it's that they're not sensible.
They're not reasonable. And they're anything but sane.

Servers designed for use in data centers are on the market right now
with adapters fully equipped with TCP/IP stacks in firmware *just* to
give a remote operator control over a computer's PS/2 or serial ports,
for instance.

You can bank that it'll happen with RISC-V as well.

[Luke Kenneth Casson Leighton]

On Sat, Nov 10, 2018 at 5:45 PM Nick Kossifidis <mi...@ics.forth.gr> wrote:

> > yes, it should [have]: my feeling is, it's a little late in the game
> > given that it's almost certainly baked into pre-existing hardware, by
> > now, so the next best thing is a new function call.
> >
> > l.
>

> Late in the game ? Who's game ? Is there any "standard" way out there
> for mapping consoles to serial line indices ?

any implementor that has put a SBI v1.0 into a boot ROM in production
silicon (or even has put it into a design that's already had USD $5m+
of engineering time and testing done), would be absolutely screwed by
changes to v1.0 SBI.

if however... if a way could be found to negotiate v1.0 being as-is,
and v2.0 declaring that there was an extra argument? yeah that would
work.

i don't mind either way: i just really need to not have to have the
financial burden of augmenting and maintaining special ports of half a
dozen applications including minicom.

l.

[Nick Kossifidis]

+1

>> 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.
>

+1, most people will just use minicom/picocom to do their job, not
implement
a protocol over serial for splitting main console from debug console.

[Luke Kenneth Casson Leighton]

*snort* yeah. is that a good enough reason to terminate all and any
discussion of enhancing a general-purpose generic API that has several
other beneficial use-cases? reminds me of the adage "guns don't kill
people: people kill people".

l.

[ron minnich]

On Sat, Nov 10, 2018 at 9:42 AM Olof Johansson <ol...@lixom.net> wrote:

> 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.

Totally agree. OK, so, at least we don't need the "index" in the SBI
call to pick a console, right?

[Nick Kossifidis]

Anything more than a main/debug console is too much for the SBI, its
goal is to be used early on in the boot process until the OS or the
bare metal app takes control. Having multiple serial lines through
the SBI for things like PPP, UPS, virtual consoles and all the stuff
you mentioned is out of scope. Boot an OS and use the standard UART
drivers for accessing the serial lines. If there are no drivers
or support on spike, it's open source ! Also you may always use
the vendor specific SBI that Atish proposes here for adding that
functionality, having this on the base SBI is not the right
approach IMHO.

Regards,
Nick

[Samuel Falvo II]

I think you are misunderstanding what I'm writing.

My tale is one of caution, not prevention. I'm OK with having a BIOS.
History shows that the problems on the PC platform all started when
the BIOS *disappeared*; when it *stopped* *being* a BIOS.

My claim is that Ron's reaction is, while well-intentioned and has
solid roots in first-hand experience, nonetheless a bit extreme. Not
having any BIOS at all is, in my estimation, worse than having one
that is 50 years old.

[ron minnich]

Actually, as long as the option remains to let the kernel replace the
SBI with something else, I'm not that worried about what vendors put
in it. But that option needs to remain there.

[Olof Johansson]

I'll repeat myself:

"trying to optimize for those use cases is a misdirected effort".
Trying to optimize your experience on spike at the cost of simplicity
for everybody else is the wrong thing to do.


-Olof

[Luke Kenneth Casson Leighton]

On Sat, Nov 10, 2018 at 6:02 PM ron minnich <rmin...@gmail.com> wrote:

> Actually, as long as the option remains to let the kernel replace the
> SBI with something else, I'm not that worried about what vendors put
> in it. But that option needs to remain there.

i remember you saying, when the boot discussion came up a couple
weeks ago, and agree absolutely: the option in real hardware to shut
off and replace whatever's got you up and running is critical.

there's a huge range of uses to which SBI is (and can be) put: i
threw some ideas out there, i feel it's important to bear that in
mind. it's not just used for booting, it's also got simulation,
debugging, development and critical first silicon bring-up potential,
out-of-band remote power management potential uses, virtual management
potential, and shed-loads more.

l.

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Sat, Nov 10, 2018 at 6:03 PM Olof Johansson <ol...@lixom.net> wrote:

> "trying to optimize for those use cases is a misdirected effort".
> Trying to optimize your experience on spike at the cost of simplicity
> for everybody else is the wrong thing to do.

i hear you on why you believe it's an optimisation: i get it, it's a
public API. that's why i put out a shed-load of other potential
use-cases.

l.

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Sat, Nov 10, 2018 at 5:59 PM Nick Kossifidis <mi...@ics.forth.gr> wrote:
>
> Στις 2018-11-10 19:47, Luke Kenneth Casson Leighton έγραψε:
> > On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <ol...@lixom.net> wrote:
> >
> >> 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.
> >
> > spike (which is only around 7,000 lines of code) doesn't have native
> > drivers, and qemu is too heavy-duty to consider adding custom
> > extensions and experimental research onto.
> >
> > with nothing in spike *other* than the serial console, it's the only
> > way in and out.
> >
> > l.
>
> Anything more than a main/debug console is too much for the SBI, its
> goal is to be used early on in the boot process until the OS or the
> bare metal app takes control.

nooo, that's just _one_ use to which it's being put.

> Having multiple serial lines through
> the SBI for things like PPP, UPS, virtual consoles and all the stuff
> you mentioned is out of scope.

why?

> Boot an OS and use the standard UART
> drivers for accessing the serial lines. If there are no drivers
> or support on spike, it's open source !

this is a common misconception that "because it's open source anyone
can do what they want". code costs money. servers to host code cost
money. answering the emails where people expect "free" support
because you're hosting the only public version of that server costs
money.

i'm an ethical libre developer: i can't go footing the bill for other
people to sponge off my efforts all the time, i've had 20 years of
people doing that and i'm f*****g well not putting up with it on this
project.

so no, mick, sorry, not buying the argument "it's open source".

l.

[Nick Kossifidis]

Because the firmware is meant to be something minimal, not to replace
the
OS. Let me ask you this, if you want to change UART speed or settings in
general would you also ask for an SBI call for that ? What's coming up
next ? Adding networking support for example ? Where do you put the
barrier
on firmware's complexity / scope ?

>> Boot an OS and use the standard UART
>> drivers for accessing the serial lines. If there are no drivers
>> or support on spike, it's open source !
>
> this is a common misconception that "because it's open source anyone
> can do what they want". code costs money. servers to host code cost
> money. answering the emails where people expect "free" support
> because you're hosting the only public version of that server costs
> money.
>

Even if we decide that the SBI gets extended for accessing different
serial lines, someone will have to write code for that e.g. on BBL or on
OpenSBI, coreboot etc. If we follow your logic, maintaining, hosting
and supporting this also costs money. So what's the point here ? That
it's easier to implement it there for everyone than write a UART driver
for spike ?

By the way spike is an ISA simulator, I don't see why it should emulate
UART ports, last time I checked it didn't, so someone will need to write
code for that, more money ! You can use QEMU for that where you can have
as many UARTs as you want and the drivers for them are already available
for you.

> i'm an ethical libre developer: i can't go footing the bill for other
> people to sponge off my efforts all the time, i've had 20 years of
> people doing that and i'm f*****g well not putting up with it on this
> project.
>
> so no, mick, sorry, not buying the argument "it's open source".
>
> l.

Don't assume you are the only one.

Regards,
Nick

[Atish Patra]

I completely agree with this. Once we finalize a decent SBI spec, any
additional SBI call should be vetted through community and added only if
**absolutely** necessary. I had echoed same thoughts for a request about
adding SBI calls for perf & trigger modules in the mailing list.

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?
>

I think the larger picture might have lost somewhere because of the
verbosity of the proposal. The idea of adding vendor extension support
in SBI is to allow them provide a standard mechanism to facilitate this.
In absence of that, vendor might adopt different approaches to support
their feature leading a lot of chaos. Vendors can not go and add
anything in the Linux kernel(just a example, SBI is still OS agnostic)
as well.

Example:
http://lists.infradead.org/pipermail/linux-riscv/2018-November/002086.html

I am not sure which part in the proposal led to the conclusion that
adding vendor-specific forks will super easy. I am more than happy to
correct it.

> see https://github.com/riscv/riscv-sbi-doc/pull/12 for other thoughts.
>

Thanks a lot for the review. I am going through the suggestions.


Regards,
Atish

[Tommy Murphy]

> I'm an ethical libre developer: i can't go footing the bill for other

people to sponge off my efforts all the time, i've had 20 years of
people doing that and i'm f*****g well not putting up with it on this
project.

Off topic, but just to mention ... you keep banging on about being bullied on these forums but yet you're the only individual here that I know who keeps using profanities (albeit self censored) which betrays an aggressive tone towards those to whom you are responding. Any chance you could practice what you preach on dealing with people here? Thanks.

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

of course, not, nick. it's a simple cut/paste of the existing
console getchar/putchar code. you're beginning to alarm me by making
this out to be much more complex than it is.

if i'd thought it was a good idea to propose an SBI call to change
UART speed or settings, i would have said so. there's absolutely no
need to make it *look* like i've proposed that. doing so - putting
words into someone else's mouth - is unethical, and i'd appreciate it
if you could stop doing it.

> What's coming up next ?

nothing, nick. just one extra parameter to the console
getchar/putchar function [or a duplicate function which does] that's
all.

> Adding networking support for example ?

of course not. why on earth would that make sense? how on earth
would networking fit into a 16k Boot ROM?

i feel that you're arguing and throwing up straw-man questions for
arguments' sake, here, hoping that one of them will stick, and that by
ignoring the positive aspects of the (incredibly simple)
cut/paste-style minimalist proposal and throwing as many "bad" ones
out there, it'll somehow.. do.. i dunno, what *is* the purpose of the
questions you're asking?

> Where do you put the
> barrier
> on firmware's complexity / scope ?

at the exact same point that you do, under the circumstances and
context in which you're looking at and from.

now, can you recognise that there are *other* needs and requirements
as well, beyond the ones that you have?

> By the way spike is an ISA simulator, I don't see why it should emulate
> UART ports, last time I checked it didn't,

ah, nick, i get the feeling you're deliberately looking for ways to
be obstructive, and also fundamentally misunderstanding how the
getchar / putchar code works.

spike provides a minimal implementation of the SBI, via libfesvr.
the data that goes to the getchar/putchar function is ultimately
redirected to a minimalist stdin / stdout implementation. there *is*
no call to UART ports.

come on, man, be a little less adversarial: it makes life easier for everyone.

> so someone will need to write
> code for that, more money !

i'll happily do it, as i need it. it's a straight cut/paste of
pre-existing code.

> You can use QEMU for that where you can have
> as many UARTs as you want and the drivers for them are already available
> for you.

i *can't*. qemu is too complex and i've invested 2 months of
personal money - without funding or grants from any corporation or
institution - into spike, precisely because it's only 7,000 lines of
code.

modifying qemu is too much. i've seen signs that they're moving into
JIT optimisation territory, which is far too complex to get involved
with.

spike is simple, it's straightforward, it's fast, and it works.

> > i'm an ethical libre developer: i can't go footing the bill for other
> > people to sponge off my efforts all the time, i've had 20 years of
> > people doing that and i'm f*****g well not putting up with it on this
> > project.
> >
> > so no, mick, sorry, not buying the argument "it's open source".
> >
> > l.
>
> Don't assume you are the only one.

good to hear.

now... can i ask you if you could possibly turn down the adversarial
straw-man thing just a leeeetle tiny bit? it takes a huge amount of
effort on your part to maintain, and makes it really really difficult
for everyone to have to read, "no, that's not right, no, that's not
true either, no, i didn't say that at all" and so on.

what do you think?


l.

[Luke Kenneth Casson Leighton]

interestingly, if you've seen mythbusters, they tested people's
tolerance to pain (ice water) by having them swear and not swear, and
timing how long they could tolerate it.

when people swore, they found that they were able to tolerate pain
for a lot longer.

i mention that as i think it gives some insight and clears up some
misunderstandings. i'm swearing because the bullying is hurting my
feelings, and the swearing helps me to reduce some of the pain that
peoples' responses are causing me when i read their words.

i'd like to see these lists be a welcoming and encouraging place
where useful technical discussion can take place, and corporations,
students, researchers and libre/open developers can constructively
learn from each other, where they feel comfortable expressing their
needs and requirements to the rest of the RISC-V community, knowing
that they will be heard, encouraged, and supported.

l.

[Nick Kossifidis]

Sorry that wasn't my intention, my intention was to understand what you
want to achieve. On the one hand you mentioned that you want an SBI
API change so that you can better work with spike, on the other hand
in order to convince the rest of us that this is a good approach for
the SBI API, you mentioned some examples that to me look like
overengineering at this point. I would never e.g. use getchar/putchar
for
example for PPP etc. On another example you mentioned using this serial
line for providing networking with spike. My questions are honest, I'm
not trying to put words on your mouth.

>> What's coming up next ?
>
> nothing, nick. just one extra parameter to the console
> getchar/putchar function [or a duplicate function which does] that's
> all.
>

ACK and as I told you on my first reply, my only concern there is that
this argument shouldn't be about serial line indices but about "types"
so that (since this thing is going to end up on actual hardware) vendors
don't mess up. If you say serial line 0 for example and your code
assumes
this is the main console, another vendor might put the debug console
there
or an auxiliary console. By using a console id instead of a serial line
index, you can hide this on the firmware and deal with it there.

>> Adding networking support for example ?
>
> of course not. why on earth would that make sense? how on earth
> would networking fit into a 16k Boot ROM?
>

I don't know, why on earth should a 16k Boot ROM be used for accessing
multiple serial lines for PPP, UPS etc ? To me that's the work of an OS,
the same OS that will handle the running of PPP/UPS monitor/whatever.
If you use such examples you should expect that people will assume the
worst (I'm not the only one that assumed the worst btw), and that's what
any reviewer should do.

> i feel that you're arguing and throwing up straw-man questions for
> arguments' sake, here, hoping that one of them will stick, and that by
> ignoring the positive aspects of the (incredibly simple)
> cut/paste-style minimalist proposal and throwing as many "bad" ones
> out there, it'll somehow.. do.. i dunno, what *is* the purpose of the
> questions you're asking?
>

The positive aspects of supporting multiple serial lines through the SBI
getchar/putchar code that you mention are not clear to me, that's why
I'm
asking what's the purpose of this other than a hack to get around
limitations on spike. Supporting PPP for example without being able
to set serial parameters is a hack and we shouldn't be discussing that
in the context of the SBI.

>> Where do you put the
>> barrier
>> on firmware's complexity / scope ?
>
> at the exact same point that you do, under the circumstances and
> context in which you're looking at and from.
>
> now, can you recognise that there are *other* needs and requirements
> as well, beyond the ones that you have?
>

I can understand changing the current SBI and adding an extra argument
to
chose between a main and a debug console (not by serial line index as I
mentioned above but through a console id argument). Could you please
help
me understand why you want support for more ports than that on the base
SBI ?

You mentioned the following...

> * boot message separation from console login

ACK I agree on that, that's what the debug uart can be used for, lots
of people are doing that. However if by boot messages you mean anything
other than dmesg output, you need syslog for that and a /dev/tty* entry
for the debug (or any other) console. To me providing this through a
driver
that's just a wrapper around the SBI and provides only a small subset of
what a tty driver should provide is fundamentally wrong.

That's why I believe the SBI should only be used for earlyprintk and in
general for things before the OS boots. Once the OS boots we should
have proper UART support.

> * boot management separation from other purposes (u-boot/coreboot)

That makes more sense, at least in this case everything is built-in
on u-boot/coreboot so using a different way of accessing the
main and the debug console shouldn't be a big deal. However I still
don't see any value here for more consoles than main/debug.

> * virtual /dev/ttyS0-3
> * clean UPS reporting and management
> * remote virtual machine power management (power-on / off)
> * simple bog-standard multiple virtual login consoles

To me this is way off, we have networking for that, why on earth should
anyone use serial ports ?

> * separation of debug messages (stdout/stderr) to ease debugging and
> development
> * remote and virtual OpenOCD and kernel debugging without disrupting
> the main serial console
> * PPP serial links.

So again you'll need /dev/tty* for that, which should be handled by
a proper UART driver. Especially for the PPP, unless all you want to
do is hack your way through.

>> By the way spike is an ISA simulator, I don't see why it should
>> emulate
>> UART ports, last time I checked it didn't,
>
> ah, nick, i get the feeling you're deliberately looking for ways to
> be obstructive, and also fundamentally misunderstanding how the
> getchar / putchar code works.
>
> spike provides a minimal implementation of the SBI, via libfesvr.
> the data that goes to the getchar/putchar function is ultimately
> redirected to a minimalist stdin / stdout implementation. there *is*
> no call to UART ports.
>

So as I said spike doesn't emulate UART ports, and it shouldn't, it's an
ISA simulator, it doesn't and shouldn't emulate devices.

> come on, man, be a little less adversarial: it makes life easier for
> everyone.
>
>
>> so someone will need to write
>> code for that, more money !
>
> i'll happily do it, as i need it. it's a straight cut/paste of
> pre-existing code.
>

So what's the issue ? You can patch spike and add your custom SBI calls
(vendor-specific) on libfesvr and you are done with it. Why should this
extension about multiple serial lines, so that you can do your hacks
when
testing on spike, should be on the base SBI ?

>> You can use QEMU for that where you can have
>> as many UARTs as you want and the drivers for them are already
>> available
>> for you.
>
> i *can't*. qemu is too complex and i've invested 2 months of
> personal money - without funding or grants from any corporation or
> institution - into spike, precisely because it's only 7,000 lines of
> code.
>
> modifying qemu is too much. i've seen signs that they're moving into
> JIT optimisation territory, which is far too complex to get involved
> with.
>
> spike is simple, it's straightforward, it's fast, and it works.
>
>

What are you trying to do ? Test a specific piece of code / ISA
extension
etc or emulate a full blown system ? If you just want networking support
on spike let's talk about this instead, that's not an issue regarding
the
SBI.

>> > i'm an ethical libre developer: i can't go footing the bill for other
>> > people to sponge off my efforts all the time, i've had 20 years of
>> > people doing that and i'm f*****g well not putting up with it on this
>> > project.
>> >
>> > so no, mick, sorry, not buying the argument "it's open source".
>> >
>> > l.
>>
>> Don't assume you are the only one.
>
> good to hear.
>
> now... can i ask you if you could possibly turn down the adversarial
> straw-man thing just a leeeetle tiny bit? it takes a huge amount of
> effort on your part to maintain, and makes it really really difficult
> for everyone to have to read, "no, that's not right, no, that's not
> true either, no, i didn't say that at all" and so on.
>
> what do you think?
>
>
> l.

I think that on a technical discussion labeling your peers as
"obstructive"
and "adversarial" and bringing non-technical arguments like funding
issues
etc and how ethical/libre developer you are to the table is not
appropriate.
I never judged your intentions or characterized you in any way, I'd
expect
from you to do the same.

Regards,
Nick

[Palmer Dabbelt]

Luke: You may be used to posting on the sw-dev and isa-dev mailing lists where
this kind of post appears to be acceptable. In case you didn't notice, you've
now managed to get linux-riscv on your CC list. I've already dropped all the
@riscv.org lists from my inbox because they're worthless, but work actually
happens on linux-riscv and I'd like it to continue being useful.

Please keep the noise down.

Thanks!

[Nick Kossifidis]

Hello Atish,

Στις 2018-11-10 04:42, Atish Patra έγραψε:
> Hi,
> I have updated the proposal based on feedback received on previous
> version. This version has a better scalable SBI Function ID
> numbering scheme. I have adopted markdown formatting for github docs.
>
> If you prefer a github interface, it's available here as well.
>
> https://github.com/riscv/riscv-sbi-doc/pull/12
>
> Looking forward to your feedback.
>
> Regards,
> Atish
> ------------------------------------------------------------------------
>
> ## Introduction:
> This is a proposal to make SBI a flexible and extensible interface.
> It is based on the foundation policy of RISC-V i.e. modularity and
> openness. The proposal tries to introduces very few new mandatory SBI
> Functions, that are absolutely required to maintain backward
> compatibility. Everything else is optional so that it remains an open
> standard yet robust.
>
> The current RISC-V SBI only defines a few mandatory functions such as
> inter-processor interrupts (IPI) interface, reprogramming timer, serial
> console, and memory barrier instructions. The existing SBI
> documentation
> can be found here [1]. Many important functionalities such as power
> management/cpu-hotplug are not yet defined due to difficulties in
> accommodating modifications without breaking the backward compatibility
> with the current interface.
>
> The proposed design is inspired by Power State Coordination Interface
> (PSCI) from ARM world. However, it adds only two new mandatory SBI
> calls providing version information and supported Functions, unlike
> PSCI where a significant number of functions are mandatory. The
> version of the existing SBI will be defined as a minimum version(0.1)
> which will always be backward compatible. Similarly, any Linux kernel
> with a newer feature will fall back if an older version of SBI does
> not support the updated capabilities. Both the operating system and
> SEE can be implemented to be two way backward compatible.
>

Let's remove any references to Linux, it can be misleading since
this is supposed to be used by every OS.

> ## SBI Calling Conventions (TODO)
> There are some suggestions[3] to distinguish between SBI function
> return value and SBI calling sequence return value. Here are the few
> possible discussed ideas.
>
> 1. Return a single value, but values in the range {-511, -1} are
> considered errors, whereas return values in the range {0, 2^XLEN-512}
> are considered success.
>

I'm thinking about compatibility between a 64bit firmware and a 32bit
supervisor and vice-versa. If we report back values that can't fit
within 32bits, this is going to break things.

> 2. Every SBI function call may return the following structure
> ```
> struct valerr {
> long value;
> long error;
> };
> ```
> According to the RISC-V ABI spec[4], both a0 & a1 registers can be
> used for function return values.
>

This makes sense, however let's allow for this to be extensible,
there may be SBI calls that want to return something more, there
may also be SBI calls that are asynchronous so it's a good idea I
think to also include the function id there. Also please let's use
typed integers instead. How about something like this:

struct sbi_report {
uint32_t status;
uint32_t value;
uint32_t function_id;
uint8_t has_payload;
uint16_t payload_size;
/* 1 byte hole */
void payload[];
};

> 3. Introduce an extra argument that can return error by reference.
> ```
> /* Returns the CPU that was started.
> * @err indicates an error ID if one occurred, otherwise 0.
> * @err can be NULL if no error detection is required.
> */
> int start_cpu(int cpu_num,..., Error *err);
> ```
> Both approaches (2 & 3) will work, but there will be two versions of
> existing SBI functions to maintain the compatibility.
>

If we keep the first field of sbi_report as the status code then
3 is equivalent to 2. If you just want to get the status/error code
you cast the pointer to uint32_t* instead of struct sbi_report*.

My vote goes for (1 || 2 with the mods above), meaning that I
believe we should support both, 1 for simple functions that
just want to return a value and 2 for more complex functions
that want to also return a payload or that distinguish the
return value from an error code. Alternatively I'd go with
just 2 with the mods above, since it covers both cases.

> ## SBI Functions:
>
> A SBI function is an individual feature that SBI interface provides to
> supervisor mode from machine mode. Each function ID is assigned as per
> below section.
>

As I mentioned on the previous version of your proposal
I'd like to be able to call these functions from U and
HS/HU modes as well. I think having a limitation for
accessing M mode only from S mode is wrong.

> #### SBI Function ID numbering scheme:
> A Function Set is a group of SBI functions which collectively
> implement similar kind of feature/functionality. The function ID
> numbering scheme need to be scalable in the future. At the same time,
> function validation check should be as quick as possible. Keeping
> these two requirements in mind, a hybrid function ID scheme is
> proposed.
>
> SBI Function ID is u32 type.
>
> ```
> 31 24 0
> -----------------------------------------
> |O| | |
> -----------------------------------------
> Function Set | Function Type |
> ```
> Bit[31] = ID overflow bit
>
> Bit[30:24] = Function Set
>
> Bit[23:0] = Function Type within Function Set
>
> The Function set is Bits [31:24] describing both function set number
> and overflow bit. In the beginning, the overflow bit should be set to
> **zero** and the function Type per function set can be assigned by
> left shifting 1 bit at a time. The overflow bit can be set to one
> **only** when we need to allocate more than 24 functions per function
> set in future. Setting the overflow bit will indicate an integer
> function type scheme. Thus, there will more than enough function IDs
> available to use in the future. Refer appendix 1 for examples.
>
> Here are few Function Sets for SBI v0.2:
>
> | Function Set | Value | Description |
> | ------------------- |:------:|
> :--------------------------------------------|
> | Base Functions | 0x00 | Base Functions mandatory for any SBI
> version |
> | HART PM Functions | 0x01 | Hart UP/Down/Suspend Functions for
> per-Hart power management|
> | System PM Functions | 0x02 | System Shutdown/Reboot/Suspend for
> system-level power management|
> | Vendor Functions | 0x7f | Vendor specific Functions|
>
> N.B. There is a possibility that different vendors can choose to
> assign the same function numbers for different functionality. That's
> why vendor specific strings in Device Tree/ACPI or any other hardware
> description document can be used to verify if a specific Function
> belongs to the intended vendor or not.
>
> # SBI Function List in both SBI v0.2 and v0.1
>
> |Function Type | Function Set | ID(v0.2) |ID
> (v0.1) |
> |---------------------------|
> ------------------|:------------:|:---------:|
> | sbi_set_timer | Base | 0x00 000000 |0
> |
> | sbi_console_putchar | Base | 0x00 000001 |1
> |
> | sbi_console_getchar | Base | 0x00 000002 |2
> |
> | sbi_clear_ipi | Base | 0x00 000004 |3
> |
> | sbi_send_ipi | Base | 0x00 000008 |4
> |
> | sbi_remote_fence_i | Base | 0x00 000010 |5
> |
> | sbi_remote_sfence_vma | Base | 0x00 000020 |6
> |
> | sbi_remote_sfence_vma_asid| Base | 0x00 000040 |7
> |
> | sbi_shutdown | System PM | 0x02 000000 |8
> |
> | sbi_system_reset | System PM | 0x02 000001 |-
> |
> | sbi_get_version | Base | 0x00 000080 |-
> |
> | sbi_get_function_mask | Base | 0x00 000100 |-
> |
> | sbi_get_function_count | Base | 0x00 000200 |-
> |
> | sbi_hart_up | Hart PM | 0x01 000000 |-
> |
> | sbi_hart_down | Hart PM | 0x01 000001 |-
> |
> | sbi_hart_suspend | Hart PM | 0x01 000002 |-
> |
> | sbi_hart_state | Hart PM | 0x01 000004 |-
> |
>

While I agree with the concept of categorizing functions, I think the
implementation is a bit complicated. We can just have function id
ranges instead of wasting a byte for encoding a category within the
function id. Also this approach will be backwards compatible with the
function ids we already have on current SBI.

Encoding function sets and a bitmask for functions, along with
the overflow bit on the function id seems overly complicated to me
and I don't see what we gain from this. We are wasting bits for
sets that may have only a few functions and need to support
overflow for sets that are larger than 24 functions which is not
that much, especially if you take vendor sets into account.
I understand that you want this bitmask for reporting back the list
of available functions per set but this can be done differently. For
example we can use introduce a function called sbi_call_check(uint32_t
function_id) and expect SBI_ERR_SUCCESS or SBI_ERR_NOT_SUPPORTED.

Also with regards to the DT/ACPI the hardware vendor doesn't always
imply firmware vendor. I think we should be more specific here.
Also needing a side channel to understand which vendor specific
function we are calling is suboptimal. We might want to call
a vendor specific SBI call for example before parsing DT or
ACPI.

I believe we should use GUIDs for vendor specific function calls
instead of function ids. Normally these are 128bit long (RFC 4122)
but we can get away with 64bits. Instead of allowing a range of
function ids for vendors, we can just specify one call to rule
them all, something like:

int sbi_vendor_call(uint32_t vfid_high, uint32_t vfid_low, void* arg)

under the hood this can be an SBI call e.g. with fid 0x10000000 that
takes 3 arguments (already supported), with the pointer on the 3rd
argument to point to a struct with the vendor call arguments on
call, and a pointer contain a struct sbi_report on return.

> #### Function Description
>
> This section describes every newly introduced(in v0.2) function in
> details. Please refer to [1] for any v0.1 functions.
>
> ```
> u32 sbi_get_version(void):
> ```
> Returns the current SBI version implemented by the firmware.
> version: uint32: Bits[31:16] Major Version
> Bits[15:0] Minor Version
>
> The existing SBI version can be 0.1. The proposed version will be at
> 0.2
> A different major version may indicate possible incompatible functions.
> A different minor version must be compatible with each other even if
> they have a higher number of features.
>
> ```
> u32 sbi_get_function_mask(u32 ftype)
> ```
> Given a function set type, it returns a bitmask of all functions IDs
> that are implemented for that function set.
>
> ```
> u32 sbi_get_function_count(u32 ftype, u32 start_fid, unsigned long
> count):
> ```
>
> This is a **reserved** function that should only be used if overflow
> bit in SBI function ID is set.
>
> Accepts a start_Function_id as an argument and returns if
> start_Function_id to (start_Function_id + count - 1) are supported or
> not.
>
> A count can help in minimizing the number of the M-mode traps by
> checking a range of SBI functions together.
>

As I mentioned above I thing this complicates things and forces a
suboptimal function id encoding. We can instead introduce something
like sbi_call_check() instead. As for the vendor calls, we can also
introduce:

int sbi_vendor_call_check(uint32_t vfid_high, uint32_t vfid_low);

Another reason I find sbi_vendor_call/sbi_vendor_call_check better
is because the function names follow the rest of the namespace scheme.
I'll come back to that later on.

> ```
> int sbi_hart_up(unsigned long hartid, unsigned long start, unsigned
> long priv)
> ```
> Brings up "hartid" either during initial boot or after a sbi_hart_down
> SBI call.
>
> "start" points to a runtime-specified address where a hart can enter
> into supervisor mode. This must be a physical address.
>
> "priv" is a private data that caller can use to pass information about
> execution context.
>
> Return the appropriate SBI error code.
>
> ```
> int sbi_hart_suspend(u32 state, unsigned long resume_entry, unsigned
> long priv)
> ```
> Suspends the calling hart to a particular power state. Suspended hart
> will automatically wake-up based on some wakeup events at resume_entry
> physical address.
>
> "priv" is a private data that caller can use to pass information about
> execution context. The SBI implementation must save a copy so that
> caller can reuse while restoring hart from suspend.
>
> Return the appropriate SBI error code.
>
> ```
> int sbi_hart_down()
> ```
> It powers off the hart and will be used in cpu-hotplug.
> Only individual hart can remove itself from supervisor mode. It can be
> moved to normal state only by sbi_hart_up function.
>
> Return the appropriate SBI error code.
>
> ```
> u32 sbi_hart_state(unsigned long hartid)
> ```
> Returns the RISCV_POWER_STATE for a specific hartid. This will help
> make
> kexec like functionality more robust.
>

I still think that it would be better to have sbi_hart_set_state and
sbi_hart_get_state instead of having different calls for different
states but I guess it's a matter of taste. Could we at least
use sbi_hart_get_state instead of sbi_hart_state to be consistent
with the rest of the calls that contain get/set on their name ?

> ```
> void sbi_system_reset(u32 reset_type)
> ```
> Reset the entire system.
>

Could we please rename sbi_shutdown to sbi_system_shutdown so that
it's consistent with the _system_ namespace/category ?

> ## Return error code Table:
> Here are the SBI return error codes defined.
>
> | Error Type | Value |
> | -------------------------|:------:|
> | SBI_ERR_SUCCESS | 0 |
> | SBI_ERR_FAILURE | -1 |
> | SBI_ERR_NOT_SUPPORTED | -2 |
> | SBI_ERR_INVALID_PARAM | -3 |
> | SBI_ERR_DENIED | -4 |
> | SBI_ERR_INVALID_ADDRESS | -5 |
>
>

Since success is not error, could we call them status codes or just
return codes instead ?

Thank you for your time and effort on this !

Regards,
Nick

[Michael Clark]

>> On 11/11/2018, at 6:47 AM, Luke Kenneth Casson Leighton <lk...@lkcl.net> wrote:
>>
>> On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <ol...@lixom.net> wrote:
>>
>> 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.
>
> spike (which is only around 7,000 lines of code) doesn't have native
> drivers, and qemu is too heavy-duty to consider adding custom
> extensions and experimental research onto.

Neither of those statements are completely true. Spike can have its hardware emulation capabilities expanded and QEMU is not unsuitable for experimental research. For example, we have been developing the CLIC interrupt controller model in QEMU.

We also could port VirtIO from RISCVEMU to spike. It would be nice to add the PLIC, CLIC and an NS16550A UART to spike so we can model the RISC-V “virt” machine that is currently in QEMU.

That said, you are probably correct. A simulator like spike makes a little more sense for evolving the hardware models versus a heavy-weight fast-model emulator like QEMU.

> with nothing in spike *other* than the serial console, it's the only
> way in and out.

That’s likely to change.

There is bare metal code in BBL to support several console types (HTIF, SiFive UART, NS16550A). All of these except for HTIF have kernel device drivers. The main reason for the SBI console is to be used as a bring-up console before full device drivers have been developed and for simulation use-cases (running Linux in spike and HDL simulators).

Spike currently relies on HTIF for console and HTIF is not appropriate as a kernel device interface. HTIF is designed for tethered simulation as it relies on a front-end finding special ELF symbols used for host <-> target communications.

A polled-mode console interface is fine for debug but not appropriate for running something like pppd. Adding a tty layer (sbi_ioctl) to SBI is not a good idea. Note: an actual serial interface has several out-of-band interface to check link status and set baud rates, etc (as do the simple SBI drivers which have these details hardcoded). It’s a simple boot console.

Apologies Luke, this is not directed at you, rather it is directed at SBI.

I think we should seriously question any interface we add to SBI.

- Making SBI a library API is an invitation for binary blobs. It should remain an ECALL interface to fill in privilege boundary virtualization gaps i.e. functions that require M-mode privileges. It can’t or shouldn’t do this if it is linked to the kernel as a library. In the case it were a library the question is why not just document the hardware interface and add a driver to the kernel. For anything else, such as for virtualization; we should minimize address space footprint for anything that is not a device. Otherwise we should spend effort on defining standard hardware interfaces such as virtualizable interrupt controllers or PMUs.

- SBI shouldn’t be used as a wrapper to hide (as yet unspecified) hardware interfaces from the kernel. i.e. for example to hide a device aperture that contains configuration for both M-mode and S-mode interrupts or an interface for a function that we don’t yet have hardware for. It’s equally possible that we can make bad software interfaces.

There are some points up for discussion regards HALs.

There is a principle that functions that have typically been done in hardware can be simplified if certain aspects are devolved to software. This is valid.

We have this with S-mode timer and software interrupts which presently are delegated by the monitor who implements the SBI interface to configure or initiate them. This is not strictly because we don’t want to expose the hardware to Linux i.e. why not just write a driver in Linux? SBI is required here because these functions were initially only able to be executed in M-mode and it would violate a privilege boundary for Linux to run their code as Linux is a Supervisor. i.e. there was no direct interface for S-mode to configure or initiate software or timer interrupts.

I think the best approach is for folk to share their hardware interfaces and explore approaches that allow S-mode to operate autonomously whether M-mode exists or not. I.e. some models may require M-mode, and some models may support fully autonomous S-mode (the only M-mode function that exists is running on another core). e.g. Real-time.

Of course virtualization and real-time can be combined if the M-mode core can control interrupt routing tables on behalf of the running Supervisors. We could have multiple RTOS running with Supervisors that have pre-emptable User tasks and the virtual domains never need to enter M-mode, except perhaps for power on and power off. Maybe power management is in scope. One should probably chat to Linus about what he’d like to see... possibly not an in-kernel byte-code interpreter...


BTW Please do not swear on the list. Alex, Bruce, myself and the other posters have not written anything that warrants swearing at us. Many folk have been working away quietly in the open and the messages to the contrary are completely unfounded. Anyway this goes without saying. There is only one person swearing and shouting on this list.

Luke, you are incorrigible. Whether you are a bully or not is neither here nor there. Your behaviour on this mailing list is not acceptable. Try no shouting or swearing. Many have advised this before but there has been no change.

[Michael Clark]

On 11/11/2018, at 6:59 AM, ron minnich <rmin...@gmail.com> wrote:

On Sat, Nov 10, 2018 at 9:42 AM Olof Johansson <ol...@lixom.net> wrote:

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.

EFI has ExitBootServices. After ExitBootServices has been called, the firmware passes full control to the OS.

https://lwn.net/Articles/632528/

Any arbitration beyond that I would classify as virtualization and in the real world we don’t have more than one device driver talking to one function on one device.

We indeed do have devices with virtual functions, both at the thread and VM/domain level e.g. network adapters with one ring buffer per thread with an MSI source per queue, so interrupts can be routed to a specific hart handling one device queue, as well as separate sets of device queues that can be associated with virtual domains. These devices already work on RISC-V Linux (HiFive U with e1000), just not yet with full use of OS-level hardware virtualization features on RISC-V as the Hypervisor spec is still in draft and we don’t yet have a reference implementation.

In this case it is likely the first Supervisor on the machine that is virtualization aware that owns the virtual functions on the device (not SBI), be that a distinct Hypervisor or Linux and QEMU/KVM.

e1000 is a pretty good example of an SR-IOV adapter that supports both virtualization and multiple device queues for thread level parallelism. We have PCI IOMMU groups to create virtual domain boundaries for IO. The issue is mapping these existing virtualization constructs to the RISC-V interrupt controller models, adding support for virtualization to spike, QEMU, eventually silicon, by which time there is likely to be an IOMMU to arbitrate access between harts and devices.

Another device looks a lot like another hart if it has coherent memory access. domain/hart/mode are context (that can be switched) for address allow/deny rules on the networks they are attached to.

Totally agree. OK, so, at least we don't need the "index" in the SBI
call to pick a console, right?

It just introduces compatibility issues as we need to retain the existing interface without an index (file descriptor?) for compatibility. SBI console is supposed to be super simple.  What we have is sufficient. 

If someone seriously wants a separate debug serial line then using SBI as the interface to their serial driver is likely the last thing on their mind.

I think we need to separate things which we want to lock into standards with strong ABI compatibility and areas that need further modelling. It’s safer to not add to these standards until there are demonstration models that can be critiqued and improved.

Supervisor functionality is indeed stable in the Privileged ISA. Interrupts work and there are now fast interrupts for real-time systems. Interrupt virtualization on the other hand still needs work. We will need a new PLIC revision if we are to separate permissions for M and S mode interrupts on a single core. We will also need a CLIC driver for Linux, as SiFive’s CLIC has so far only been implemented on MCU class cores (minion cores).

SBI should stay in flux, insomuch as we don’t break what is there and add the minimum necessary for bootstrap and any area we genuinely need an interface to. I think a prototype implementation should be present for some time so that we only add necessary interfaces, and the qualifying factor seems to be “must run in M-mode due to some privilege constraints”. If for example power management can be exposed as a device driver, then it’s perhaps best to have a device driver. i.e. where is the implementation behind the proposed API? and why is it necessary that it is part of SBI? and what would an extensible firmware interface (i.e. UEFI) look like on top of this? or besides SBI?

Finally, if one has a core with documented hardware interfaces, then one can simply jump into boot loader or OS and devolve the platform into defining and dynamically describing hardware interfaces. i.e. where coreboot would plug in. SBI in that case is replaced by an enclave that the first payload can reserve for its own use (e.g. credential storage), and M-mode function, and virtual environments can make the payload believe that the implementation that appears to be there is real versus virtual (by measuring timing). In this model SBI slowly disappears and is replaced by hardware interfaces that have been virtualized.

Adding PMP interfaces to SBI makes some sort of sense given its capabilities over address space (in my conception of what SBI should do).

But reading M mode CSRs seems to be better handled by mapping them to U mode. i.e. if we all use the U mode aliases to access rdhartid, rdisa, rdarchid, etc, then we don’t have this problem of Supervisors that have to be compiled for a specific privilege level. Make them all U accessible. This is probably because these types of registers are optionally accessible in U mode elsewhere and the provision has already been made for this in the architecture. We have a mechanism to allow us to virtualize their responses as these CSR accesses trap in all modes but M. Thinking about this. Use the U version of those CSRs. This removes the necessity for one register in the boot protocol (although it’s hard to change now because the current protocol it is becoming widespread; not impossibly so; but we could “simplify” this).

And one day the hardware lets U mode read the time stamp counter and a processor id in U mode (e.g. as a dimension in a compute kernel) and there is a bitmask and a per hart id field so that we can control what appears in the currently running virtual context. No need to save it in a register when you are booted, or parse /proc/cpuinfo. This is “use what’s there and be careful what you add i.e. don’t add a redundant interface when one has already been designed into the ISA”.

[Bruce Hoult]

On Mon, Nov 12, 2018 at 5:22 PM, 'Michael Clark' via RISC-V SW Dev <sw-...@groups.riscv.org> wrote:

- Making SBI a library API is an invitation for binary blobs. It should remain an ECALL interface to fill in privilege boundary virtualization gaps i.e. functions that require M-mode privileges. It can’t or shouldn’t do this if it is linked to the kernel as a library. In the case it were a library the question is why not just document the hardware interface and add a driver to the kernel.

I note that there is no reason for an ECALL to be much more heavyweight than a library call. Probably about the same as a shared library call, in fact.

In particular in the case of things such as reading timer registers (and possibly making this atomic for the user, and possibly subtracting an offset to virtualise it) there is NO NEED to wrap it in saving and restoring all 32 registers or nonsense like that.

[Benjamin Herrenschmidt]

On Sat, 2018-11-10 at 19:58 -0800, Atish Patra wrote:
>
> I think the larger picture might have lost somewhere because of the
> verbosity of the proposal. The idea of adding vendor extension support
> in SBI is to allow them provide a standard mechanism to facilitate this.
> In absence of that, vendor might adopt different approaches to support
> their feature leading a lot of chaos. Vendors can not go and add
> anything in the Linux kernel(just a example, SBI is still OS agnostic)
> as well.

The concept of vendor extensions to a userspace ISA is so fundamentally
broken to begin with, this FW proposal verges on utter insanity to be
honest.

Calling FW for things so deeply ingrained in the kernel such as context
swithes, isn't going to fly. The performance will be ridiculously bad,
among other things.

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.

Cheers,
Ben.

[Nick Kossifidis]

Στις 2019-01-28 18:38, Alexander Graf έγραψε:

> 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 <ag...@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

FYI
https://fosdem.org/2019/schedule/event/riscvsbi/

[ron minnich]

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 <ag...@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 <ag...@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.
> >>

[ron minnich]

On Mon, Jan 28, 2019 at 11:55 AM Alexander Graf <ag...@suse.de> wrote:

> You're mixing up 2 things (which is a pretty common fallacy I've come
> across people who worked too much with x86 firmware): Design and
> implementation.

uhm, alex, I worked on or started the coreboot ports to
arm
arm64
ppc
riscv
alpha

I've been working on various non-x86 firmware for over 40 years,
starting in 8 bit days.

You should probably not assume too much about people.

> The conclusion that runtime firmware is a bad idea IMHO is wrong though.

We can agree to disagree. But please don't start by stating things
about my background; you don't know me and you're wrong.

Runtime firmware is acceptable *if and only if* the kernel can measure
it, disable it all or in part, or replace it.
That's a different statement than what you just said. I don't like
runtime firmware, but of course on RISCV there are few options
for some registers. But it is a very rare runtime firmware that is
implemented correctly or even well.

There is one company that is so concerned about M mode they are
implementing a RISCV CPU without it.

> Now, if the firmware development model is so broken but at the same time
> such firmware gives us the ability to abstract interfaces better, what
> is the solution?

you give me the information I need to write a driver. Done. That's
known to work. And for linuxboot systems, that's the only way it
works.That way, we have one driver to deal with, not two. Server
systems that work this way are being deployed today.

> You obviously need to apply the same standards as you do for the OS to
> firmware. It's why open firmware is so important.

Sure. It'd be nice if that worked, but it's essential to ensure it's
the only thing that works. It's important not to enable architecture
features that can be used to make open source firmware
difficult or impossible. PMP is one such feature, since it allows
firmware to lock down regions of memory and make them inaccessible to
the kernel.

In general, however, vendor firmware is extremely poorly written, and
I don't expect that to change.

> But putting everything into Linux instead really is not the answer. The
> only thing it does is break forward compatibility and bloat code size.

I am, today, fitting a linux kernel and full Go userland into about 3M
in SPI. For reference, this is smaller than the audio codec firmware
on some chipsets.

I don't agree with your claim.

That said, RISCV will have the SBI, and there is no getting around it
for certain purposes, but there's no reason to encourage growth.

ron

[ron minnich]

On Mon, Jan 28, 2019 at 12:37 PM Alexander Graf <ag...@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.

I wish it were as easy to install firmware as it is to install a
kernel. That's not
ever going to happen.

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.

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.

> 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--)?

> 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.
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 :-(
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.

> 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 :-)
Looking forward to seeing you at FOSDEM!

ron

[Bruce Hoult]

On Mon, Jan 28, 2019 at 11:40 AM ron minnich <rmin...@gmail.com> wrote:
> 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 disagree.

The owner/user should be able to change the SBI, perhaps by booting
into a special mode. The kernel in a system running normally shouldn't
be able to.

[Paul Miranda]

On Monday, January 28, 2019 at 1:40:51 PM UTC-6, rminnich wrote:

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 don't know enough about the rest of this thread to comment intelligently, but I'm curious what you advocate with respect to PMP?

I believe it has usefulness in allowing M mode code to protect it from itself. Is your only concern that it may be used by ROM code that is not replaceable?

It's definitely not the first protection scheme I've seen that uses lock bits. 

[Samuel Falvo II]

On Mon, Jan 28, 2019 at 7:48 PM Paul Miranda <paulcm...@gmail.com> wrote:
> I don't know enough about the rest of this thread to comment intelligently, but I'm curious what you advocate with respect to PMP?
> I believe it has usefulness in allowing M mode code to protect it from itself. Is your only concern that it may be used by ROM code that is not replaceable?
> It's definitely not the first protection scheme I've seen that uses lock bits.

If I understand Ron's emails correctly, he already indicated his
experience with such systems, and is basing his dislike of PMP
expressly on that experience. It seems history records this feature
being abused rather profusely.

[ron minnich]

The nice thing about riscv is that we can both get what we want here :-)

I can tell you that security-oriented folks I'm working with much
prefer that the kernel be able to measure, selectively disable, or
replace firmware; and then set the PMP registers. The kernel should
drive the security, not firmware, because we have such ample evidence
that firmware is far less secure than kernels, in how it's written,
how it's built, and how it's deployed. In such a world, platforms that
do not allow this will be marked as not trustable.

The good news is that neither you nor I have to to dictate this for
everyone. There are going to be multiple SBI implementations and
firmware implementations for riscv, and we can see where this ends up.
One thing I can say for sure is there won't be just one.

ron

[ron minnich]

On Mon, Jan 28, 2019 at 7:48 PM Paul Miranda <paulcm...@gmail.com> wrote:
>

> I don't know enough about the rest of this thread to comment intelligently, but I'm curious what you advocate with respect to PMP?
> I believe it has usefulness in allowing M mode code to protect it from itself. Is your only concern that it may be used by ROM code that is not replaceable?

The rule is that measures taken by firmware to protect itself tend to
degrade overall security. We have ample evidence of this effect.

If firmware can protect it itself from the kernel, it's already
running at a higher privilege, and the history of firmware security
shows that is a poor practice. The last two years have shown it quite
a bit.
If the kernel wishes to lock down firmware from the kernel there are
already lots of ways to do that.

Sure, we do lockdown bits. That does not mean they're a good idea as
currently practiced.

ron

[ron minnich]

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 <ag...@suse.de> wrote:

>
>
>
> On 28.01.19 23:23, ron minnich wrote:
> > On Mon, Jan 28, 2019 at 12:37 PM Alexander Graf <ag...@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

[Palmer Dabbelt]

Right now nobody with a Linux-capable RISC-V core has vendor-specific stateful
extensions. The plan is to avoid implementing any of this and convince people
to avoid building them, but since the ISA allows for these we do need an out.
I'd prefer this to forcing people to fork the kernel.

[Palmer Dabbelt]

Yep, and the hope here is that we can build something that allows everyone to implement their systems within the same framework.  With any luck we'll be able to build a platform specification that allows both of these systems to exist -- essentially "boot Linux into M-mode" or "boot Linux into S-mode".  It'll be work to make sure the spec can work for everyone, but that's part of the way to get a good spec.

 

 

ron

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAP6exYJD0Qrnni%2ByCUBdNWv0tmR%3D3vYzLwJTy%2BoOnQEb83ja1g%40mail.gmail.com.

[ron minnich]

btw, w.r.t. carrying sbi with the kernel image.

When you get to a big enough world, and you get enough machines,
updating flash to update firmware runtime services is not guaranteed
to end well.
Flash just isn't that great and the less you depend on it the better.

So the idea of being able to fix an SBI problem by kexec'ing a kernel
that carries its own SBI is a very attractive idea. Anything that
reduces the role of persistent memory
for startup is a very attractive idea.

And this is why I believe an M mode that is changeable by the kernel
is a feature, not a bug: it let us do something we could not do
before.

That doesn't mean it is for every possible use; but the fact that you
can do it is great. You can't do that stuff on x86, for example, and
it's been a problem for 25 years now.
This is why I find riscv so attractive, it can free us from old thinking.

On Tue, Jan 29, 2019 at 4:06 PM Luke Kenneth Casson Leighton
<lk...@lkcl.net> wrote:
>
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>

> On Tue, Jan 29, 2019 at 11:26 PM Palmer Dabbelt <pal...@sifive.com> wrote:
>
> > Yep, and the hope here is that we can build something that allows everyone to implement their systems within the same framework. With any luck we'll be able to build a platform specification that allows both of these systems to exist -- essentially "boot Linux into M-mode" or "boot Linux into S-mode". It'll be work to make sure the spec can work for everyone, but that's part of the way to get a good spec.
>

> ... and how is that to be achieved if the RISC-V Foundation
> pathologically insists on secretive closed-doors discussions when it
> comes to RISC-V specifications?
>
> it's time for the RISC-V Foundation to recognise that the ITU-style
> closed doors practice is damaging the ecosystem by preventing people
> from contributing.
>
> l.

[Bruce Hoult]

On Tue, Jan 29, 2019 at 4:06 PM Luke Kenneth Casson Leighton
<lk...@lkcl.net> wrote:
>
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>

> On Tue, Jan 29, 2019 at 11:26 PM Palmer Dabbelt <pal...@sifive.com> wrote:
>

> > Yep, and the hope here is that we can build something that allows everyone to implement their systems within the same framework. With any luck we'll be able to build a platform specification that allows both of these systems to exist -- essentially "boot Linux into M-mode" or "boot Linux into S-mode". It'll be work to make sure the spec can work for everyone, but that's part of the way to get a good spec.
>

> ... and how is that to be achieved if the RISC-V Foundation
> pathologically insists on secretive closed-doors discussions when it
> comes to RISC-V specifications?
>
> it's time for the RISC-V Foundation to recognise that the ITU-style
> closed doors practice is damaging the ecosystem by preventing people
> from contributing.

There needs to be some slight barrier to entry, some commitment
needed, otherwise the process has a real danger of simply being
flooded by concern-trolls and time-wasters and never completing.
Designing things by discussion and consensus rather than simply having
a completed spec handed down from some expert is already
time-consuming enough.

[Benjamin Herrenschmidt]

On Mon, 2019-01-28 at 11:40 -0800, ron minnich wrote:

.../...

(snip a very well written description of issues I fully agree with)

> 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.

IMHO, something like SBI has value when seen from the perspective of
providing a thin abstraction enabling existing OS binaries to run on
newer/different systems *as a fallback*. This should be done with the
clear intent and guidance that ultimately, the OS is meant to grow
native handling for those cases and platforms.

Cheers,
Ben.

[Luís Marques]

On Tue, Feb 5, 2019 at 10:30 PM Benjamin Herrenschmidt
<be...@kernel.crashing.org> wrote:
> IMHO, something like SBI has value when seen from the perspective of
> providing a thin abstraction enabling existing OS binaries to run on
> newer/different systems *as a fallback*. This should be done with the
> clear intent and guidance that ultimately, the OS is meant to grow
> native handling for those cases and platforms.

I like the idea of it being a fallback (and thus something that can be
replaced or complemented at runtime by the kernel, or even be absent
when the kernel has full knowledge of the exact hardware details).
That also meshes well with the goal of it being a fairly minimal
abstraction. It's not clear to me that the current design path will
take us there, unless this becomes a well reiterated goal, and the
implementation decision are made in alignment with that goal.

[ron minnich]

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

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.

I think we should consider the OpenSBI in its current state a starting
point for figuring out what we need to do.

[Paul Walmsley]

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

[Anup Patel]

(Sorry for spamming, my previous reply got rejected by googlegroups).

On Thu, Feb 7, 2019 at 9:26 AM Paul Walmsley <paul.w...@sifive.com> wrote:
>
> 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

I would like to clarify that reference firmwares provided by OpenSBI
only provide RUNTIME services (i.e. handle SBI calls and M-mode traps)
so they are not early boot firmware.

The OpenSBI reference firmwares are not suitable to be used as ROM
firmware (e.g. ZSBL) or LOADER (e.g. FSBL) firmware. They are only
RUNTIME firmwares designed to replace BBL.

Further, it is not mandatory to use OpenSBI reference firmwares as-is
and HW vendors can simply create their own RUNTIME firmware (
probably link it o OpenSBI library).

Regards,
Anup