I think there’s a need for several items:
1. A secured RISC-V needs a security state machine. The state should be reliably available to all levels, so the software can behave responsibly. S levels and above need a way to report a breach. I think the state machine should be application-dependent, except maybe the sign bit is clear for insecure states (or something).
2. If RISC-V adds significant security features, over time it’s likely to grow into an entire security module, feature-by-feature, maybe in H-level BMIs. I’d hide the whole thing now, behind a single BMI call with a function code to select APIs. Make the upper half of function codes application-defined. The bottom half can be standardized, RFU for now. Maybe make function code 0 the way to test if a function code is implemented. Or something.
3. The debug unit needs some standard form of lightweight, firmware-controlled security. If it is controlled by firmware, then it can integrate with any security system, and adding passwords, challenge-response and crypto security is possible, maybe without turning the spec, IP or (possibly) silicon. An exact scheme would be something like: reset disabled to prevent reset-timing attacks, then enable automatically after some number of instructions (e.g. 4096), unless the firmware configures debug to be disabled. I think it should have the option to have the firmware disable it until the next reset (prevents software breaches), or disable it until enabled (permits complex debug authorization).
4. The RISC-V privileged register set desperately needs a software watchdog. (It’s transcendentally weird to see a NMI without a watchdog.) It’s useful for security, safety, reliability and EMI recovery. For security because it can set the security interval. I think the default time should be about 1.5 seconds. I think the choice of starting enabled or disabled should be by a trim, because applications have legitimately different requirements. (All of my applications at work need to start with a watchdog enabled.)
5. I think secure boots should be simple (banks and government need them), and insecure operation should be possible (a civil right), with reliable notification of the insecurity (e.g. by a security-state inquiry), so secured apps can run responsibly.
6. Affordable (cheap) IoT RISC-V CPUs running out of (slow) flash are going to be slow at running intensive things like ECC authentications. A standardized crypto coprocessor interface in the BMI would be helpful. At this stage, an RFU would be enough. Any preexisting coprocessor interface is fine, BTW.
7. Hardware random-number-generators are useful for small slow systems. They don’t have access to much entropy. A standardized BMI or even a register would be helpful. Cheap ones tend to be nondeterministic, so a data-ready interrupt is truly helpful.
--
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 post to this group, send email to isa...@groups.riscv.org.
Visit this group at
https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit
https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAFkuX4uFVDfYnFM5i06-QF-Dc8-XN07RvpcCmFLOUdDov68nAA%40mail.gmail.com.
--
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+unsubscribe@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAG7hfcLUJiCjCHHNq9Wf4EX%2Bf09sd6hVEMUgVGVRaTskU%2B4XYg%40mail.gmail.com.
Doesn't it seem obvious that to have an understandable software standard for a new platform it's not OK to allow anyone to make any changes they want and still call it RISC-V?
Dave
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAG7hfcLUJiCjCHHNq9Wf4EX%2Bf09sd6hVEMUgVGVRaTskU%2B4XYg%40mail.gmail.com.
--
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+unsubscribe@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAHis7pn81R1GwP6CanVRWd2%2B3yABNMUNCR4Pfan24APkTeeOoA%40mail.gmail.com.
On Sun, Apr 29, 2018 at 6:22 AM, David PATTERSON <pat...@cs.berkeley.edu> wrote:Doesn't it seem obvious that to have an understandable software standard for a new platform it's not OK to allow anyone to make any changes they want and still call it RISC-V?Indeed, we're entering a time now where RISC-V is starting to mature, with many different players adopting it.. and this may be the most vulnerable time of all for the success of RISC-V. If conformance testing is not effective and the trademark not well defended, we could easily end up with a variety of divergent devices that are incompatible. They all claim to be RISC-V but small variations mean a binary that runs on one will not run on the others. That will either have to be corrected by aggressive legal action, or RISC-V may very well wither on the vine. Can action be taken now to stave off this kind of divergence from taking root?For example, can the Foundation be given more teeth, and become more active in developing a clear, definitive, easier to use conformance system, and participate more in partnering with companies doing RISC-V chips, to help them maintain compliance? Make them more pro-active. Advertise them as the keepers of compliance. Make the Foundation a well known one-stop shop for all things compliance?It would be sad for there to be an achilles heel, and divergent implementations seems the most likely and credible achilles heel for RISC-V.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAHis7pn81R1GwP6CanVRWd2%2B3yABNMUNCR4Pfan24APkTeeOoA%40mail.gmail.com.
--
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+unsubscribe@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAJ4GwDJodLe7UhYvn%2B0DHAHbMK6NtrBJysnZ1muXm_q9%2B2%2BsKw%40mail.gmail.com.
On 2 May 2018 at 08:26:14, Samuel Falvo II (sam....@gmail.com) wrote:
> Features cost gates, gates cost energy.
If I remeber right, energy consumption is the integral of power over time.
Instead of using a few extra specialised gates for a short time, you
suggest that using a larger bunch of general purpose gates for a lot
longer time is more economical.
I don't say it cannot be so, but I would not count on it, from my
limited knowledge of the technology, it might be very well the other
way around.
--
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+unsubscribe@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAEz%3DsokO6enmQAiFmRhrfG8k20BW42mHdNu%3DuX_5xTGu1%3DQDKA%40mail.gmail.com.
--
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+unsubscribe@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAG7hfcL5%3Df2S3ZokrPc0JS634UjAp26-iOJ3bgHug-pKRR_9rQ%40mail.gmail.com.
(3) Software running on the machine should *not* be able to determine
what images were used to boot the system. (There is no point, since
malicious firmware carrying a rootkit could tamper with any such report;
enabling this gives only a false sense of security.) (This also means
that all digests dumped after the first one not recognized are suspect,
since a malicious firmware component could tamper with subsequent
images.) Only the diagnostic port is required to have access to read
the firmware.
(4) All system firmware can be read back (unconditionally) and
overwritten (unless in mask ROM) using the diagnostic port with 100%
certainty. (Peripherals not on the service network may have their own
unrelated firmware that is excluded from this rule, or may have their
own diagnostic ports.) This also provides a guaranteed unbricking
interface. If the main processor can potentially write to a firmware
image, the diagnostic port must be able to overwrite that firmware image.
(7) If the system is started without a diagnostic pad connected, or the
diagnostic port is explicitly locked and the diagnostic pad
disconnected, the diagnostic port cannot be re-enabled without a hard
reset. When enabling the diagnostic port (but optionally not if the
port was active at the time of the reset), all volatile memory in the
system is erased. (This prevents "0wn3d-by-an-iPod" DMA attacks or
related "quasi-warm-boot" attacks using the diagnostic interface.)