Some Insights on what else Spectre NG (Next Generation) might be about
Thomas Poetter
AI/IT Architect (AI, Big Data, Cloud, Apps, Enterprise, Security), Agile Coach/Project Management/Product Owner, CyberSecurity
On May 7, first Spectre NG (Next Generation) information was planned to be disclosed (expiry of the 90 day Google Project zero grace period). Upon short notice, that was postponed. Yesterday, Spectre (NG) Variant 3a (Rogue System Register Read, CVE-2018-3640) and Variant 4 (Speculative Store Bypass – CVE-2018-3639) were published. However, several patches were submitted to the Linux kernel on May 7 and ever since. Those that point in the direction of fixes for Spectre NG are:
1. Adding of Processor Trace information (mitigating the physical limitation of the Intel Return Stack Buffers (RSB) against underflows)
2. Callers should take proper care to ensure that VMs sharing a queue should be allowed access.
3. Secure virtualization of WLAN access point (AP) devices.
4. Secure virtualization of crypto adapters.
5. Access of VMs and data from WLAN access points (AP) to crypto control blocks (CRYCB)
6. Secure initialization of the CRYCB.
7. Creation of an access points extended addressing facility (APXA) so that an AP matrix can be configured per virtualized guest.
8. Creation of mediated matrix devices, taking care that only one can be opened per virtual guest.
9. Secure management of AP Mask (APM), AP Queue Mask (AQM), AP Domain Mask (ADM), …
10. Creation/secure management of domain attribute files for adapters, domains and control domains.
11. Adding more CPU model (PCID and CPUID) based code so that the various required mitigations are implemented as efficiently as possible on each CPU.
12. Inserting LFENCE (preventing speculative execution) regarding most vulnerable code passages (due to slowdowns of up to 60%, it seems this had and has to be selective, Intel doesn’t seem to have published its rules where to insert them)
13. …
Generally, there are probably many vulnerabilities around speculative execution: One would have to analyse all CPU instructions for speculative aspects. Furthermore, all effects of that speculative execution inside the CPU, all levels of cache and the RAM would have to be undone without exception. Intel seems to lack such a functionality for undoing all effects of speculative execution and rendering time-attacks based on that impossible - and thus we can expect many more quick-hacks to be required until Intel implements such a component.