David Chisnall
Abstract
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.
- C Defect Report 260. 2004; http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_260.htm.Google Scholar
- Chadwick, G. A. 2013. Communication centric, multi-core, fine-grained processor architecture. Technical Report 832. University of Cambridge, Computer Laboratory; http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-832.pdf.Google Scholar
- Memarian, K., Matthiesen, J., Lingard, J., Nienhuis, K., Chisnall, D. Watson, R. N. M., Sewell, P. 2016. Into the depths of C: elaborating the de facto standards. Proceedings of the 37th ACM SIGPLAN Conference on Programming Language Design and Implementation: 1-15; http://dl.acm.org/authorize?N04455. Google ScholarDigital Library
- Ou, A., Nguyen, Q., Lee, Y., Asanovic, K. 2014. A case for MVPs: mixed-precision vector processors. Second International Workshop on Parallelism in Mobile Platforms at the 41st International Symposium on Computer Architecture.Google Scholar
- Perlis, A. 1982. Epigrams on programming. ACM SIGPLAN Notices 17(9). Google ScholarDigital Library
Index Terms
- C Is Not a Low-level Language: Your computer is not a fast PDP-11.
Recommendations
Performance based design of high-level language-directed computer architectures
This paper is concerned with the analytical modeling of computer architectures to aid in the design of high-level language-directed computer architectures. High-level language-directed computers are computers that execute programs in a high-level ...
Reviews
Andrea F Paramithiotti
Early computers were programmed with low-level languages that were very close to their physical architecture. Although those languages guaranteed efficient use of machine resources, they were not particularly user-friendly, meaning it was hard for researchers in any domain outside computer science to write programs that solved their problems. The C programming language was developed as an effort to overcome these difficulties. It was, at the same time, compatible with the greatest number of computer architectures and more comprehensible by people who were not computer scientists. Yet as processor architecture evolved and became more sophisticated, the C language developed problems of its own, some of which are highlighted in this article. In short, C natively uses sequential execution and flat memory spaces-no problem for early computers where processor architectures were built precisely on those requirements, but a big pain for modern computers where processors heavily use threading for program execution and caching for fast data retrieval. Compiling C programs to make use of these features creates huge, inefficient, low-level programs. On the other hand, forgoing these features makes inefficient use of processor power. More alarmingly, these weaknesses have been known to be exploited by the Spectre and Meltdown viruses. The author's answer to this issue seems rather blunt at first: stop using C when programming on machines with modern processor architectures. On second thought, though, this recommendation holds only for newer code; the world literally runs on plenty of legacy C programs, and they continue to be efficient and reliable.
Access critical reviews of Computing literature here
Become a reviewer for Computing Reviews.
Comments