Re: Smepmp discovery

Anup Patel

(Adding other platform HSC folks)

On 03/08/21, 10:10 PM, "Nick Kossifidis" <mick@...> wrote:

Στις 2021-07-27 10:16, Andrew Waterman έγραψε:
> Although I'm not dead set against this proposal, I'm a little skeptical
> that this is something that needs to be dynamically discovered by early
> boot code. In practice, the early boot code is quite tailored to the
> system it's running on--after all, it's often baked into the same
> chip--and so the early boot code will be statically compiled to assume
> that Smepmp is (or isn't) implemented. If that assumption turns out to
> be incorrect, there would seem to be much bigger problems afoot--it's
> hard to believe in the security of a system whose early boot code makes
> incorrect assumptions about what ISA it's running on.
> With that said, if you can make an argument for dynamic discovery that
> isn't in conflict with the above observation, I agree with you that
> adding a hardwired bit to mseccfg indicating the presence of Smepmp is
> a reasonable way to go.

(ccing Anup/Atish)

Good point, BootROM is hw-specific and doesn't need to rely on any
discovery mechanism, but the first stage boot loader like OpenSBI or
u-boot-spl, or the secure monitor, may be more generic / hw-agnostic.
For example it's possible to run the same OpenSBI image on multiple
platforms (the "generic" target) based on a provided device-tree image
at runtime, and I assume the new configuration data structure will be
used in a similar way.

I'm worried of the scenario where an attacker will manage to tamper with
the configuration data structure and remove Smepmp from the available
extensions, in which case sw will fallback to PMP (without being able to
provide the mitigations Smepmp introduces) and/or a less-secure
configuration in general since the same can happen with other
security-related extensions in the future. So if we are about to make
security decisions based on that data structure, we need to verify its
integrity/authenticity. However the fsbl may run with very limited
resources to do signature checking of the configuration data structure /
device-tree, or it may need Smepmp to do the signature verification to
begin with (run the verification inside an isolated environment on
M-mode) depending on the system's security requirements.

Another issue is that the new discovery mechanism may not be available,
in which case it won't be possible to discover the existence of Smepmp
and we can only handle this at compile-time as you suggest. Currently
it's possible for sw to discover the existence of PMP and the number of
available PMP entries without having to go through the new discovery
method, which so far has been useful for sw developers.

It seems like we have the following options:

a) Resolve this at compile-time and ignore any discovery mechanism
regarding Smepmp, which would e.g. require another "generic-epmp" target
on OpenSBI.
b) Require that BootROM uses Smepmp (e.g. sets MMWP which makes perfect
sense) in which case the fsbl can then read mseccfg and verify Smepmp's
existence without adding a dependency to the new discovery mechanism.
c) Add this hard-wired bit (which btw as Allen suggested it should be >=
bit12) on mseccfg to indicate that Smepmp is implemented.

My preference is b but I thought c would be simpler which is why I
suggested it.

@Anup/@Atish, any thoughts on this ?

In this context, it is very important to re-visit the generic booting flow
for rich-OS capable SoCs (across architectures):

BootROM => Loader => Runtime => Bootloader => RichOS
(M-mode) (M-mode) (M-mode) (S-mode) (S-mode)

From the above, FPGAs, QEMU, Spike, and other emulators tend to
skip "BootROM", "Loader", and "Bootloader" stages whereas rich-OS
capable SoCs will usually have all above booting stages.

BootROM - This is vendor/SoC specific firmware which is the first
thing to run on system boot-up. It runs from on-chip ROM or Flash
and does all the SoC specific initialization (such as configuring PLLs,
configuring power rails, reading securing keys, authenticating/loading
loader from boot device, etc).
(For example, ZSBL firmware of SiFive SoCs)

Loader - This is also vendor/SoC specific firmware which is the second
stage on system boot-up. It is loaded in on-chip SRAM by the BootROM.
It's primary job is to setup DRAM/DDR and authenticate/load other
booting stages onto DRAM/DDR.
(For example, FSBL OR U-Boot SPL firmware of SiFive SoCs)

Runtime - This may or may not be vendor/SoC specific firmware. Usually,
it is OpenSBI runtime firmware. It provides SBI services and other runtime
services (such as emulating missing CSRs, emulating misaligned load/store,
system level-partitioning, etc).

Bootloader - This may or may not be vendor/SoC specific. Usually, it is
U-Boot (S-mode) or EDK2 or some other rich open-source bootloader.
It will have rich filesystem support and will provide various booting
Methods (e.g. network booting, eMMC booting, etc).

RichOS - This will mostly be vendor independent generic OS (such as
Linux, FreeBSD, etc). Most generic OSes will provide single kernel
image which boots on multiple platforms and will use DT or ACPI
for detecting system configuration.

Coming back to OpenSBI (M-mode runtime firmware), at the moment
it detects optional HART features using traps and ad-hoc CSRs writes
because on FPGAs/emulators there is no previous booting stage which
can pass this info via DT. Other system level devices (such as PLIC,
CLINT, ACLINT, IMSCI, APLIC, etc) are discovered and probed based
on DT.

For security sensitive features (like Smepmp), the preferred approach
would be that OpenSBI detect it without relying on any HW configuration
so that previous booting stage can't lie about it. This way we continue
to use same OpenSBI firmware across RISC-V platforms. Other HART
features can be discovered by OpenSBI using ad-hoc method,
unified HW discovery, or DT.

Based on above, the option (c) is certainly a preferred approach
to detect Smepmp on OpenSBI.


Join to automatically receive all group messages.