Complete Consumption Requirement

[andreiw]

...a few thoughts.

Being able to detect that there were unknown features is half the battle. The other problem is ensuring that features unknown to a particular OS (or OS version) are safely disabled or controlled.

It might be trivial enough to prevent a situation where an application writes something to some new register, and the OS leaks that to another application because it doesn't know anything about swapping this state. You could force all optional extensions to be disabled at OS boot, but what about a new Linux kernel kexec'ing an older Linux kernel? What would ensure that all unsupported features are disabled at the time of loading the older Linux kernel?

What about exposing unknown features in hypervisors? Think old hypervisor booting a new enough guest. That should be doable, so long as the hypervisor knows what CPU state to switch (which may work for some extensions like some new set of DSP instructions, but won't be doable if the extension is a new bit in PTE...)

Perhaps there could be a way to describe "kill bits" so that an OS kernel can disable anything it doesn't know about.

[radimkrcmar]

Being able to detect that there were unknown features is half the battle. The other problem is ensuring that features unknown to a particular OS (or OS version) are safely disabled or controlled.

ISA extensions are designed in a way to achieve this by default.

Some features can't be controlled, which is a problem for virtualization, but UD cannot help.

Linux kernel kexec'ing an older Linux kernel? What would ensure that all unsupported features are disabled at the time of loading the older Linux kernel?

The kexec'ing Linux.

Perhaps there could be a way to describe "kill bits" so that an OS kernel can disable anything it doesn't know about.

Yes, we could even define UEFI-style services that do it on request, but I don't think it is needed in RISC-V as all stateful extensions should be disabled by default.

[allenjbaum]

I don't think it is the case that stateful extensions are disabled as a default, but maybe I don't understand your usage of stateful. The spec sec. 3.4 says: The misa register is reset to enable the maximal set of supported extensions, as described in Section 3.1.1. The F & D extensions are stateful, and must be enabled at reset, so that contradicts your statement (depending on how you're defining a stateful extension) Of course, this says nothing about extensions that aren't controlled by misa, but I haven't seen anything that says they are disabled by default, unless the extension definition requires it.

…

On Fri, Mar 21, 2025 at 7:17 AM Radim Krčmář ***@***.***> wrote: Being able to detect that there were unknown features is half the battle. The other problem is ensuring that features unknown to a particular OS (or OS version) are safely disabled or controlled. ISA extensions are designed in a way to achieve this by default. Some features can't be controlled, which is a problem for virtualization, but UD cannot help. Linux kernel kexec'ing an older Linux kernel? What would ensure that all unsupported features are disabled at the time of loading the older Linux kernel? The kexec'ing Linux. Perhaps there could be a way to describe "kill bits" so that an OS kernel can disable anything it doesn't know about. Yes, we could even define UEFI-style services that do it on request, but I don't think it is needed in RISC-V as all stateful extensions should be disabled by default. — Reply to this email directly, view it on GitHub <#128 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJWNOHEEHMRXADS7CMD2VQNOFAVCNFSM6AAAAABPZSCF6SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONBTGUYDKMRTHE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> [image: radimkrcmar]*radimkrcmar* left a comment (riscvarchive/configuration-structure#128) <#128 (comment)> Being able to detect that there were unknown features is half the battle. The other problem is ensuring that features unknown to a particular OS (or OS version) are safely disabled or controlled. ISA extensions are designed in a way to achieve this by default. Some features can't be controlled, which is a problem for virtualization, but UD cannot help. Linux kernel kexec'ing an older Linux kernel? What would ensure that all unsupported features are disabled at the time of loading the older Linux kernel? The kexec'ing Linux. Perhaps there could be a way to describe "kill bits" so that an OS kernel can disable anything it doesn't know about. Yes, we could even define UEFI-style services that do it on request, but I don't think it is needed in RISC-V as all stateful extensions should be disabled by default. — Reply to this email directly, view it on GitHub <#128 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJWNOHEEHMRXADS7CMD2VQNOFAVCNFSM6AAAAABPZSCF6SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONBTGUYDKMRTHE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[radimkrcmar]

We probably mean the same "stateful", but I meant less strict "disabled". I consider mstatus.FS=OFF as disabled F&D, because U-mode software won't be able to access the F&D state.
(The initial assumption is that M-mode and S-mode are oblivious to F&D and therefore won't touch mstatus.FS nor misa.F&D.)

I think that instead of adding UD nodes that tell M-mode to set mstatus.FS to OFF, it would be better if the mechanism that provides UD could just set mstatus.FS to OFF instead.
Similarly with VS and *stateen. The ISA extensions are well designed for this.

[allenjbaum]

Unless the spec specifies what the value of a state bit should be (which it does in the reset chapter), the value at reset is undefined.

Smode is NOT oblivious to F&D; it is responsible for saving and restoring the state (including sstatus.fs) so it has to know if F&D are present, and when it is, what the .fs field values are.

[radimkrcmar]

Unless the spec specifies what the value of a state bit should be (which it does in the reset chapter), the value at reset is undefined.

Yes, initialization of the remaining state is the responsibility of non-isa specifications.

Smode is NOT oblivious to F&D; it is responsible for saving and restoring the state (including sstatus.fs) so it has to know if F&D are present, and when it is, what the .fs field values are.

Right, sorry, continuing the illustration with F&D was bad call on my part, because sstatus.FS was present in the first ratified RISC-V spec.

It would have been better to talk about a stateful extension that is disabled through sstateen or some other future mechanism. S-mode is oblivious to stateful extensions that will be ratified after the software is written.

Back to the initial assumption:

The other problem is ensuring that features unknown to a particular OS (or OS version) are safely disabled or controlled.

I think this is out-of-scope for UD. The BRS or some other spec should mandate their disablement.
OS shouldn't try to accidentally enable features that it doesn't know about.

Proposing kill-bits in UD means that same as saying the M-mode software can be oblivious to some ISA extensions and therefore won't disable them for less privileged modes.
I don't see the point of complicating UD to achieve this.

[allenjbaum]

Let's be clear we are talking about a custom extensions. (There is a whole other discussion about whether we test custom or standard extensions that aren't "declared" by a vendor. e.g. Vector extension v.71 has been implemented in existing chips, but doesn't meet the ratified standard. That means it is custom, by definition, and almost all the opcodes will work. The question becomes how or if that custom extension is discoverable: via misa, or by a test parameter. If misa.V is set at reset, we can safely assume the ratified spec is implemented. If boot code can't turn it off: that's a bug.) There is no architectural requirement that any extension *not controlled by misa* is enabled or disabled at reset. Custom extensions could be enabled at reset... or not. Expecting a kill-bit is custom behavior, and means that UD is documenting a custom extension. I would agree this is out of scope for OSs and apps, and that's OK. OSs/toolchains/apps won't know about these extensions and won't try to exercise them. Mmode firmware is private to an implementation, and certainly could disable or use a custom extension, but anything that RVI uses to test/certify a vendor implementation won't. If a reset value changes the behavior of a standard extension -- that's different, and there are two approaches: - call it a bug - ensure that boot code disables it (implying BRS mandates it, which I would agree with) The ACTs do allow a custom boot routine to run before running tests; that a black box that UD doesn't have to know about. That doesn't mean that UD can't describe those things. The artifacts that UD will cause to be built (Device trees, ACPI tables, etc) could have that information, but (standard) toolchains, OSes and apps won't know how to use that information, so it will be safely ignored.

…

On Tue, Mar 25, 2025 at 3:29 AM Radim Krčmář ***@***.***> wrote: Unless the spec specifies what the value of a state bit should be (which it does in the reset chapter), the value at reset is undefined. Yes, initialization of the remaining state is the responsibility of non-isa specifications. Smode is NOT oblivious to F&D; it is responsible for saving and restoring the state (including sstatus.fs) so it has to know if F&D are present, and when it is, what the .fs field values are. Right, sorry, continuing the illustration with F&D was bad call on my part, because sstatus.FS was present in the first ratified RISC-V spec. It would have been better to talk about a stateful extension that is disabled through sstateen or some other future mechanism. S-mode is oblivious to stateful extensions that will be ratified after the software is written. Back to the initial assumption: The other problem is ensuring that features unknown to a particular OS (or OS version) are safely disabled or controlled. I think this is out-of-scope for UD. The BRS or some other spec should mandate their disablement. OS shouldn't try to accidentally enable features that it doesn't know about. Proposing kill-bits in UD means that same as saying the M-mode software can be oblivious to some ISA extensions and therefore won't disable them for less privileged modes. I don't see the point of complicating UD to achieve this. — Reply to this email directly, view it on GitHub <#128 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJQAPPW4GA4HMZK4NFL2WEOXRAVCNFSM6AAAAABPZSCF6SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONJQG44TOMZXHA> . You are receiving this because you commented.Message ID: ***@***.***> [image: radimkrcmar]*radimkrcmar* left a comment (riscvarchive/configuration-structure#128) <#128 (comment)> Unless the spec specifies what the value of a state bit should be (which it does in the reset chapter), the value at reset is undefined. Yes, initialization of the remaining state is the responsibility of non-isa specifications. Smode is NOT oblivious to F&D; it is responsible for saving and restoring the state (including sstatus.fs) so it has to know if F&D are present, and when it is, what the .fs field values are. Right, sorry, continuing the illustration with F&D was bad call on my part, because sstatus.FS was present in the first ratified RISC-V spec. It would have been better to talk about a stateful extension that is disabled through sstateen or some other future mechanism. S-mode is oblivious to stateful extensions that will be ratified after the software is written. Back to the initial assumption: The other problem is ensuring that features unknown to a particular OS (or OS version) are safely disabled or controlled. I think this is out-of-scope for UD. The BRS or some other spec should mandate their disablement. OS shouldn't try to accidentally enable features that it doesn't know about. Proposing kill-bits in UD means that same as saying the M-mode software can be oblivious to some ISA extensions and therefore won't disable them for less privileged modes. I don't see the point of complicating UD to achieve this. — Reply to this email directly, view it on GitHub <#128 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJQAPPW4GA4HMZK4NFL2WEOXRAVCNFSM6AAAAABPZSCF6SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONJQG44TOMZXHA> . You are receiving this because you commented.Message ID: ***@***.***>

[radimkrcmar]

Let's be clear we are talking about a custom extensions.

I was also considering standard extensions. e.g. HS-mode software written with the first ratified spec does not know about *stateen, so the CSRs should be in a safe state when M-mode hands execution over to HS-mode on platforms that implement stateful extensions that can be disabled with *stateen.

Mmode firmware is private to an implementation, and certainly could disable or use a custom extension, but anything that RVI uses to test/certify a vendor implementation won't.

Does RVI certify non-ISA specifications as well?
The ISA can be implemented perfectly, but the whole platform can still be unsafe, because it will default to ones in *stateen.

OSs/toolchains/apps won't know about these extensions and won't try to exercise them.

It is a security issue if two U-mode or Vx-mode programs could use a stateful extension that S-mode or HS-mode doesn't properly context switch as it does know about it. The platform should be responsible for booting (H)S-mode in a state where the isolation breach cannot happen.

I agree, UD definitely can describe the kill-bits, I just don't think the UD kill-bits are to address the initial concerns.

Any secure RISC-V platform should always boot in a state that doesn't need the UD kill-bits.
We are now in CVE territory and CVEs wouldn't look good on RISC-V, even if the CVE was caused because VS-mode software depended on an unspecified behavior by mistake.
A RISC-V platform could have easily prevented the CVE by an initial state that triggered an illegal instruction trap instead.

[allenjbaum]

It's a good question as to whether RVI does, or will, certify non-ISA extensions. I believe they will. What they won't certify is the software or firmware that a vendor writes. That's the vendor's job. If Mmode firmware has the information and ability to configure the system correctly - and doesn't - RVI doesn't have a problem, the vendor does. An implementation that has the ability to set a default correctly, and doesn't use it, is a perfectly valid RVI implementation -- with buggy SW or buggy firmware. RVI is not responsible for a vendor's bugs. Mmode firmware is written knowing the capabilities of the system; that's one of the reasons to have Mmode firmware, and bootloaders, etc. Mmode firmware is responsible for booting the system in a secure manner. Portable Mmode firmware can and will be written (e.g. SBI calls), but that doesn't absolve Mmode for configuring the system to a state that the portable firmware expects. But,

…

On Wed, Mar 26, 2025 at 12:05 AM Radim Krčmář ***@***.***> wrote: Let's be clear we are talking about a custom extensions. I was also considering standard extensions. e.g. HS-mode software written with the first ratified spec <https://github.com/riscv/riscv-isa-manual/releases/download/Priv-v1.12/riscv-privileged-20211203.pdf> does not know about *stateen, so the CSRs should be in a safe state when M-mode hands execution over to HS-mode on platforms that implement stateful extensions that can be disabled with *stateen. Mmode firmware is private to an implementation, and certainly could disable or use a custom extension, but anything that RVI uses to test/certify a vendor implementation won't. Does RVI certify non-ISA specifications as well? The ISA can be implemented perfectly, but the whole platform can still be unsafe, because it will default to ones in *stateen. OSs/toolchains/apps won't know about these extensions and won't try to exercise them. It is a security issue if two U-mode or Vx-mode programs could use a stateful extension that S-mode or HS-mode doesn't properly context switch as it does know about it. The platform should be responsible for booting (H)S-mode in a state where the isolation breach cannot happen. I agree, UD definitely can describe the kill-bits, I just don't think the UD kill-bits are to address the initial concerns. Any secure RISC-V platform should always boot in a state that doesn't need the UD kill-bits. We are now in CVE territory and CVEs wouldn't look good on RISC-V, even if the CVE was caused because VS-mode software depended on an unspecified behavior by mistake. A RISC-V platform could have easily prevented the CVE by an initial state that triggered an illegal instruction trap instead. — Reply to this email directly, view it on GitHub <#128 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJUJTRMQSO5346ZPILT2WI7SXAVCNFSM6AAAAABPZSCF6SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONJTGQZDCNBRHA> . You are receiving this because you commented.Message ID: ***@***.***> [image: radimkrcmar]*radimkrcmar* left a comment (riscvarchive/configuration-structure#128) <#128 (comment)> Let's be clear we are talking about a custom extensions. I was also considering standard extensions. e.g. HS-mode software written with the first ratified spec <https://github.com/riscv/riscv-isa-manual/releases/download/Priv-v1.12/riscv-privileged-20211203.pdf> does not know about *stateen, so the CSRs should be in a safe state when M-mode hands execution over to HS-mode on platforms that implement stateful extensions that can be disabled with *stateen. Mmode firmware is private to an implementation, and certainly could disable or use a custom extension, but anything that RVI uses to test/certify a vendor implementation won't. Does RVI certify non-ISA specifications as well? The ISA can be implemented perfectly, but the whole platform can still be unsafe, because it will default to ones in *stateen. OSs/toolchains/apps won't know about these extensions and won't try to exercise them. It is a security issue if two U-mode or Vx-mode programs could use a stateful extension that S-mode or HS-mode doesn't properly context switch as it does know about it. The platform should be responsible for booting (H)S-mode in a state where the isolation breach cannot happen. I agree, UD definitely can describe the kill-bits, I just don't think the UD kill-bits are to address the initial concerns. Any secure RISC-V platform should always boot in a state that doesn't need the UD kill-bits. We are now in CVE territory and CVEs wouldn't look good on RISC-V, even if the CVE was caused because VS-mode software depended on an unspecified behavior by mistake. A RISC-V platform could have easily prevented the CVE by an initial state that triggered an illegal instruction trap instead. — Reply to this email directly, view it on GitHub <#128 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJUJTRMQSO5346ZPILT2WI7SXAVCNFSM6AAAAABPZSCF6SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONJTGQZDCNBRHA> . You are receiving this because you commented.Message ID: ***@***.***>