Since CPUs now pre-fetch data and then check later if you have credentials to look at it, and it is all hardware side, no patch will help you.
I think these CPUs are only 2007ish and later old
Meltdown and Spectre
Jack Richardson
Brayden Nguyen
even playing HD videos became laggy
Colton James
C2D were good enough, now we all have to upgrade because reasons
Julian Gonzalez
Jordan Cook
luckily that doesn't fucking matter because process isolation never worked anyway (due to UNIX braindamage ,etc). just run everything as a single user or fuck off and use one machine per process
Bentley Mitchell
No, you nigger, I asked what kind of computer you own, specifically so I could lookup the Coreboot or Libreboot compatibility. These softwares replace the Intel firmware almost entirely and mitigate a lot of these vulnerabilities. Also removes built in back doors.
Logan Sullivan
Can disable speculative execution on a librebooted/corebooted computer? I thought libre/coreboot only applied to the BIOS and not wherever the fuck the CPU stores microcode.
The "patch" would be CPU manufacturers letting you disable speculative execution which will never happen. Speculative execution is the proccessor via some function executing differing paths that code could execute. So say you told the compiler
Without speculative execution the proccessor would do this one thing every time which is deterministic
With speculative execution it executes all of these combinations every time barring some form of cache based on previous execution which just adds more complexity and waste of proccessing power, which wastes time and energy
This is in order to guess what the programmer actually wanted to do, it then feeds the result that (((makes the most sense))) back to wherever the data was to be stored. It does this shit for every instruction and is a huge speed decrease in exchange for devs being able to write shit code. Meltdown and specter abuse the results of speculative execution to do what they do.
Older CPU manufacturers fucked up and disabled it on older CPU's since it is a backdoor falsely in the name of speed. Except that disabling it ironically improves your performance since compilers are better then two decades ago and can path the instructions for the programmer without needing to guess at the proccessor level incase the compiler/programmer made an error. See ARM or powerpc speculative vs no speculative benchmarks for proof.
Ayden Brooks
github.com
Kernel is Linux 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u2 (2019-05-13) x86_64
CPU is Intel(R) Core(TM)2 CPU P8600 @ 2.40GHz
SUMMARY:
CVE-2017-5753:OK
CVE-2017-5715:OK
CVE-2017-5754:OK
CVE-2018-3640:KO
CVE-2018-3639:KO
CVE-2018-3615:OK
CVE-2018-3620:OK
CVE-2018-3646:OK
CVE-2018-12126:KO
CVE-2018-12130:KO
CVE-2018-12127:KO
CVE-2019-11091:KO
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
CVE-2018-3640 [rogue system register read] aka 'Variant 3a'
CVE-2018-3639 [speculative store bypass] aka 'Variant 4'
CVE-2018-3615 [L1 terminal fault] aka 'Foreshadow (SGX)'
CVE-2018-3620 [L1 terminal fault] aka 'Foreshadow-NG (OS)'
CVE-2018-3646 [L1 terminal fault] aka 'Foreshadow-NG (VMM)'
CVE-2018-12126 [microarchitectural store buffer data sampling (MSBDS)] aka 'Fallout'
CVE-2018-12130 [microarchitectural fill buffer data sampling (MFBDS)] aka 'ZombieLoad'
CVE-2018-12127 [microarchitectural load port data sampling (MLPDS)] aka 'RIDL'
CVE-2019-11091 [microarchitectural data sampling uncacheable memory (MDSUM)] aka 'RIDL'
Nicholas Ramirez
Imagine being this ignorant lol. What speculative execution does is let you execute more instructions at once than you could otherwise, even with the most perfect x86 code.
Without speculative execution you could only fill the pipeline up to a branch. With speculative execution the pipeline is filled with the instructions in the most probable branch, and if that wasn't the path that was actually taken, then the results from the extra useless instructions that were executed are ignored.
The security problems come from the fact that whether those branches are guessed correctly depends on what code was executed previously, which allows programs to deduce information they shouldn't have access to about the other programs running in the system (including kernel structures).
Julian Parker
You are wrong, that is what ALU's are for. What you mean to say is that a schedular on the die creates latency in order to hide the complexity of branch prediction overhead. There's only so many logic units or FPU's that can take decoded instructions at a time. There's no getting around that physical limit in software.
Why waste die space on more complexity and heat with speculative execution and its neccessary components when you could add more ALU's to execute more at once?
Are you cnile? Why would you ever want control taken away from you? Let the compiler/programmer/you deal with scheduling instructions in parrallel and not the processor. The proccessor processes, it is not meant to schedule. If you want a hardware schedular instead of doing it at the software level such as modern speculative execution schedulars make it a addon card for cnile programmers such as yourself. Let the competent engineers program without the handholding.