It is likely triggering one branch misprediction will avoid future branch predictions and instead cause a stall. Even if it isn’t, taking the opposite branch once before taking the desired one would leave many alterations to the local cache, unless in a thread on the same core is making some effort to measure which branch was used first. Simply flushing and using an lfence should prevent many issues and just cause a stall. It is funny on stackexchange that L1 and L2 caches (SRAM less vulnerable to radiation) is often disabled due to radiation, according to various askers. It is still bizarre that “AEX” masks registers before context switching out. It seems as if Intel is aware of an issue that they would be liable for. Side channel attacks obtaining information measured in the bits per millisecond or less is unimportant. There are still several “reserved” bits in CPUID, and buffer overreads or underreads, or non-linear overreads would negate many defenses. Possible that C++ could use a time consuming extension preventing parsers reading more than a kilobyte of data, although this would require extensive reprogramming to include it. Although a code review of parsers wouldn’t be bad either. “Mitigate spectre” Well, that solves one bug we’re aware of. What’s the zero day market for browsers again? Oh, right, RCE. RCE is a bit worse than... Spectre. The 1-day market could be impaired by delaying the inclusion of diffs of crash-causing or security bugs in the public code by waiting a day after releasing the binaries. (Although this might encourage monopolies so it should be socially fair to allow access to major downstream distributions) The GPL doesn’t say how timely everyone has to be, and I imagine doing things faster than it would take to make a request for the source code and responding would be legally sufficient. Anyway, the Grsec theory that because someone used an outdated version that it has to be restricted to paying customers is bonkers. I think you can legally call the Grsecurity Firm bonkers.