On Aug 3, 2021, at 4:40 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 ?

Regards,
Nick