5 ms·
>Spectre has nothing to do with program correctness or safety. I get your point and also your analogy of the "bricks::hardware" and "house::software". Yes, Sp
by jasode 9y ago
>Spectre has nothing to do with program correctness or safety.
I get your point and also your analogy of the "bricks::hardware" and "house::software".
Yes, Spectre has nothing to do with C/C++/Javascript/Rust safety. Yes, we can look at the world as it currently is with existing languages and confidently say that.
However, I think you're inadvertently creating a thought-stopping comment instead of charitably reading his essay as exploring a possible future of language security and whether that langsec evolution is practical or provable. That author starts that line of thought with, "Where do we go from here? I see but two options. [...]"
My attempts at addressing the author's possible future would be:
1) microcode instructions may be considered a "competitive advantage" and therefore cpu manufacturers like Intel and AMD wouldn't publicize them such that GCC/Clang could incorporate that intelligence into a compilation algorithm. There are already variations of this profit-vs-openness tension happening such as NVIDIA not releasing open source Linux drivers.
2) publishing microcode architecture and putting the optimization responsibility into into GCC/LLVM sounds very similar to the failed EPIC instruction set[1] for Itanium. There seems to be an underlying human law of "specialization" and having Intel hardware engineers figure out all the speculative out-of-order-execution was better for us than having Richard Stallman and his gcc colleagues work on it. Unfortunately, the hardware side of things created a 20 year old bug. Is there new evidence about the interaction of hardware optimization & compiler theory that won't repeat the Itanium EPIC failure?
3) having a completely specified "hardware model vm" transparent to a compiler and language spec doesn't necessarily remove side-channel attacks. It may just change who creates the vulnerabilities... e.g. the Clang LLVM team (instead of Intel) inadvertently creates a timing attack inside the target executable.
[1] https://en.wikipedia.org/wiki/Explicitly_parallel_instruction_computing https://en.wikipedia.org/wiki/Explicitly_parallel_instructio...
- outworlder 9y agoIsn't "not publishing microcode instructions" security by obscurity?
- flukus 9y ago> Yes, Spectre has nothing to do with C/C++/Javascript/Rust safety. I'm not so sure at the root cause level, part of the problem is that programming languages treat memory as a contiguous blob and speculative execution is a work around for that. All languages are designed as if the memory bus speed and cpu are still identical. Maybe languages need better ways to tell CPU's what data they are going to need ahead of time so that the CPU can have it ready. Could we build a cache aware programming language? Imagine something like an iterator that would process one item and concurrently pull in data for the next iteration. If creating correct hardware is too hard then maybe we can be more explicit at the software level.
- jnwatson 9y ago"Preloading" instructions already exist, e.g.: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344i/Cbbbdaed.html http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc....
- flukus 9y agoI was thinking something slightly more complicated. Correct me if I'm wrong but you have to know the memory address to prefetch so it can only deal with a single level of indirection. Often it's a case where you know you'll need x but you'll also need x.y (and y is a pointer) and you can't prefetch that until you have x. For many cases you could build an index to get both efficiently but I think it's pretty hard to do generically.