Tuesday, April 4, 2017
We have made all of the code used in this example available on the CSAPP student website, as part of the Chapter 5 materials. The code has been tested on multiple Linux systems. You can see how to code does when running on your machine.
More information is available at the publisher's website.
The translation was performed by Yili Gong and Lian He of Wuhan University. We are grateful for the conscientious job Yili has done for all three editions of the book.
Thursday, February 18, 2016
It's instructive to read the bug tracking reports at the Google post on their discovery:
as well as the bug tracking log covering the actual error:
There are several important insights to be gained from this report:
- Buffer overflows are still a key source of software vulnerabilities. Although they can be mitigated by address space randomization and other techniques, they still show up.
- This bug was introduced in with glib 2.9 in May, 2008. It was first reported in July, 2015 and fixed in February, 2016. That's a long time for a security vulnerability to lie undetected.
- It only happens when a string is given that exceeds the 2048-byte limit of the regular buffer size. The code is then allocates more memory, but it does not correctly update some of the size information properly. Apparently, this part of the code was not tested very carefully. It's an unfortunate reality of program testing that it's hard to reach all of the corner cases in a program. It seems like using code coverage tools could have been beneficial here.
Tuesday, February 9, 2016
Tuesday, January 12, 2016
Monday, January 11, 2016
The Attack Lab was first offered to CMU students in Fall 2015. It is the 64-bit successor to the 32-bit Buffer Lab and was designed for CS:APP3e. In this lab, students are given a pair of unique custom-generated x86-64 binary executables, called targets, that have buffer overflow bugs. One target is vulnerable to code injection attacks. The other is vulnerable to return-oriented programming attacks. Students are asked to modify the behavior of the targets by developing exploits based on either code injection or return-oriented programming.
Wednesday, August 26, 2015
This is a clever mnemonic devised by Geoff Kuenning of Harvey Mudd College to help him remember which registers are used for passing arguments in a Linux x86-64 system:
Thanks to Geoff for providing this helpful aid!
Monday, August 17, 2015
Tuesday, June 2, 2015
This fall, we will be teaching 15-213, the CMU course that inspired the book originally. Leading up to that, we will update the lecture slides and the labs, and we will be making that available on the instructors' site.
Wednesday, February 11, 2015
According to Amazon, the book will be available starting March 11.
Here are some chapter-by-chapter highlights:
- Ch. 2 (Data): After hearing many students saying ``It's too hard!'' we took a closer look and decided that the presentation could be improved by more clearly indicating which sections should be treated as informal discussion and which should be studied as formal derivations (and possibly skipped on first reading). Hopefully, these guideposts will help the students navigate the material, without us reducing the rigor of the presentation.
- Ch. 3 (Machine Programming): It's x86-64 all the way! The entire presentation of machine language is based on x86-64. Now that even cellphones run 64-bit processors, it seemed like it was time to make this change. Eliminating IA32 also freed up space to put floating-point machine code back in (it was present in the 1st edition and moved to the web for the 2nd edition). We generated a web aside describing IA32. Once students know x86-64, the step (back) to IA32 is fairly simple.
- Ch. 4 (Architecture): Welcome to Y86-64! We made the simple change of expanding all of the data widths to 64 bits. We also rewrote all of the machine code to use x86-64 procedure conventions.
- Ch. 5 (Optimization): We brought the machine-dependent performance optimization up to date based on more recent versions of x86 processors. The web aside on SIMD programming has been updated for AVX2. This material becomes even more relevant as industry looks to the SIMD instructions to juice up performance.
- Ch. 7 (Linking): Linking as been updated for x86-64. We expanded the discussion of position-independent code and introduce library inter positioning.
- Ch. 8 (Exceptional Control Flow): We have added a more rigorous treatment of signal handlers, including signal-safe functions.
- Ch. 11 (Network Programming): We have rewritten all of the code to use new libraries that support protocol-independent and thread-safe programming.
- Ch. 12 (Concurrent Programming): We have increased our coverage of thread-level parallelism to make programs run faster on multi-core processors.
Friday, June 13, 2014
Here's a summary of the planned changes for each chapter.
- Introduction. Minor revisions. Move the discussion of Amdahl's Law to here, since it applies across many aspects of computer systems
- Data. Do some tuning to improve the presentation, without diminishing the core content. Present fixed word size data types.
- Machine code. A complete rewrite, using x86-64 as the machine language, rather than IA32. Also update examples based on more a recent version of GCC (4.8.1). Thankfully, GCC has introduced a new opimization level, specified with the command-line option `-Og' that provides a fairly direct mapping between the C and assembly code. We will provide a web aside describing IA32.
- Architecture. Shift from Y86 to y86-64. This includes having 15 registers (omitting %r15 simplifies instruction encoding.), and all data and addresses being 64 bits. Also update all of the code examples to following the x86-64 ABI conventions.
- Optimization. All examples will be updated (they're mostly x86-64 already).
- Memory Hierarchy. Updated to reflect more recent technology.
- Linking. Rewritten for x86-64. We've also expanded the discussion of using the GOT and PLT to create position-independent code, and added a new section on the very cool technique of library interpositioning.
- Exceptional Control Flow. More rigorous treatment of signal handlers, including async-signal-safe functions, specific guidelines for writing signal handlers, and using sigsuspend to wait for handlers.
- VM. Minor revisions.
- System-Level I/O. Added a new section on files and the file hierarchy.
- Network programming. Protocol-independent and thread-safe sockets programming using the modern getaddrinfo and getnameinfo functions, replacing the obsolete and non-reentrant gethostbyname and gethostbyaddr functions.
- Concurrent programming. Enhanced coverage of performance aspects of parallel multicore programs.
Wednesday, March 27, 2013
Tuesday, January 22, 2013
Monday, November 12, 2012
- 167 students
- 14 recitations sections (12 students each)
- 14 faculty doing recitations
- 8 faculty doing lectures
Monday, June 11, 2012
In a recent blog post, I noted that 52% of all copies of the CS:APP that have been sold were in Chinese. Prof. Yili Gong of Wuhan University did the translations for both the first and second editions of the book. Prof. Gong has also been a valuable contributor to our errata.
I recently came back from a trip to China, where I gave lectures about CS:APP at both Peking University and Tsinghua University, both of which use the book in their courses. Looking at our adoptions list, there are only 8 universities in China that we know of using CS:APP as a textbook. Apparently, the vast majority of copies sold in China are being used by individuals for self study.
Wednesday, May 30, 2012
- English. Including versions published in India (1st edition only) and China (1st and 2nd edition) for readers in those two countries
- Chinese (1st and 2nd edition)
- Korean (2nd edition)
- Russian (1st edition)
- Macedonian (1st edition)
One thing that's clear is that we're very popular in China: fully 52% of the total has been in Chinese, and another 15% has been the English version for the Chinese market.
Thursday, May 17, 2012
The Bomb Lab servers assign diffusions and explosions to Bomb IDs, rather than users, and Bomb IDs start over from scratch each term. Thus, if a student who took the class last semester ran their old bomb while the lab was as underway this semester, then the explosions and diffusions from the old bomb would be incorrectly assigned to the current bomb with the same Bomb ID.
To address this, we've added a per-semester identifier, called $LABID, to the Bomb Lab config file. Instructors can set this variable each term (for example $LABID="f12") to uniquely identify each offering. Any results from previous bombs with different $LABIDs are ignored.
Thanks for Prof. Godmar Bak, Virginia Tech, for pointing this out.
Monday, April 23, 2012
(1) Some recent gcc builds automatically enable the -fstack-protector option. We now explicitly disable this by compiling the buffer bomb with -fno-stack-protector.
(2) In order to avoid infinite loops during autograding, the previous update from February 2012 introduced a timeout feature that was always enabled. However, this was a problem for students who were debugging their bombs in gdb. We now enable timeouts only during autograding.
Thanks to Prof. James Riely, DePaul University for pointing these out to us.
Tuesday, February 21, 2012
Saturday, February 4, 2012
Shortly after arriving, we visited Strathmore University, where I gave a presentation about CS:APP. There were students and faculty members from several area universities. The talk went very well, with interesting and insightful questions from the audience. Perhaps the most striking response occurred when I showed our map of schools using CS:APP as a text book as of Jan. 1, 2012: