News for hackers. Stuff that matters.
Re:Spectre and the end of langsec by adrianN on Thursday January 11, 2018 @12:06PM (#16125495)
Currently we build CPUs with a handful of very powerful cores and multiplex processes onto them, to optimize for the use case that a process really does need all the power a core offers. We could build processors with, say, only two powerful cores and a hundred simple cores and give most processes their own core.
Re:Spectre and the end of langsec by GuB-42 on Thursday January 11, 2018 @01:05PM (#16126094)
That's either a big waste of silicon or a very hard problem.

On a related topic, I know someone who worked on CPU/FPGA hybrid architectures. The idea was to move processes between CPUs and FPGAs. Awesome stuff, realtime processes offloaded to the FPGA get to run completely off the CPU, with ridiculously low latencies. The issue is that you really have to design your code for it.

Re:Spectre and the end of langsec by phkahler on Thursday January 11, 2018 @04:27PM (#16128059)
>> That's either a big waste of silicon or a very hard problem.

How about 16 big core and 4096 small cores that don't have speculative execution?

https://content.riscv.org/wp-content/uploads/2017/12/Tue1136...

Perhaps one day we'll talk about how many cores are allocated to a program rather than the other way around. OTOH even their chip will have shared caches. Spectre is achieved via speculation but communicates via side channel of the cache, so it's not clear this is a whole lot better.

Re:Spectre and the end of langsec by warkdarrior on Thursday January 11, 2018 @06:31PM (#16129090)
There are always things that are shared even between distinct cores: RAM, buses, disk I/O, network I/O, LAN, the Internet, etc.
Re:Spectre and the end of langsec by phkahler on Friday January 12, 2018 @10:21AM (#16133517)
Agreed. I pointed out caches. Running only a single process per core does prevent sharing of the branch predictor and the lowest level cache.

What nobody wants to say is that the real problem is running untrusted code. They don't want to say it because Apps and JS are so many peoples bread an butter these days.

Re:Spectre and the end of langsec by milesvp on Thursday January 11, 2018 @01:24PM (#16126332)
I still dream of a day where the compiler largely handles this kind of thing for you. I'm starting to suspect that this day may never come, but it feels like a logical extension of the jit. To have code that self modifies not just itself to run faster, but also the hardware it runs on just seems so cool.

Course, in the context of the larger thread, I can't help but wonder how much more attack surface this would tend to create.

Re:Spectre and the end of langsec by qubex on Thursday January 11, 2018 @02:55PM (#16127230)
I remember something marketed as a “hypercomputer” by Starburst Systems or something like that (long since defunct, apparently... I'm referring back to the late 1990s and early 2000s) that “compiled software to hardware” by substituting parallel CPUs with FPGAs.
Re:Spectre and the end of langsec by Aloha on Thursday January 11, 2018 @04:26PM (#16128047)
This approach has been tried - as it turns out, we're not very good at writing compilers.
Re:Spectre and the end of langsec by zzzcpan on Thursday January 11, 2018 @04:42PM (#16128188)
Compilers are sort of at the edge of technology, there is always some value in trying again, no matter how many times it has been tried before.
Re:Spectre and the end of langsec by nine_k on Thursday January 11, 2018 @01:14PM (#16126201)
FPGAs are great because they are field-programmable and can adapt the hardware to a task. In all other aspects (density, power draw, cost) they are not that great.

We could consider something like Tilera chips working together with privileged "general compute" chips, the same way as current machines work with separate GPUs as privilege "vector compute" chips.