3 ms·

> What’s the strategy for operating systems, compilers, and/or language runtimes to figure out what a RISC-V chip supports? Same as for x86, Power, ARM, MIPS,

> What’s the strategy for operating systems, compilers, and/or language runtimes to figure out what a RISC-V chip supports? Same as for x86, Power, ARM, MIPS, systemz, sparc, ... ISAs: there is a flag register that the OS can query to test whether the hardware supports something. I only know one ISA that works in a completely different way (WebAssembly), by requiring the user to attempt to perform an operation, and if that faults, then the operation is not supported. The reason WASM can do this is because it is a virtual ISA. This approach does not work well for real hardware because it makes instruction decoders larger and slower, since it prevents them from assuming that they will only be fed instructions they do know.

orra 6y ago
You sound knowledgeable, but this I don't understand: > This approach does not work well for real hardware because it makes instruction decoders larger and slower, since it prevents them from assuming that they will only be fed instructions they do know. But what if you fail to do the runtime checks? And for example just feed an SSE4 binary/instructions to a processor that only supports SSE3? Then won't it segfault?
- fluffything 6y ago
  Hardware undefined behavior. The hardware can do anything. That includes trapping on an illegal instruction or something, but there is no guarantee that some CPU that was designed and built before SSE4 existed will do anything meaningful when fed with machine code that it was never intended to see. You are basically hopping for the instruction decoder to be "really good", and not "really fast". Eg. suppose that there is only one instruction in SSE3 which has the 7th bit set. A fast instruction decoder tests that bit, and if its true, it knows exactly what instruction that is. Years later, SSE4 is designed and implemented, and it adds another instruction that also has that bit set. You are required to check whether the CPU supports SSE4, and the SSE3-only CPU will tell you that it does not. If you then go ahead and feed it a SSE4 instruction, the CPU can do really anything, including executing some other completely different instruction.
  - orra 6y ago
    Interesting, but how is that not a security flaw? Sounds like user space applications can cause CPU level undefined behaviour!?
    - fluffything 6y ago
      When running a user space program, instead of executing the instruction in the assembly, the CPU will at best raise an exception, and at worse attempt to execute some other instruction. If the process doesn't have privileges to execute that other instruction, then the CPU will just raise an exception (unless if it has a big hardware bug). I don't see how this could be a security flaw.

orra 6y ago

You sound knowledgeable, but this I don't understand: > This approach does not work well for real hardware because it makes instruction decoders larger and slower, since it prevents them from assuming that they will only be fed instructions they do know. But what if you fail to do the runtime checks? And for example just feed an SSE4 binary/instructions to a processor that only supports SSE3? Then won't it segfault?

fluffything 6y ago
Hardware undefined behavior. The hardware can do anything. That includes trapping on an illegal instruction or something, but there is no guarantee that some CPU that was designed and built before SSE4 existed will do anything meaningful when fed with machine code that it was never intended to see. You are basically hopping for the instruction decoder to be "really good", and not "really fast". Eg. suppose that there is only one instruction in SSE3 which has the 7th bit set. A fast instruction decoder tests that bit, and if its true, it knows exactly what instruction that is. Years later, SSE4 is designed and implemented, and it adds another instruction that also has that bit set. You are required to check whether the CPU supports SSE4, and the SSE3-only CPU will tell you that it does not. If you then go ahead and feed it a SSE4 instruction, the CPU can do really anything, including executing some other completely different instruction.
- orra 6y ago
  Interesting, but how is that not a security flaw? Sounds like user space applications can cause CPU level undefined behaviour!?
  - fluffything 6y ago
    When running a user space program, instead of executing the instruction in the assembly, the CPU will at best raise an exception, and at worse attempt to execute some other instruction. If the process doesn't have privileges to execute that other instruction, then the CPU will just raise an exception (unless if it has a big hardware bug). I don't see how this could be a security flaw.