So now that the exploit has been released, we should stop screaming about it and start figuring out how to fix it.
My proposal: Copy On Write Cache: Upon a speculative branch, any cache requests running on these branches is placed into a separate cache, tagged by an n-bit branch id, in which each bit is a Branch/No branch speculation For example: Branch tag ID 1010 is: Branch first branch Don't branch second branch Branch third branch Don't branch fourth branch When a branch succeeds, take the routes based on failed branches, zero them out, and shift the ids for good branches up 1. Then merge these cache requests into main cache. Gotta run, hope someone can expand on this idea.
This doesn't fix the fundamental flaw in speculation, and the attacks work on cache anyway.
Ryder Moore
bump, i'm still interested in this(OP)
Jeremiah Flores
fpbp
Jaxson Young
One core per process.
Noah Lee
This doesn't seem practical in modern preemptive multitasking OSes.
Isaiah Wright
It's actually extremely simple to fix, we just need to end this current situation where it's considered normal to run any code one comes across on your computers and get rid of software that makes such a thing possible. Think, if the majority of people didn't have their web browsers set up to run any code the website they're connecting to pushes to them through javascript, this vulnerability would be a non issue for the most part. This is literally only an issue because people think that they can do things that need to be secure on their machine while letting anyone run whatever code they want on their machine. You wouldn't expect to do secure things in your house while simultaneously letting anyone you meet in public come in, would you?
Isaiah Ortiz
this is not a hardware solution
Cameron Scott
Remove speculative execution, remove out-of-order execution, remove pipelining, remove all caches, sync all clocks on the board to the CPU
Ayden Clark
What about having OSes not allow custom assembly code to be run, or requiring proof checked code to ensure that all memory accesses are within the programs mapped memory?
I mean, it's only an issue if you run arbitrary assembly code on your machine right? That can seriously screw things up regardless. Just require all code to be written in a safe language, and memory related exploits won't be a thing.
Xavier Reed
Switch to FPGA's for everything.
Mason Clark
welcome to your commodore 64 it's an issue beyond assembly, can be exploited in JITs, perfectly correct code can be manipulated to access things incorrectly and we'll be back to 1995 in terms of performance
i'm not mad i'm just disappointed
Brayden Gray
>> it's an issue beyond assembly, can be exploited in JITs, perfectly correct code can be manipulated to access things incorrectly
How? If the language you use is memory safe and has no undefined behaviour, how to you exploit a hardware bug to access memory you're not allow to look at?
Mason Davis
the code knows that it's not supposed to do something, but the CPU does it anyway
Austin Miller
Because with spectre, you can tell the cpu to speculatively branch the wrong way, and get the result from that branch.
Aaron Nelson
>girl (male) fucks guy abort
Leo Hughes
>girl (male) fucks male (soyboy) FTFY
James Brown
How retarded can you be
Joshua James
But how do you index foreign memory without pointer arithmetic? You need to be able to specify arbitrary addresses somehow
Mason Stewart
how would arrays work without addresses precomputing addresses here is not an option no really you can't fit it all in registers
Oliver Roberts
oops, read your message wrong, you don't use addresses, you use cache lines. that's why the attack is so bad
