This week, there has been a lot of discussion about the newly discovered vulnerability known as side-channel attacks [1]. Most modern superscalar microprocessors have this vulnerability due to their use of speculative execution. The existence of this vulnerability has been confirmed by Intel, AMD, ARM and several software vendors [2]. People have asked me about this so here is my evaluation of the situation.
This vulnerability makes it theoretically possible - under certain conditions - to read sensitive information from computer memory.
Facts about this vulnerability:
It is only possible to read information, not to modify or delete it
Sensitive information can be read only if it resides in cache memory, not if it is only stored on a disk or other storage device
Reading sensitive information is very slow, reading one bit at a time. A complete attack may take hours
The attacker needs access to the same computer and the same processor core and the same address space as the sensitive information
No actual attack has been observed. The researchers have only proven that it is theoretically possible. The possibilities for exploiting this vulnerability in practice are quite limited.
Possible remedies:
General recommendations for protection against malware apply
Keep sensitive information and applications separate from general information and applications
Keep the operating system updated
Software developers should not regard a simple branch as sufficient for protecting sensitive data from unauthorized access
Software fixes can slow down general performance
A complete elimination of this vulnerability would require a change in microprocessor hardware so that the cache state is rolled back when a speculative execution is rolled back. This would be quite costly.
The proposed ForwardCom instruction set and computer system is better protected than current systems because security is integrated in the fundamental design rather than added as patches later:
ForwardCom has an addressing mode for arrays with bounds checking. Any violation of array bounds will stop speculative execution. This protection can only be used if the maximum array size is known at compile time
Device drivers have limited access rights. A device driver can only access its own memory space and a specific block of user memory that the calling application has given it access to
Each thread has its own private memory space by default
Memory access rights can be checked immediately with an on-chip memory map
Simultaneous multithreading is not recommended, though it is technically possible to make a ForwardCom processor with SMT
The Meltdown and Spectre CPU flaws have been making rounds lately and I've been wondering if ForwardCom could have mitigation techniques.
Meltdown happens because a lot of fast CPUs essentially ignore page faults except for marking the instructions for generating a fault on retirement, then doing a rollback when they reach the end of the pipeline.
It's a classic RISC technique (the mips R10000 did this as well) and helps keep the pipeline simple, but opens up the possibility of the meltdown exploit.
Meltdown:
- Conditional branch to special code
- The branch is built to look like it will be taken, but won't
- Read from supervisor memory
- Use this supervisor data to build an address
- Read from a random address built from this data
- This will evict a cache line
- CPU rollbacks due to the branch misprediction
- Do timed memory reads to figure out which cache line got evicted
- Recover supervisor data from this information
OS vendors now have to implement separate page tables for the OS data because of this, and there are patches and a performance cost. Maybe CPU facilities to do separate OS page tables could be a good idea.
AMD has avoided this problem specifically because their cores won't load page faulting data, not even speculatively.
Spectre is even more complex and uses all shared CPU components (cache, branch predictor, instruction buffer, tlb...) to form side-channels for information to form timing attacks, and right now there are no architectural defences against this.
Would it be possible to give ForwardCom defences against this?
Hubert, I have moved your post to the thread "Side-channel attacks". The question is discussed above.
A ForwardCom processor will never ignore page faults if it has an on-chip memory map, as I have proposed, because access violation will be detected immediately and this will stop speculative execution.
An on-chip memory map is feasible only if we can keep memory fragmentation low. One method of reducing memory fragmentation is to replace dynamic link libraries and shared objects with static linking and a feature for re-linking executable files to update a library, as I have discussed before. I am working on this re-linking feature right now.