Secure boot incur cost, either in hardware or boot-up time. Besides, it only guarantees the initial state of the next stage is known good state, nothing is said about the runtime behavior of the next

It's also worth noting that ePMP may not be representative of most security-related extensions with regards to needing early discovery. For example, Scalar Crypto will leverage the new RV discovery

IT is already expected that msseccfg will be used for other security related features - I think it is mentioned in the spec. The overall question is whether discovery is needed at all, or can we

Extrapolating from the discussion on Smepmp discovery, it is reaonable to expect that in the future any security feature will potentially run into the same issue, that is, any data structure is not

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

(Adding other platform HSC folks) On 03/08/21, 10:10 PM, "Nick Kossifidis" <mick@...> wrote: Στις 2021-07-27 10:16, Andrew Waterman έγραψε: (ccing Anup/Atish) Good

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

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

what do other architectures do? -------- sent from a mobile device. please forgive any typos.

Στις 2021-07-27 10:16, Andrew Waterman έγραψε: (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

Resending from correct email address Begin forwarded message: From: krste@... Subject: Re: [RISC-V] [tech-privileged] RISC-V H-extension freeze consideration Date: August 1, 2021 at 1:41:10 PM

Generally it seems like the early boot code needs to have a built in understanding of the initial resources and initial address map that it has to work with (starting with a small amount of RAM

It’s a cheap, effective solution. But I think Andrew’s question is whether a solution is needed. If the early boot code knows what hardware it’s running on, it doesn’t need the information.

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

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

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

Re-posting from a smaller audience sub-thread on this issue: The current naming intent (in contrast to what was written a long time ago) is: Extensions that only extend the machine-level architecture

It's the latter option: the chapter needs to be updated to reflect the new naming convention.

Section 25.7 of the unprivileged spec says that standard supervisor-level ISA extensions are named using S as a prefix. Section 25.9 says that standard machine-level ISA extensions are named using

The current uses of the work "pointer" in the Priv architecture are wrt the *scratch CSRs and non-leaf PTEs. All other CSRs that can hold address values, possibly along with other fields, have names