A short session with gdb verifies a few facts; the student has made notes of some observations:

Transcription

1 This assignment refers to concepts discussed in the course notes on gdb and the book The Art of Debugging by Matloff & Salzman. The questions are definitely "hands-on" and will require some reading beyond the course notes. Download the file HW10.tar and unpack it on a Linux system. It contains files you will need for this assignment. You may work in pairs for this assignment. If you choose to work with a partner, make sure only one of you submits a solution and that the file lists names and PIDs for both of you. Prepare your answers to the following questions in a single plain ASCII text file. Submit your file to the Curator system by the posted deadline for this assignment. No late submissions will be accepted. You will submit your answers to the Curator System ( under the heading HW [26 points] A student is testing an implementation of the following C function: /** * Computes and returns sum of A[0]:A{Sz-1]. * Pre: * A points to an array of dimension at least Sz * A[0:Sz-1] are initialized * Returns: * sum of A[0] through A[Sz-1] */ int AddEm(const int* A, int Sz); Unfortunately, the student does not have the C source code for the implementation; instead, she has an object file obtained by compiling AddEm.c with the following command: gcc -c -O0 -m32 -std=c99 -Wall AddEm.c As you can see, the object file is compiled to 32-bit instructions, with no optimizations, and (alas) with no debugging information added (since the build did not include the switch g or ggdb3). So, while the student can use gdb to analyze the execution of the function (after writing a driver for it), but gdb will be less useful than she might like. A short session with gdb verifies a few facts; the student has made notes of some observations: 2107: Q1 > gdb Q1main (gdb) list 1 #include <stdio.h> 2 #include "AddEm.h" 3 4 int main() { 5 6 int Sz = 5; 7 int A[5] = {32, 16, 64, 4, 8}; 8 9 int Sum = AddEm(A, Sz); 10 Here's part of my driver code. Note that AddEm() should have returned the sum 124. Pause execution at the beginning of main(). (gdb) break main Breakpoint 1 at 0x80483cd: file Q1main.c, line 6. 1

2 (gdb) run Starting program: /home/jillhokie/hw10/q1/q1main Breakpoint 1, main () at Q1main.c:6 6 int Sz = 5; (gdb) n 7 int A[5] = {32, 16, 64, 4, 8}; (gdb) n 9 int Sum = AddEm(A, Sz); (gdb) p *A@5 $1 = {32, 16, 64, 4, 8} (gdb) print/x &A[0] $9 = 0xffffd7e4 (gdb) p Sum $2 = A points to an array; this prints the first 5 elements. Let's see the address of the array; it's passed in the function call. Sum holds garbage; hasn't been initialized yet. OK. (gdb) n 11 printf("sum is %d\n", Sum); (gdb) p Sum $3 = Sum is obviously wrong why did that happen? Now, we see that the return value from AddEm() is wrong badly wrong. In order to pin down the reason, the student must examine the execution of the instructions in AddEm() itself, but she will not be able to see the C source code. Here's another gdb session: 2108: Q1 > gdb Q1main (gdb) break main Breakpoint 1 at 0x80483cd: file Q1main.c, line 6. (gdb) break AddEm Breakpoint 2 at 0x804843a Pause when AddEm() is called. (gdb) run Starting program: /home/jillhokie/hw10/q1/q1main Breakpoint 1, main () at Q1main.c:6 6 int Sz = 5; (gdb) continue Continuing. Breakpoint 2, 0x a in AddEm () (gdb) disassem Let's look at AddEm() as x86 code. Dump of assembler code for function AddEm: 0x <+0>: push %ebp 0x <+1>: mov %esp,%ebp 0x <+3>: sub $0x10,%esp => 0x a <+6>: movl $0x0,-0x4(%ebp) 0x <+13>: mov 0xc(%ebp),%eax 0x <+16>: shl $0x2,%eax 0x <+19>: add 0x8(%ebp),%eax 0x a <+22>: mov %eax,-0x8(%ebp) 0x d <+25>: jmp 0x804845b <AddEm+39> 0x f <+27>: mov 0x8(%ebp),%eax Stack frame setup nor relevant. Here's the next instruction to be executed. Looks like we have parameters at ebp + 8 and ebp

3 0x <+30>: mov (%eax),%eax 0x <+32>: add %eax,-0x4(%ebp) 0x <+35>: addl $0x1,0x8(%ebp) 0x b <+39>: mov 0x8(%ebp),%eax 0x e <+42>: cmp -0x8(%ebp),%eax 0x <+45>: jb 0x804844f <AddEm+27> 0x <+47>: mov -0x4(%ebp),%eax 0x <+50>: leave 0x <+51>: ret End of assembler dump. (gdb) p/x $ebp + 8 $1 = 0xffffd7d0 (gdb) p/x $ebp + 12 $2 = 0xffffd7d4 (gdb) p/x *($ebp + 12) Attempt to dereference a generic pointer. Looks like we have local variables at ebp - 4 and ebp - 8 I can print register contents! Note use of '$'. And I can print expressions using register names! Now, $ebp + 12 is the address of a word on the stack, presumably it's the second parameter, Sz. Oops need a typecast! (gdb) p/x *(int*)($ebp + 12) $3 = 0x5 (gdb) p/x *(int*)($ebp + 8) $4 = 0xffffd7e4 (gdb) p *$4 $5 = 32 (gdb) p *$4@5 $6 = {32, 16, 64, 4, 8} Yes, that's Sz! And that's the address of the array! I can refer to previously-displayed values by the symbolic names gdb gives them. Now, AddEm() must compute the sum of the array values examining the x86 code above suggests where this is being done: => 0x a <+6>: movl $0x0,-0x4(%ebp) # sum? 0x <+13>: mov 0xc(%ebp),%eax # get array size 0x <+16>: shl $0x2,%eax # multiply it by 4? 0x <+19>: add 0x8(%ebp),%eax # add to array address? 0x a <+22>: mov %eax,-0x8(%ebp) # put in local variable 0x d <+25>: jmp 0x804845b <AddEm+39> # jump to loop test 0x f <+27>: mov 0x8(%ebp),%eax # loop start 0x <+30>: mov (%eax),%eax # retrieve value 0x <+32>: add %eax,-0x4(%ebp) # add it to sum 0x <+35>: addl $0x1,0x8(%ebp) # add 1 to ptr 0x b <+39>: mov 0x8(%ebp),%eax # fetch pointer 0x e <+42>: cmp -0x8(%ebp),%eax # loop test 0x <+45>: jb 0x804844f <AddEm+27> It looks like the sum is being accumulated in a local variable at $ebp 4. And it looks like we're storing a pointer into the array at $ebp + 8 (making the parameter serve double duty). Now, if so, we can trace through the code for AddEm() with some understanding of what's going on there. But, we have to use the right gdb commands to step through the assembly code. 3

4 0x in AddEm () 0x in AddEm () 0x in AddEm () 0x a in AddEm () 0x d in AddEm () I can tell what s being executed by comparing the instruction addresses shown after each ni command to the disassembly of the code. (gdb) disassem 0x a <+6>: movl $0x0,-0x4(%ebp) 0x <+13>: mov 0xc(%ebp),%eax 0x <+16>: shl $0x2,%eax 0x <+19>: add 0x8(%ebp),%eax 0x a <+22>: mov %eax,-0x8(%ebp) => 0x d <+25>: jmp 0x804845b <AddEm+39> 0x f <+27>: mov 0x8(%ebp),%eax 0x <+30>: mov (%eax),%eax 0x <+32>: add %eax,-0x4(%ebp) 0x <+35>: addl $0x1,0x8(%ebp) 0x b <+39>: mov 0x8(%ebp),%eax 0x e <+42>: cmp -0x8(%ebp),%eax 0x <+45>: jb 0x804844f <AddEm+27> 0x <+47>: mov -0x4(%ebp),%eax 0x <+50>: leave 0x <+51>: ret The value at $ebp 8 is used in the loop test what is it? What does 0xffffd7f8 have to do with anything wait 0xffffd7f8 0xffffd7e4 is 0x14 or 20 that s the size of the array (in bytes) (gdb) p/x *(int*)($ebp - 8) $8 = 0xffffd7f8 0x b in AddEm () 0x e in AddEm () 0x in AddEm () 0x f in AddEm () 0x in AddEm () (gdb) p/x $eax $10 = 0xffffd7e4 0x in AddEm () (gdb) p/x $eax $11 = 0x20 (gdb) p $eax $12 = 32 Use ni to step through the machine code again. I've stepped to the instruction at 0x f: mov 0x8(%ebp),%eax Step once more to execute that instruction OK, eax stores the address of the array, which I displayed earlier Step again, to execute mov (%eax),%eax and I just loaded the first value from the array. 0x in AddEm () (gdb) 0x b in AddEm () 4

5 (gdb) p *(int*)($ebp - 4) $14 = 32 0x e in AddEm () 0x in AddEm () 0x f in AddEm () 0x in AddEm () 0x in AddEm () 0x in AddEm () (gdb) p *(int*)($ebp - 4) $15 = (gdb) p $eax $16 = (gdb) p/x *(int*)($ebp + 8) $18 = 0xffffd7e5 I just executed add %eax,-0x4(%ebp) and I m pretty sure that Sum is the local at $ebp 4; OK, the sum is now 32 correct so far. I ll step through the loop again and see what happens on the second pass there s the instruction that updates the sum. OK, Sum is now wildly wrong That's what I just added to Sum that's badly wrong too! And that tells me why Now, that last display is the essential clue the student needed to deduce what was wrong with the implementation of AddEm(). Of course, she might want to further reverse-engineer C from the x86 code to verify her conclusion. a) [10 points] Given the gdb sessions displayed above, what conclusion should the student have reached about the error in the implementation of AddEm()? b) [16 points] Justify your conclusion for part a) carefully. Your justification should definitely cite relevant information from the gdb sessions, and possibly also involve some reverse-engineering of the x86 code. 5

6 2. Another student is testing an implementation of the following C function: /** * Fills array A of dimension Sz with integer squares. * Pre: * A points to an array of dimension Sz (or larger) * Post: * A[k] = k * k, for k = 0:Sz-1 */ void WriteSquares(int* const A, int Sz); As in question 1, the student only has an object file for the function implementation. However, in this case it appears that the implementation does what is required. However, the student suspects his testing may be missing an arraybounds error within the implementation of WriteSquares(). So, the student writes some clever code to see if his hunch about the implementation is correct: The cleverness in this code is that the student has guaranteed that there is a known value (a canary value) just before the first element of the array, and just after the last element of the array. If the implementation of WriteSquares() does violate the array bounds, we should see a change in one or both of the canary values after WriteSquares() returns. #include <stdlib.h> #define CANARY 0XDEADBEEF #include "WriteSquares.h" int main() { DEADBEEF int Sz = 100; int* MemoryBlock = malloc(sz * sizeof(int) + 8); if ( MemoryBlock == NULL ) return 1; *MemoryBlock = CANARY; *(MemoryBlock + 101) = CANARY; int* A = MemoryBlock + 1; DEADBEEF // We suspect this function may contain a bug // (or two), and it may write outside the proper // boundaries of the array A of dimension Sz: WriteSquares(A, Sz); } free(memoryblock); return 0; a) [13 points] Use gdb to examine the results of the call to WriteSquares(). Hint: setting an appropriate watchpoint in gdb can yield a very fast resolution of the question. b) [13 points] Use gdb or objdump to analyze what's wrong with the implementation of WriteSquares(). You must show your gdb session, or your output from objdump and reverse-engineering to support your conclusion. 6

7 3. The directory Q3 (created when you unpacked the tar file referred to above) contains three files: Q3main.c, Q3.h and Q3.o. The object file contains the compiled code for the function Q3() declared in the header file. Q3main.c contains a main() function designed to call Q3(); read the comments in Q3main.c. Experiment a bit with the code; you will discover that running Q3main results in a runtime error, unless you get very lucky and use a parameter to Q3() that satisfies a particular constraint. You must determine what constraint the parameter to Q3() must satisfy in order to avoid the runtime error. Brute force attacks can answer the question and will receive no credit. There are several ways to analyze this situation, and you have a number of tools available to aid you. You can use gdb to examine the execution of the code. You can also use objdump,with the d switch, to display the assembly code for an object or executable file. You must state the constraint the parameter to Q3() must satisfy and show what rational analysis you performed to determine the constraint. You can justify your conclusion by showing a transcript of a gdb session and/or showing objdump output with an analysis of the x86 assembly code. (It's easy to copy text from a Linux shell window and paste it into a text editor.) a) [8 points] Identify the exact assembly/machine instruction within Q3() at which the runtime error occurs. Show exactly how you determined your answer. b) [8 points] Analyze the instruction you identified in part a), and explain exactly why executing this instruction would cause a runtime error. c) [8 points] For what parameter value(s) will Q3() not trigger a segmentation fault? Show exactly how you determined your answer(s) to this question; guessing is not a valid technique, nor is experimentation with different parameter values. 4. Repeat question 1, but with the files Q4main.c, Q4.h and Q4.o. a) [8 points] Identify the exact assembly/machine instruction within Q4() at which the runtime error occurs. Show exactly how you determined your answer. b) [8 points] Analyze the instruction you identified in part a), and explain exactly why executing this instruction would cause a runtime error. c) [8 points] For what parameter value(s) will Q4() not trigger a segmentation fault? Show exactly how you determined your answer(s) to this question; guessing is not a valid technique, nor is experimentation with different parameter values. 7