SoylentNews is people
SoylentNews
posted by
cmn32480
on Wednesday May 23 2018, @06:47PM
from the your-computer-is-not-a-fast-PDP-11 dept.
from the your-computer-is-not-a-fast-PDP-11 dept.
Very interesting article at the IEEE ACM by David Chisnall.
In the wake of the recent Meltdown and Spectre vulnerabilities, it's worth spending some time looking at root causes. Both of these vulnerabilities involved processors speculatively executing instructions past some kind of access check and allowing the attacker to observe the results via a side channel. The features that led to these vulnerabilities, along with several others, were added to let C programmers continue to believe they were programming in a low-level language, when this hasn't been the case for decades.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Life is to you a dashing and bold adventure.
(Score: 1, Insightful) by Anonymous Coward on Wednesday May 23 2018, @11:33PM
I can't agree with the starting point or conclusion of this article.
C is not a high or low level language.
It is a language which supports both a sort of high and definitely low level programming.
You can write big programs and get the full performance of the machine in selected parts.
You can talk to hardware at the bit and register level.
None of this requires a big, complex compiler if the programmer is able to provide carefully crafted code for the few parts that need to be fast.
(Unrolled, lots of opportunities for speculative and parallel operations, and easy mapping into assembly code.)
Given this, the same code will run well on multiple of ISA's.
I know this to have been true since at least the 90's, and it's only getting better since then.
C does assume a sequential model, but if you provide enough work to do without sequential dependencies, since Alpha gcc has not had problems getting a bunch of functional units working in parallel. Vector processors may be a simpler way to make hardware to do this. They are available as optimizations in many common processors but history has shown that this is a niche thing.
These exploits are possible because there is too much shared logic between the protection levels. Some secure facilities paint physical things different colors for different levels. Perhaps the processor or at least the simulator needs to do this with logical labels to sort this out. (black code seeing red data is an error. Red code writing to black memory makes black data, etc) Didn't Buroughs or Multix already do this at runtime?