Mitigating Spectre in future CPU Designs

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.

Other urls found in this thread:

youtube.com/watch?v=qgiUuTmXyGs
twitter.com/SFWRedditImages

Boys make the best girls.

Addition I forgot:
- when the nbits are filled, CPU stalls waiting on the first branch.

sauce?

[Yatsuzaki] Josou Demo Aishite (Gekkan Web Otoko no Ko-llection! S Vol. 15) According to saucenao.
can we like talk about cpus now

>start figuring out how to fix it.
No need
youtube.com/watch?v=qgiUuTmXyGs

This doesn't fix the fundamental flaw in speculation, and the attacks work on cache anyway.

bump, i'm still interested in this(OP)

fpbp

One core per process.

This doesn't seem practical in modern preemptive multitasking OSes.

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?

this is not a hardware solution

Remove speculative execution, remove out-of-order execution, remove pipelining, remove all caches, sync all clocks on the board to the CPU

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.

Switch to FPGA's for everything.

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

>> 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?

the code knows that it's not supposed to do something, but the CPU does it anyway

Because with spectre, you can tell the cpu to speculatively branch the wrong way, and get the result from that branch.

>girl (male) fucks guy
abort

>girl (male) fucks male (soyboy)
FTFY

How retarded can you be

But how do you index foreign memory without pointer arithmetic? You need to be able to specify arbitrary addresses somehow

how would arrays work without addresses
precomputing addresses here is not an option
no really you can't fit it all in registers

oops, read your message wrong, you don't use addresses, you use cache lines.
that's why the attack is so bad