3 ms·
I have difficulty following some of the points made in that article. 1. I always thought that common vulnerabilities like Spectre were a problem with implement
by ribit 4y ago
I have difficulty following some of the points made in that article.
1. I always thought that common vulnerabilities like Spectre were a problem with implementation (a certain way to do speculative execution) rather than with the ISA. How is RISC-V ISA supposed to solve these kind of issues?
2. I do not understand how openness of RISC-V makes it easier to find bugs in the ISA. For example, ARM ISA is fully described in a publicly available documents. What is stopping a security researcher from analysing the ARM specification and pointing out issues at the ISA level? Or do they mean that it's easier to analyse open-sources RISC-V implementations rather than ISA spec?
- gchadwick 4y ago> 1. I always thought that common vulnerabilities like Spectre were a problem with implementation (a certain way to do speculative execution) rather than with the ISA. How is RISC-V ISA supposed to solve these kind of issues? They are implementation dependent but the architecure can help. It can provides guarantees about the ways in which speculation is limited and provide features to help software isolate speculation (if you download the arm ARM here: https://developer.arm.com/documentation/ddi0487/latest https://developer.arm.com/documentation/ddi0487/latest and look at section A2.2.1 which lists post v8.0 architecture additions you'll see a whole bunch of stuff around speculative execution for instance. The RISC-V ISA doesn't inherently resolve these issues, indeed I don't think it says anything on speculative execution, provide certain features and and guarantees to help isolate it (like arm does). > 2. I do not understand how openness of RISC-V makes it easier to find bugs in the ISA. For example, ARM ISA is fully described in a publicly available documents. What is stopping a security researcher from analysing the ARM specification and pointing out issues at the ISA level? Or do they mean that it's easier to analyse open-sources RISC-V implementations rather than ISA spec? I don't think the ISA openness helps you much or at all here, researchers analyse x86 and arm all the time and publish results. I think they're mixing up open ISA with open design and with the latter, yes it does make it easier for external parties to find security issues.
- IshKebab 4y agoYeah the point about not being able to do this for ARM makes no sense. Especially since the paper starts with an example of the issue from ARM!
- colejohnson66 4y ago> For example, ARM ISA is fully described in a publicly available documents. Wasn’t Spectre discovered through nothing more than a careful reading of Intel’s publicly available documentation?
- crest 4y agoPart of the problem is that existing ISAs have been (and still are) underspecified. At best software was software was written against observed implementation behaviour. More commonly software wasn't written against any (formal) specification from simple things like is shifting by a variable number of bits a constant time operation, to nastier things like does the latency of multiplication leak the magnitude or hamming weight all the way to does the the implementation speculate past permission checks and leak observable state changes left behind by speculative memory accesses. Most instruction sets don't specify the presence and absence of side channels. RISC-V is in a better position than most other ISAs to fix this "oversight".