Στις 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 ?

Regards,
Nick