Smepmp discovery


Nick Kossifidis
 

Hello all,

When we initially defined mseccfg as part of Smepmp we specified that the existence of that CSR would also mean that ePMP (at least MML and MMWP) is implemented. Obviously since other security extensions will also use mseccfg (that was the idea from the start, to have one CSR that anyone can use for security-related stuff), that approach is not optimal since it will add a dependency on Smepmp to every security extension (such as the Scalar Crypto that will also use mseccfg for enabling/disabling S-mode access to the TRNG). For that reason I changed the spec a bit to allow mseccfg to exist even when PMP is not available as long as Scalar Crypto is available (or any other extension that 'll use it in the future), with the only requirement that the bits used by Smepmp should remain reserved if not implemented (there are still some non-functional improvements to be made to the spec https://raw.githubusercontent.com/riscv/riscv-tee/main/Smepmp/Smepmp.pdf but are off topic).

So now we are in a situation where there is no way to figure out from mseccfg if Smepmp is implemented, MML and MMWP are locked when set and RLB may be hardwired to 0 (and may also be locked to 0), so none of them can be used for testing if the extension is implemented. The new general discovery mechanism is a software-based mechanism and for now we have nothing related to its security guarantees, so we can't rely on it at this point for ensuring the availability of Smepmp. Even if we do have guarantees regarding the data structure's integrity/authenticity, Smepmp is a security mechanism that may be used very early in the boot process where decoding the data structure and verifying its integrity/authenticity may not be possible (e.g. not enough memory at that point), it may be used on a very constrained environment (recall the discussions we had at some point on secure boot and how expensive asymmetric crypto is for systems with power/resources/boot time constraints), and may be needed in order to verify the integrity/authenticity of the discovery mechanism in the first place, depending on the vendor's security requirements (so there is a possible circular dependency there, Smepmp may be needed to check for Smepmp via the software-based mechanism).

Would it be ok if we just add a bit on mseccfg (bit3) to indicate that Smepmp (MML, MMWP and optionally RLB) is implemented ?

Regards,
Nick


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.

On Mon, Jul 26, 2021 at 7:22 PM Nick Kossifidis <mick@...> wrote:
Hello all,

When we initially defined mseccfg as part of Smepmp we specified that
the existence of that CSR would also mean that ePMP (at least MML and
MMWP) is implemented. Obviously since other security extensions will
also use mseccfg (that was the idea from the start, to have one CSR that
anyone can use for security-related stuff), that approach is not optimal
since it will add a dependency on Smepmp to every security extension
(such as the Scalar Crypto that will also use mseccfg for
enabling/disabling S-mode access to the TRNG). For that reason I changed
the spec a bit to allow mseccfg to exist even when PMP is not available
as long as Scalar Crypto is available (or any other extension that 'll
use it in the future), with the only requirement that the bits used by
Smepmp should remain reserved if not implemented (there are still some
non-functional improvements to be made to the spec
https://raw.githubusercontent.com/riscv/riscv-tee/main/Smepmp/Smepmp.pdf
but are off topic).

So now we are in a situation where there is no way to figure out from
mseccfg if Smepmp is implemented, MML and MMWP are locked when set and
RLB may be hardwired to 0 (and may also be locked to 0), so none of them
can be used for testing if the extension is implemented. The new general
discovery mechanism is a software-based mechanism and for now we have
nothing related to its security guarantees, so we can't rely on it at
this point for ensuring the availability of Smepmp. Even if we do have
guarantees regarding the data structure's integrity/authenticity, Smepmp
is a security mechanism that may be used very early in the boot process
where decoding the data structure and verifying its
integrity/authenticity may not be possible (e.g. not enough memory at
that point), it may be used on a very constrained environment (recall
the discussions we had at some point on secure boot and how expensive
asymmetric crypto is for systems with power/resources/boot time
constraints), and may be needed in order to verify the
integrity/authenticity of the discovery mechanism in the first place,
depending on the vendor's security requirements (so there is a possible
circular dependency there, Smepmp may be needed to check for Smepmp via
the software-based mechanism).

Would it be ok if we just add a bit on mseccfg (bit3) to indicate that
Smepmp (MML, MMWP and optionally RLB) is implemented ?

Regards,
Nick


Allen Baum
 

To be brief: you need a way to determine whether Smepmp exists without accessing anything in memory or by writing a CSR.
It is acceptable that reading a CSR traps, (which indicates that Smepmp is not implemented), 
but if it doesn't, a read-only bit indicates whether Smepmp is implemented or not.

Sounds like a cheap, effective solution


On Mon, Jul 26, 2021 at 7:22 PM Nick Kossifidis <mick@...> wrote:
Hello all,

When we initially defined mseccfg as part of Smepmp we specified that
the existence of that CSR would also mean that ePMP (at least MML and
MMWP) is implemented. Obviously since other security extensions will
also use mseccfg (that was the idea from the start, to have one CSR that
anyone can use for security-related stuff), that approach is not optimal
since it will add a dependency on Smepmp to every security extension
(such as the Scalar Crypto that will also use mseccfg for
enabling/disabling S-mode access to the TRNG). For that reason I changed
the spec a bit to allow mseccfg to exist even when PMP is not available
as long as Scalar Crypto is available (or any other extension that 'll
use it in the future), with the only requirement that the bits used by
Smepmp should remain reserved if not implemented (there are still some
non-functional improvements to be made to the spec
https://raw.githubusercontent.com/riscv/riscv-tee/main/Smepmp/Smepmp.pdf
but are off topic).

So now we are in a situation where there is no way to figure out from
mseccfg if Smepmp is implemented, MML and MMWP are locked when set and
RLB may be hardwired to 0 (and may also be locked to 0), so none of them
can be used for testing if the extension is implemented. The new general
discovery mechanism is a software-based mechanism and for now we have
nothing related to its security guarantees, so we can't rely on it at
this point for ensuring the availability of Smepmp. Even if we do have
guarantees regarding the data structure's integrity/authenticity, Smepmp
is a security mechanism that may be used very early in the boot process
where decoding the data structure and verifying its
integrity/authenticity may not be possible (e.g. not enough memory at
that point), it may be used on a very constrained environment (recall
the discussions we had at some point on secure boot and how expensive
asymmetric crypto is for systems with power/resources/boot time
constraints), and may be needed in order to verify the
integrity/authenticity of the discovery mechanism in the first place,
depending on the vendor's security requirements (so there is a possible
circular dependency there, Smepmp may be needed to check for Smepmp via
the software-based mechanism).

Would it be ok if we just add a bit on mseccfg (bit3) to indicate that
Smepmp (MML, MMWP and optionally RLB) is implemented ?

Regards,
Nick






Nick Kossifidis
 

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


mark
 

what do other architectures do?

--------
sent from a mobile device. please forgive any typos.

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





Andrew Waterman
 



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

If later-boot software like OpenSBI wants to dynamically detect this feature to change its behavior at runtime, and we can't trust the configuration structure, but we can trust the mseccfg CSR, then this is a logical argument.  The second premise seems flimsy, though, because other aspects of the boot process will depend on the veracity of the information in the configuration structure for functional correctness, and hence security.

(The "discovery mechanism may not be available" argument doesn't hold water, since relevant profiles can require its existence, and nonconforming systems can refuse to boot.)


Regards,
Nick


Bill Huffman
 

 

 

From: tech-privileged@... <tech-privileged@...> On Behalf Of Andrew Waterman
Sent: Tuesday, August 3, 2021 5:41 PM
To: Nick Kossifidis <mick@...>
Cc: Anup Patel <anup.patel@...>; atishp@...; Tech Tee <tech-tee@...>; tech-privileged@...; Krste Asanovic <krste@...>
Subject: Re: [RISC-V] [tech-privileged] Smepmp discovery

 

EXTERNAL MAIL

 

 

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

 

If later-boot software like OpenSBI wants to dynamically detect this feature to change its behavior at runtime, and we can't trust the configuration structure, but we can trust the mseccfg CSR, then this is a logical argument.  The second premise seems flimsy, though, because other aspects of the boot process will depend on the veracity of the information in the configuration structure for functional correctness, and hence security.

 

I think the issue here is that we want to be able to use the ePMP as part of the chain of trust for the configuration structure.

 

(The "discovery mechanism may not be available" argument doesn't hold water, since relevant profiles can require its existence, and nonconforming systems can refuse to boot.)

 

There will certainly be small systems that don’t have the discovery mechanism.  Whether such systems need any help discovering the ePMP is more doubtful because most (all?) of such systems will do a) above – resolve at compile time.

 

     Bill

 


Regards,
Nick


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.

Regards,
Anup


Anup Patel
 

Generic booting flow on ARM for rich-OS capable SoC looks
like this:

BootROM => Loader => Runtime => Bootloader => RichOS
(EL3) (EL1S) (EL3) (EL2 or EL1NS) (EL2 or EL1NS)
(ATF BL1) (ATF BL2) (ATF BL31) (U-Boot or EDK2) (Linux or FreeBSD or others)

Regards,
Anup

On 03/08/21, 10:16 PM, "tech-privileged@... on behalf of mark" <tech-privileged@... on behalf of markhimelstein@...> wrote:

what do other architectures do?

--------
sent from a mobile device. please forgive any typos.

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


Andrew Waterman
 



On Tue, Aug 3, 2021 at 9:40 AM 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.

Greg and I have concluded that this option is the best compromise.

Just as a clarification, we'll point out that "Require that BootROM uses Smepmp" might be taken out of context.  Of course, we aren't requiring that all boot ROMs use Smepmp; we're stating that some boot ROMs will simply assume that Smepmp exist and proceed accordingly.

Further, later-boot software like OpenSBI has no need to use an early-discovery mechanism, since early-boot software will already have set up the feature (or otherwise will have asserted its presence).

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