Public review for Scalar Cryptography extensions

[Stephano Cetola]

Forwarding this email on from our Crypto TG Chair.

Cheers,

Stephano

--

We are delighted to announce the start of the public review period for the following proposed standard extensions to the RISC-V ISA:
 
Zknd - NIST Suite: AES Decryption
Zkne - NIST Suite: AES Encryption
Zknh - NIST Suite: Hash Function Instructions
Zksed - ShangMi Suite: SM4 Block Cipher Instructions
Zksh - ShangMi Suite: SM3 Hash Function Instructions
Zkr - Entropy Source Extension
Zkn - NIST Algorithm Suite (shorthand for Zknd_Zkne_Zknh_Zbkb_Zbkc_Zbkx)
Zks - ShangMi Algorithm Suite  (shorthand for Zksed_Zksh_Zbkb_Zbkc_Zbkx)
Zk - Standard scalar cryptography extension (shorthand for Zkn_Zkt_Zkr)
Zkt - Data Independent Execution Latency
Zbkb - Bitmanip instructions for Cryptography
Zbkc - Carry-less multiply instructions
Zbkx - Crossbar permutation instructions
 
The review period begins today, Thursday Sept 2, 2021, and ends on Sunday October 17, 2021 (inclusive).
 
These extensions are described in the PDF spec available at:
 
https://github.com/riscv/riscv-crypto/releases/tag/v1.0.0-rc2-scalar

(or  https://github.com/riscv/riscv-crypto/releases for the latest)
 
which was generated from the source available in the following GitHub repo:
 
https://github.com/riscv/riscv-crypto

 
This specification has been developed by the RISC-V Cryptography Extensions Task Group under the governance of the Unprivileged and the Security Committees.
 
To respond to the public review, please either email comments to the public isa-dev mailing list or add issues and/or pull requests (PRs) to the Crypto GitHub repo: https://github.com/riscv/riscv-crypto. We welcome all input and appreciate your time and effort in helping us by reviewing the specification.
 
During the public review period, corrections, comments, and suggestions, will be gathered for review by the Cryptography task group. Any minor corrections and/or uncontroversial changes will be incorporated into the specification. Any remaining issues or proposed changes will be addressed in the public review summary report. If there are no issues that require incompatible changes to the public review specification, the unprivileged ISA committee will recommend the updated specifications be approved and ratified by the RISC-V Technical Steering Committee and the RISC-V Board of Directors.
 
Thanks to all the contributors for all their hard work.
 
Richard Newell
Chair, Cryptography Extensions Task Group

G. Richard Newell
Associate Technical Fellow

Microchip Technology Inc

richard...@microchip.com

[John Hauser]

I have some concerns about the proposed extension Zkr, Entropy Source
Extension, which is a part of the Scalar Cryptography extensions,
described in _RISC-V Cryptography Extensions Volume I: Scalar & Entropy
Source Instructions_.

The first is a minor point:  Section 4.1 says "seed is a user mode
CSR".  In fact, seed should be labeled as an _unprivileged_ CSR, not
user-mode.  The difference is that the seed CSR may exist even if
U mode isn't implemented.

The more significant issues involve Section 4.3, "Access Control to
seed".

The mseccfg bits sseed and useed that grant access to CSR seed from
S and U modes must not grant access also from VS and VU modes.  The
simplest fix is to always prohibit access from VS and VU modes.  If
desired, a hypervisor can emulate accesses to the seed CSR from a
virtual machine.

When a trap occurs due to an attempt to access seed from VS or
VU mode, the specific exception should depend on the type of access
and the value of the sseed bit of mseccfg.  If the attempted access
is read-only (never allowed), an illegal instruction exception must be
raised.  Else, following the rules for virtual instruction exceptions
laid down by the hypervisor extension, if mseccfg.sseed = 1, a virtual
instruction exception should be raised, and if mseccfg.sseed = 0, an
illegal instruction exception should be raised.

Lastly, HS mode is described as an "additional mode", but it really
should be thought of as an expansion of S mode, not a new mode.

Regards,

    - John Hauser

[Markku-Juhani O. Saarinen]

On Sat, Oct 16, 2021 at 1:41 AM John Hauser <jhause...@gmail.com> wrote:

I have some concerns about the proposed extension Zkr, Entropy Source
Extension, which is a part of the Scalar Cryptography extensions,
described in _RISC-V Cryptography Extensions Volume I: Scalar & Entropy
Source Instructions_.

Hi John,

Thanks for the further review! I personally think that your suggestions make sense.

I've itemized the proposed changes below as :

- JH-R1: (Non-func.) Terminology, user mode -> unprivileged (Sect. 4.1),

- JH-R2: (Functional) Entropy source is never available in VS/VU (Sect 4.3 and parts of Appendix B).

- JH-R3: (Functional) Use of "virtual instruction exception" to implement [JH-R2] for VS/VU (Table in Sect 4.3).

- JH-R4: (Non-func.) Terminology, related to HS mode (Sect. 4.3)

The first is a minor point:  Section 4.1 says "seed is a user mode
CSR".  In fact, seed should be labeled as an _unprivileged_ CSR, not
user-mode.  The difference is that the seed CSR may exist even if
U mode isn't implemented.

[JH-R1] Change of wording to unprivileged; makes sense to me. As noted elsewhere, "seed" can definitely be available also in simple systems that implement M-mode only.

 

The more significant issues involve Section 4.3, "Access Control to
seed".

The mseccfg bits sseed and useed that grant access to CSR seed from
S and U modes must not grant access also from VS and VU modes.  The
simplest fix is to always prohibit access from VS and VU modes.  If
desired, a hypervisor can emulate accesses to the seed CSR from a
virtual machine.

[JH-R2] Denial of access from VS and VU modes; makes sense to me. The ("virtual source") emulation is specifically appropriate for VS and VU modes and - due to security concerns - and we can always prevent direct access.

My rationale: In my (admittedly limited) hypervisor understanding the VS and VU modes are generally less trusted. Direct access to the entropy source implies the ability to deny it to others (depletion), along with other effects, as discussed in (non-normative) Appendix B.3.5. The S-mode access is intended only for "simple" systems for performance reasons; e.g. single-instance Linux-like system where the system kernel can can be trusted for this purpose.

When a trap occurs due to an attempt to access seed from VS or
VU mode, the specific exception should depend on the type of access
and the value of the sseed bit of mseccfg.  If the attempted access
is read-only (never allowed), an illegal instruction exception must be
raised.  Else, following the rules for virtual instruction exceptions
laid down by the hypervisor extension, if mseccfg.sseed = 1, a virtual
instruction exception should be raised, and if mseccfg.sseed = 0, an
illegal instruction exception should be raised.

[JH-R3]   Modifying the table to include "virtual instruction exception" for VS and VU modes in the cases where access would currently be granted; this seems like a sensible way to implement [JH-R2] and I can imagine that it makes exception handling easier. (I will read up on "virtual instruction exception" to have the correct references.)

Lastly, HS mode is described as an "additional mode", but it really
should be thought of as an expansion of S mode, not a new mode.

[JH-R4]  I'm sure you're right. We can change the language appropriately.

Cheers,

- markku

Dr. Markku-Juhani O. Saarinen <mj...@pqshield.com> PQShield, Oxford UK.

[Markku-Juhani O. Saarinen]

On Sat, Oct 16, 2021 at 1:41 AM John Hauser <jhause...@gmail.com> wrote:

 

When a trap occurs due to an attempt to access seed from VS or
VU mode, the specific exception should depend on the type of access
and the value of the sseed bit of mseccfg.  If the attempted access
is read-only (never allowed), an illegal instruction exception must be
raised.  Else, following the rules for virtual instruction exceptions
laid down by the hypervisor extension, if mseccfg.sseed = 1, a virtual
instruction exception should be raised, and if mseccfg.sseed = 0, an
illegal instruction exception should be raised.

Hi John,

It has been noted ( https://github.com/riscv/riscv-crypto/issues/139 ) that the crypto specification currently actually states a slightly different thing than this e-mail. The main difference is what kind of an exception to raise for "potentially legal" read-write in VS/VU mode (there will always be an exception).

It seems that the rationale for the proposed emulation of entropy sources via illegal instruction exception rather than virtual instruction exception (mseccfg.seed=0) was based on the interpretation of "HS-qualified" but I'm not sure if that's a good idea here. This is a CSR that is almost always emulated if invoked in VS/VU, regardless of the host configuration. In practice the original proposal would lead to a situation where the m-mode/hypervisor would need to perform emulation via either the illegal instruction exception or virtual instruction exception, depending on the current state of the global mseccfg.sseed (which is literally a "kernel/system configuration" matter). According to notes in Section 5.6 of privileged specification, the handling of these exceptions is substantially different, and illegal instruction handling can be expected to be notably complex/slower.

So.. the currently specified behavior is that the exception type in VS/VU is not dependant on mssecfg.sseed (or mseccfg.useed) global flags. In VS/VU an illegal read causes an illegal instruction exception, while a read-write (an action that may be a legal and common operation in some virtual systems) always causes a virtual instruction exception. The virtual instruction exception handler can then make the determination if it is indeed an illegal instruction in that instance. I hope this is okay, given what the entropy source actually does, and that emulation is the expected handling path for it.

[John Hauser]

Markku-Juhani O. Saarinen wrote:
> It has been noted
> ( https://github.com/riscv/riscv-crypto/issues/139 ) that the crypto
> specification currently actually states a slightly different thing
> than this e-mail. The main difference is what kind of an exception to
> raise for "potentially legal" read-write in VS/VU mode (there will
> always be an exception).
>
> It seems that the rationale for the proposed emulation of
> entropy sources via illegal instruction exception rather than
> virtual instruction exception (mseccfg.seed=0) was based on the
> interpretation of "HS-qualified" but I'm not sure if that's a good
> idea here. This is a CSR that is almost always emulated if invoked in
> VS/VU, regardless of the host configuration. In practice the original
> proposal would lead to a situation where the m-mode/hypervisor
> would need to perform emulation via either the illegal instruction
> exception or virtual instruction exception, depending on the current
> state of the global mseccfg.sseed (which is literally a "kernel/
> system configuration" matter). According to notes in Section 5.6
> of privileged specification, the handling of these exceptions is
> substantially different, and illegal instruction handling can be
> expected to be notably complex/slower.

Markku,

How common are we expecting mseccfg.sseed to be zero?

Clearly, if mseccfg.sseed were normally = 1, then the exception raised
when VS mode attempts to access the seed CSR would normally be a
virtual instruction exception, and we'd have little reason to be
bothered about the reduced performance of illegal instruction traps
in this case.

So let's assume mseccfg.sseed = 0 will be common.  If that's true, then
I claim you've made a mistake in your assumptions.  Because extension
Zkr defines the seed CSR, you are assuming that having M level emulate
this CSR for S mode (HS mode) is the obvious and proper way to provide
an OS with entropy bits when mseccfg.sseed = 0.  In fact, it is usually
best to avoid emulating instructions when a simple SBI call (ECALL) can
achieve the same purpose.  Here, I see nothing preventing the creation
of an SBI function to return entropy bits to an OS, and this solution
would altogether have better performance than emulating the seed CSR
for S mode.

If we can assume such an SBI function exists, then I would expect a
guest OS running in a virtual machine (VS mode) also to invoke this
function in most circumstances, obviating any concerns about the
difference in performance between illegal and virtual instruction
traps.

    - John Hauser

[Markku-Juhani O. Saarinen]

Markku-Juhani O. Saarinen wrote:

> It has been noted
> ( https://github.com/riscv/riscv-crypto/issues/139 ) that the crypto
> specification currently actually states a slightly different thing
> than this e-mail. The main difference is what kind of an exception to
> raise for "potentially legal" read-write in VS/VU mode (there will
> always be an exception).

(..) 

On Sat, Nov 6, 2021 at 3:52 PM John Hauser <jhause...@gmail.com> wrote:

How common are we expecting mseccfg.sseed to be zero?

John,

Sorry about the overlong reply; "It depends". Below are my personal expectations; the purpose of the configuration register is to allow system designers freedom in this respect. And they may surprise all of us... RISC-V is a general-purpose architecture.

From a security perspective, the right setting depends on whether or not S mode -- in a given (physical) application with some given operating system and security goals -- can be trusted to access this hardware resource directly. The main issues we've been worried about are covert channels, resource depletion, and unique host identification -- but there may be others.

Not all physical entropy sources are alike; some may require more careful protection than others. For example, Intel decided to build a relatively large circuitry for their RDSEED entropy source so that it can be made available with the equivalent of mseccfg.useed=1 permissions; however, it is still somewhat vulnerable to some of those attacks. Simpler, low-bandwidth (and non-"full entropy", with much lower power and area requirements) entropy sources in the style of ARM TrustZone TRNG should never be given untrusted user-mode access. I personally think that the latter type makes more sense "quantitatively" since even high-performance cryptography does not require that much entropy to seed DRBGs. So mseccfg.useed=0 generally.

Anyway, given the Linux security model, I'd generally assume useed=0, sseed=1 on "simple" systems that have a single, trusted kernel (e.g., common Linux running in an appliance SoC, for example -- unlikely to need hypervisor extensions either). The configuration may also change mid-flight (during boot, for example).

For cloud servers, hosts doing sandboxing, etc., one would be more concerned about those covert channels, etc., and perhaps set sseed=0, and perform emulation/virtualization instead. Note that one might still want to spin up a guest system in a sandbox that "thinks" that sseed=1 while the host actually has sseed=0. I certainly hope that the hypervisor extension can facilitate this.

Wrt sandboxing; note that if we make the behavior dependant on the host "sseed" configuration, we're unnecessarily telling a VS/VU mode entity something about the host physical configuration; either directly or via execution latency. I don't like the implied mixing of the state of the virtual guest and the host configuration.

I've been told that there are potential use cases for useed=1,sseed=0 too; I'm not sure if I fully understand the motivations, but it's up to system designers to make sure that they are doing the right thing for their system. Note that these bits control access to the entropy source only and the security implications are more limited than with general S and U mode access.

A RISC-V chip with Zkr may also choose to hardwire both useed=0 and sseed=0 to zero if it doesn't support this access control feature (modifying the configuration) and provides the CSR in M-mode only.

 

So let's assume mseccfg.sseed = 0 will be common.  If that's true, then
I claim you've made a mistake in your assumptions.  Because extension
Zkr defines the seed CSR, you are assuming that having M level emulate
this CSR for S mode (HS mode) is the obvious and proper way to provide
an OS with entropy bits when mseccfg.sseed = 0. 

It may not be the best way to provide access, but M mode is the only way to emulate the availability of an S-mode entropy source on a host that has sseed=0. So this would be referring to the sandboxing concerns etc.

 

I guess this is a security person in me talking; I'm automatically assuming that the guest/enclave/entity in VS/VU mode is not going to play along and will try to DoS the host or something :)

If we can assume such an SBI function exists, then I would expect a
guest OS running in a virtual machine (VS mode) also to invoke this
function in most circumstances, obviating any concerns about the
difference in performance between illegal and virtual instruction
traps.

If we could assume that, then we could have the entropy source to be M-mode only. We added the S-mode support in order for (Linux) kernels to be able to access the entropy source directly and created virtual entropy sources to facilitate emulation. An SBI function is not emulation.

In any case, I think making the VS/VU exception type dependant on the host mseccfg.sseed setting would seem to lead to more. not less, complicated hypervisor implementation (necessitating emulation via M-mode, perhaps not frequently, but still).

I still can't see many advantages in making the behavior of VS/VU dependant on global mseccfg.sseed. Again, note that "sseed" and "useed" only affect access to this particular resource, which already has its own access control rules independent of other things that happen with S and U modes. The access control rules to the CSR are also different. Making it always invoke a virtual instruction exception when hit with a read-write from SV/VU modes would seem easy enough to implement in hardware.

I am also left wondering about the interpretation of mseccfg.useed in case "sseed" is not virtualized. If VS/VU are set to just invoke a virtual instruction exception, "useed" handling is as easy.

[John Hauser]

> Sorry about the overlong reply;

Back at you.  :^)

> Wrt sandboxing; note that if we make the behavior dependant on the
> host "sseed" configuration, we're unnecessarily telling a VS/VU mode
> entity something about the host physical configuration; either
> directly or via execution latency. I don't like the implied mixing of
> the state of the virtual guest and the host configuration.

I understand, but we need to be realistic.  (There's also a purist
information-leakage reason not to raise virtual instruction exceptions
when mseccfg.sseed = 0, which I get to later.)

According to what I've been told, for performance reasons it's
standard practice to run most guest virtual machines at least
partly "paravirtualized", which means the guest knows, somewhere in
its software, that it's inside a guest environment.  It's true that
we've tried to make the RISC-V hypervisor hardware capable of truly
virtualizing a wide range of machines so the guest doesn't easily know.
But we should not imagine this is the typical use case.  The vast
majority of folks who care about the performance of their guests run
them every day in paravirtualized environments, and thus regularly mix
"the state of the virtual guest and the host configuration", as you
say.

> I guess this is a security person in me talking; I'm automatically
> assuming that the guest/enclave/entity in VS/VU mode is not going to
> play along and will try to DoS the host or something :)

You mean, by deviously making SBI calls instead of executing CSR
accesses to seed that get trapped and emulated?  What's the difference
for security?  Why should we assume SBI call are less secure?

> > If we can assume such an SBI function exists, then I would expect a
> > guest OS running in a virtual machine (VS mode) also to invoke this
> > function in most circumstances, obviating any concerns about the
> > difference in performance between illegal and virtual instruction
> > traps.
>
> If we could assume that, then we could have the entropy source to be
> M-mode only.

I don't follow that statement exactly.  The reason we support giving
S-mode direct access to CSR seed is to improve the speed for S mode,
not because we're incapable of inventing an SBI function for passing
entropy down to the OS.

> We added the S-mode support in order for (Linux) kernels
> to be able to access the entropy source directly and created virtual
> entropy sources to facilitate emulation. An SBI function is not
> emulation.

But why should I care that an SBI function isn't emulation?  I think
we're back to what I said before:  It sounds like you're assuming that
because we _can_ emulate accesses to the seed CSR to provide entropy
bits, we _must_ emulate accesses to the seed CSR to provide entropy
bits.  I strongly disagree.

If the argument is supposed to be that perfect security dictates that
guests not learn they're running in a virtual machine, that argument
appears to me to be deflated by the reality that guests are almost
always handed this knowledge in practice.

> In any case, I think making the VS/VU exception type dependant on
> the host mseccfg.sseed setting would seem to lead to more. not less,
> complicated hypervisor implementation (necessitating emulation via
> M-mode, perhaps not frequently, but still).

Emulation in M mode is not how it would work when mseccfg.sseed = 0.
Rather, the illegal instruction trap handler at M level would notice
that the exception occurred in VS/VU mode and would then delegate the
exception to HS mode, by software.  If M level is emulating CSR seed
for HS mode, the exception delegated to HS mode would be a virtual
instruction exception; else it would be an illegal instruction
exception.  The real handling of the exception for VS/VU mode would be
done by the hypervisor in HS mode as usual.

But this all presupposes both that mseccfg.sseed = 0 and that we told
the guest OS the seed CSR is implemented for it to use.  In almost all
cases, what really should happen instead is the hypervisor tells the
guest OS that seed isn't available to it (which is the truth), so the
guest may make more efficient SBI calls directly to the hypervisor.

> I still can't see many advantages in making the behavior of VS/VU

> dependant on global mseccfg.sseed.  [...]

The main reason for insisting that we always raise an illegal
instruction exception when mseccfg.sseed = 0 is to address the
situation where M level leaves mseccfg.sseed = 0 and _doesn't_ emulate
the seed CSR for HS mode, instead telling the OS that Zkr isn't
implemented.  HS mode isn't supposed to see virtual instruction
exceptions from VS/VU mode for features that aren't even implemented
for HS mode.  Ironically, given the thread of this conversation,
raising a virtual instruction exception in this circumstance risks
leaking to the OS the tiny bit of information that M level is lying
to it about Zkr.  And although I've insisted that most users dismiss
these tiny leakages as insignificant, nevertheless we've tried to be
consistent and avoid it in hardware for those who may care.

For readers who detect an inconsistency in my position, note this
difference:  In one case it's the hardware leaking the information
(to be avoided); in the other, the small leakage occurs due to choices
freely made by users and their software (allowed, and common for
performance reasons, as I've said).

> I am also left wondering about the interpretation of mseccfg.useed
> in case "sseed" is not virtualized. If VS/VU are set to just invoke
> a virtual instruction exception, "useed" handling is as easy.

I don't understand this paragraph.  There's no intersection between
the setting of mseccfg.useed, which affects only U mode (not VU mode),
and whether the exception raised from VS/VU mode should be the illegal
instruction or virtual instruction exception.

Regards,

    - John Hauser

[Greg Favor]

On Sat, Nov 6, 2021 at 5:42 PM John Hauser <jhause...@gmail.com> wrote:

But this all presupposes both that mseccfg.sseed = 0 and that we told

the guest OS the seed CSR is implemented for it to use.  In almost all
cases, what really should happen instead is the hypervisor tells the
guest OS that seed isn't available to it (which is the truth), so the
guest may make more efficient SBI calls directly to the hypervisor.

Just a not-so-highly-informed peanut gallery comment:  This seems to imply that an OS needs to support two code paths - either access the CSR or make an SBI call.  Versus one code path (access the CSR) and either direct hardware access is allowed or a transparent trap-and-emulate occurs (albeit at greater expense than an SBI call).  I don't offer an opinion as to which is the better compromise.

Btw, if there is an expectation that there will be SBI support for making 'seed' requests (i.e. an API call), then the Crypto TG needs to talk with the SBI guys and initiate creation of an SBI "Entropy Source" extension to provide this support.  SBI currently has no such support and I'm not aware of any intention to add such support (since the SBI guys are unaware of this potential need).  Unless this happens (and details worked out) very quickly, I suspect this is going to miss the current SBI ratification cycle.  (Which is not the end of the world, and maybe is appropriate so that QEMU support and the OpenSBI implementation of SBI can be put in place and tested before ratification of this new SBI extension.)

Greg

[Markku-Juhani O. Saarinen]

Hi,

Since this is not really really a cryptologic issue, but one related to the implementation of hypervisors, it is ultimately for the privileged chair, arc here h committee, etc to decide among themselves. I'm going to just address it from my perspective (of a cryptographer) here and will expect them to issue a recommendation on this. Given the deadlines, I'd prefer this to happen very soon.

From a practical viewpoint (as someone who is helping to introduce this support in the operating systems and middleware, e.g. Linux and OpenSSL), the proposed change affects cryptographic software in a way I really don't like, in practice necessitating it to behave differently "in virtual setting" and in a "real box" (as noted by Greg below). The assumptions made with this proposal make the entropy source CSR generally less useful and may have a negative security impact that way.

To recap (you'll find all the original text in this thread if I misinterpreted something), we have two options for behavior in case of read-write access to the "seed" CSR for virtual modes VS and VU (an illegal access will always be an illegal instruction exception).

a) Behavior is that in virtual (VS/VU) modes is that a virtual instruction exception is raised. This is the text in the current cryptography specification.

b)  However, specifically in VS mode, if the host has mseccfg.sseed=0 setting, then an illegal instruction exception is raised, and if the host has sseed=1, a virtual exception is raised. John has not stated what he wants to happen in VU mode in relation to mseccfg.useed (which type of exception he wants to happen).

The latter requires/assumes that a brand new SBI extension to be defined, that two methods of accessing the CSR are defined effectively in all guest operating systems and/or midleware. It further assumes that paravirtualization is used instead of actual virtualization,  "According to what I've been told, for performance reasons it's standard practice to run most guest virtual machines at least partly "paravirtualized","

The main motivation given was: "The main reason for insisting that we always raise an illegal instruction exception when mseccfg.sseed = 0 is to address the situation where M level leaves mseccfg.sseed = 0 and _doesn't_ emulate the seed CSR for HS mode, instead telling the OS that Zkr isn't implemented. HS mode isn't supposed to see virtual instruction exceptions from VS/VU mode for features that aren't even implemented for HS mode. "

I'm really no hypervisor expect, but I don't see wh the hypervisor mode can't treat unknown virtual instruction exceptions as illegal when it sees them (after all the guest system was told that Zkr isn't implemented). Also, those virtual instruction exceptions would still be coming in from the VU mode if the guest wants them to happen, right? Or are all of those illegal?

Cheers,

- markku

Dr. Markku-Juhani O. Saarinen <mj...@pqshield.com> PQShield, Oxford UK.

[Andrew Waterman]

On Sun, Nov 7, 2021 at 1:20 AM Markku-Juhani O. Saarinen <mj...@pqshield.com> wrote:

Hi,

Since this is not really really a cryptologic issue, but one related to the implementation of hypervisors, it is ultimately for the privileged chair, arc here h committee, etc to decide among themselves. I'm going to just address it from my perspective (of a cryptographer) here and will expect them to issue a recommendation on this. Given the deadlines, I'd prefer this to happen very soon.

From a practical viewpoint (as someone who is helping to introduce this support in the operating systems and middleware, e.g. Linux and OpenSSL), the proposed change affects cryptographic software in a way I really don't like, in practice necessitating it to behave differently "in virtual setting" and in a "real box" (as noted by Greg below). The assumptions made with this proposal make the entropy source CSR generally less useful and may have a negative security impact that way.

Just to be clear, there's no "necessitation" here.  Y'all are indirectly tussling over the para- vs. full-virtualization debate.  Naturally, software will end up having to support both virtualization regimes: e.g., guests will directly access the CSR, and hypervisors will emulate the access, even if it would've been somewhat faster to execute the SBI call instead.  So, there will be no functional need for an OS to support both.  (There might be a perf motivation to support both code paths, but let's not put the cart before the horse here...)

To recap (you'll find all the original text in this thread if I misinterpreted something), we have two options for behavior in case of read-write access to the "seed" CSR for virtual modes VS and VU (an illegal access will always be an illegal instruction exception).

a) Behavior is that in virtual (VS/VU) modes is that a virtual instruction exception is raised. This is the text in the current cryptography specification.

b)  However, specifically in VS mode, if the host has mseccfg.sseed=0 setting, then an illegal instruction exception is raised, and if the host has sseed=1, a virtual exception is raised. John has not stated what he wants to happen in VU mode in relation to mseccfg.useed (which type of exception he wants to happen).

The latter requires/assumes that a brand new SBI extension to be defined, that two methods of accessing the CSR are defined effectively in all guest operating systems and/or midleware. It further assumes that paravirtualization is used instead of actual virtualization,  "According to what I've been told, for performance reasons it's standard practice to run most guest virtual machines at least partly "paravirtualized","

The main motivation given was: "The main reason for insisting that we always raise an illegal instruction exception when mseccfg.sseed = 0 is to address the situation where M level leaves mseccfg.sseed = 0 and _doesn't_ emulate the seed CSR for HS mode, instead telling the OS that Zkr isn't implemented. HS mode isn't supposed to see virtual instruction exceptions from VS/VU mode for features that aren't even implemented for HS mode. "

I'm really no hypervisor expect, but I don't see wh the hypervisor mode can't treat unknown virtual instruction exceptions as illegal when it sees them (after all the guest system was told that Zkr isn't implemented). Also, those virtual instruction exceptions would still be coming in from the VU mode if the guest wants them to happen, right? Or are all of those illegal?

Cheers,

- markku

Dr. Markku-Juhani O. Saarinen <mj...@pqshield.com> PQShield, Oxford UK.

On Sun, Nov 7, 2021 at 1:13 AM Greg Favor <gfa...@ventanamicro.com> wrote:

On Sat, Nov 6, 2021 at 5:42 PM John Hauser <jhause...@gmail.com> wrote:

But this all presupposes both that mseccfg.sseed = 0 and that we told

the guest OS the seed CSR is implemented for it to use.  In almost all
cases, what really should happen instead is the hypervisor tells the
guest OS that seed isn't available to it (which is the truth), so the
guest may make more efficient SBI calls directly to the hypervisor.

Just a not-so-highly-informed peanut gallery comment:  This seems to imply that an OS needs to support two code paths - either access the CSR or make an SBI call.  Versus one code path (access the CSR) and either direct hardware access is allowed or a transparent trap-and-emulate occurs (albeit at greater expense than an SBI call).  I don't offer an opinion as to which is the better compromise.

Btw, if there is an expectation that there will be SBI support for making 'seed' requests (i.e. an API call), then the Crypto TG needs to talk with the SBI guys and initiate creation of an SBI "Entropy Source" extension to provide this support.  SBI currently has no such support and I'm not aware of any intention to add such support (since the SBI guys are unaware of this potential need).  Unless this happens (and details worked out) very quickly, I suspect this is going to miss the current SBI ratification cycle.  (Which is not the end of the world, and maybe is appropriate so that QEMU support and the OpenSBI implementation of SBI can be put in place and tested before ratification of this new SBI extension.)

Greg

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAPwdP4M5j-ReyXFTcjGv%3D10%3DG10CK5SwSQjBsNxYgGdRADEJDg%40mail.gmail.com.

[James Kenney]

Can I request that any clarification here also explicitly states whether the value of mseccfg.useed has any effect on the exception generated by a VU access.

Thanks,

James.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CA%2B%2B6G0DRu_qC2N3VZSOxGz830054pVQkkJnXHLgjWL8nS%3DvtoA%40mail.gmail.com.

[John Hauser]

Markku wrote:
> Since this is not really really a cryptologic issue, but one
> related to the implementation of hypervisors, it is ultimately for
> the privileged chair, arc here h committee, etc to decide among

> themselves.  [...]

The Architecture Review Committee discussed this topic, and the
consensus is that the hypervisor extension's usual rules should prevail
in determining whether attempts to access seed from VS and VU modes
raise an illegal instruction or virtual instruction exception.

As we understand it, the intended goal of deviating from the usual
rules is to improve machine performance in the specific circumstance
when:  (a) mseccfg.sseed = 0; (b) a hypervisor emulates accesses to
seed for a guest OS; and (c) the guest OS accesses seed often enough
that the difference in handling speed between an illegal instruction
exception and a virtual instruction exception is significant.

If it proves to be the case that OSes frequently need new entropy
bits yet the OS is commonly denied direct access to seed because
mseccfg.sseed = 0, then the AR Committee believes performance will be
better served by defining an SBI function to supply new entropy bits to
the caller, rather than relying on emulating accesses to the seed CSR.
If such an SBI function exists and OSes use it, then the circumstance
that justifies deviating from the usual rules should be rare in
practice.  On the other hand, if such an SBI function does not exist,
because OSes typically are given direct access to seed (mseccfg.sseed
usually = 1) and/or because OSes don't attempt to access seed often
enough that the speed of emulating those accesses matters, then again
the circumstance that justifies deviating from the usual rules should
be rare in practice.

> From a practical viewpoint (as someone who is helping to introduce
> this support in the operating systems and middleware, e.g. Linux
> and OpenSSL), the proposed change affects cryptographic software in
> a way I really don't like, in practice necessitating it to behave
> differently "in virtual setting" and in a "real box" (as noted by
> Greg below). The assumptions made with this proposal make the entropy
> source CSR generally less useful and may have a negative security
> impact that way.

The AR committee expects and intends that if mseccfg.sseed = 0 and
the SBI function is defined, the execution environment should normally
tell the OS that seed isn't implemented but the SBI function is
provided, regardless of whether the OS is running in a "virtual
setting" or in a "real box".  Hence it is not our intention that OSes
would call the SBI function only in the case that they're running as
a guest.  Main/host OSes running in S/HS mode could also benefit from
this same SBI function when mseccfg.sseed = 0.

> [...] It further assumes that paravirtualization is used instead of
> actual virtualization,

Not necessarily, per above.  It depends on what environment the guest
needs to see.

> I'm really no hypervisor expect, but I don't see wh the hypervisor
> mode can't treat unknown virtual instruction exceptions as illegal
> when it sees them (after all the guest system was told that Zkr isn't
> implemented).

The issue concerns whether the _hypervisor_ is told that Zkr is
implemented.  When Zkr really isn't implemented, all attempts to
access seed will only raise illegal instruction exceptions.  Hence,
if the hypervisor is told by the execution environment that Zkr isn't
implemented (with mseccfg.sseed = 0) and it sets up an experiment to
access seed in VS mode and gets a virtual instruction exception in
response, the hypervisor can see that Zkr does exist for M mode.

> Also, those virtual instruction exceptions would still be coming in
> from the VU mode if the guest wants them to happen, right? Or are all
> of those illegal?

Again, I don't understand what you mean.  The only thing the guest has
control over here is whether it executes in VU mode instructions that
attempt to access seed.  Is that what you mean by "the guest wants them
to happen"?

    - John Hauser

[John Hauser]

James wrote:
> Can I request that any clarification here also explicitly states
> whether the value of mseccfg.useed has any effect on the exception
> generated by a VU access.

The value of mseccfg.useed has no effect on the exception generated by
a VU access.

    - John Hauser

[Markku-Juhani O. Saarinen]

Many Thanks John!

It was really the confusion over the role of mseccfg.useed that caused me to want to lump together both VS/VU as a virtual instruction exception when I was trying to implement your change request. ( Recall that the actual public review version had VS and VU with the same access control as U and S -- thanks for catching that. It would have been a security problem. )

I've attached a screenshot of the relevant table with these changes. If I didn't get it right, or if my English is awful again, perhaps just comment on the PR so I can amend it directly: https://github.com/riscv/riscv-crypto/pull/141

[John Hauser]

Markku-Juhani O. Saarinen wrote:
> I've attached a screenshot of the relevant table with these changes.
> If I didn't get it right, or if my English is awful again, perhaps
> just comment on the PR so I can amend it directly:
> https://github.com/riscv/riscv-crypto/pull/141

What you have now looks correct to me.

Thanks for making the corrections.

    - John Hauser