Programming in C. Lecture 9: Tooling. Dr Neel Krishnaswami. Michaelmas Term

Similar documents
Class Information ANNOUCEMENTS

CSCI-243 Exam 1 Review February 22, 2015 Presented by the RIT Computer Science Community

Dynamic code analysis tools

ECE 15B COMPUTER ORGANIZATION

EL2310 Scientific Programming

Memory Analysis tools

CSC C69: OPERATING SYSTEMS

Advanced Debugging and the Address Sanitizer

Memory Corruption 101 From Primitives to Exploit

Programming in C and C++

New features in AddressSanitizer. LLVM developer meeting Nov 7, 2013 Alexey Samsonov, Kostya Serebryany

Use Dynamic Analysis Tools on Linux

C Programming. Course Outline. C Programming. Code: MBD101. Duration: 10 Hours. Prerequisites:

Undefined Behaviour in C

TI2725-C, C programming lab, course

Recitation: C Review. TA s 20 Feb 2017

A program execution is memory safe so long as memory access errors never occur:

Deep C (and C++) by Olve Maudal

Recitation #11 Malloc Lab. November 7th, 2017

Contents of Lecture 3

Quiz 0 Review Session. October 13th, 2014

CSC 1600 Memory Layout for Unix Processes"

DAY 3. CS3600, Northeastern University. Alan Mislove

18-642: Code Style for Compilers

CS 261 Fall C Introduction. Variables, Memory Model, Pointers, and Debugging. Mike Lam, Professor

Lecture 03 Bits, Bytes and Data Types

Deep C by Olve Maudal

Hacking in C. Pointers. Radboud University, Nijmegen, The Netherlands. Spring 2019

Lecture 2: C Programm

Programming in C and C++

Lecture 4: Outline. Arrays. I. Pointers II. III. Pointer arithmetic IV. Strings

Data Type Fall 2014 Jinkyu Jeong

NETWORK AND SYSTEM PROGRAMMING

CS61, Fall 2012 Section 2 Notes

Pointers and Memory Management

Lecture Notes on Types in C

Hacking in C. Memory layout. Radboud University, Nijmegen, The Netherlands. Spring 2018

CSci 4061 Introduction to Operating Systems. Programs in C/Unix

Programming in C. 3. Pointers and Structures. Dr. Neel Krishnaswami University of Cambridge

Lecture 07 Debugging Programs with GDB

Announcements. assign0 due tonight. Labs start this week. No late submissions. Very helpful for assign1

INITIALISING POINTER VARIABLES; DYNAMIC VARIABLES; OPERATIONS ON POINTERS

ELEC / COMP 177 Fall Some slides from Kurose and Ross, Computer Networking, 5 th Edition

Runtime Defenses against Memory Corruption

Identifying Memory Corruption Bugs with Compiler Instrumentations. 이병영 ( 조지아공과대학교

Dynamic Memory CMSC 104 Spring 2014, Section 02, Lecture 24 Jason Tang

18-600: Recitation #3

COMP 2355 Introduction to Systems Programming

Lecture Notes on Polymorphism

SOFTWARE Ph.D. Qualifying Exam Spring Consider the following C program which consists of two function definitions including the main function.

CMSC 341 Lecture 2 Dynamic Memory and Pointers

Recitation: Cache Lab & C

AGENDA Binary Operations CS 3330 Samira Khan

Recitation 2/18/2012

High-performance computing and programming Intro to C on Unix/Linux. Uppsala universitet

Programming refresher and intro to C programming

CSCI-1200 Data Structures Spring 2016 Lecture 6 Pointers & Dynamic Memory

Memory Management. CSC215 Lecture

IMPORTANT QUESTIONS IN C FOR THE INTERVIEW

C Introduction. Comparison w/ Java, Memory Model, and Pointers

DEBUGGING: DYNAMIC PROGRAM ANALYSIS

C Tutorial. Pointers, Dynamic Memory allocation, Valgrind, Makefile - Abhishek Yeluri and Yashwant Reddy Virupaksha

COMP26120: Linked List in C (2018/19) Lucas Cordeiro

Malloc Lab & Midterm Solutions. Recitation 11: Tuesday: 11/08/2016

Copyright 2015 MathEmbedded Ltd.r. Finding security vulnerabilities by fuzzing and dynamic code analysis

CS24 Week 2 Lecture 1

OSI Network Layer. Network Fundamentals Chapter 5. Version Cisco Systems, Inc. All rights reserved. Cisco Public 1

Lecture 19 Notes Data Structures in C

Programming in C S c o t t S c h r e m m e r

o Code, executable, and process o Main memory vs. virtual memory

Structures, Unions Alignment, Padding, Bit Fields Access, Initialization Compound Literals Opaque Structures Summary. Structures

Data Structures in C. C Programming and Software Tools. N.C. State Department of Computer Science

Exercise Session 2 Simon Gerber

ECE 250 / CS 250 Computer Architecture. C to Binary: Memory & Data Representations. Benjamin Lee

ECE4110 Internetwork Programming. Introduction and Overview

CSE 333 Lecture 2 Memory

CS 314 Principles of Programming Languages. Lecture 11

18-642: Code Style for Compilers

Lecture 05 Integer overflow. Stephen Checkoway University of Illinois at Chicago

In Java we have the keyword null, which is the value of an uninitialized reference type

Lecture 20 C s Memory Model

[0569] p 0318 garbage

Programming in C++ 5. Integral data types

Pointer Casts and Data Accesses

Lecture 14 Notes. Brent Edmunds

Finding Bugs Using Xcode Runtime Tools

6.S096: Introduction to C/C++

Key C Topics: Tutorial Pointers, Dynamic Memory allocation, Valgrind and Makefile CS370

Lecture 20 Notes C s Memory Model

Programming in C. Lecture 5: Aliasing, Graphs, and Deallocation. Dr Neel Krishnaswami. Michaelmas Term University of Cambridge

CS61C : Machine Structures

Solution Manual for Data Structures and Problem Solving Using C++ 2nd edition by Mark A. Weiss

C++ Undefined Behavior

ECE 598 Advanced Operating Systems Lecture 12

CS 61c: Great Ideas in Computer Architecture

CS 61C: Great Ideas in Computer Architecture. C Arrays, Strings, More Pointers

Linux Programming

15-122: Principles of Imperative Computation, Spring Written Homework 12. Due: Sunday 15 th April, 2018 by 10pm. Name: Andrew ID: Section:

Lecture 3: C Programm

CS C Primer. Tyler Szepesi. January 16, 2013

Transcription:

Programming in C Lecture 9: Tooling Dr Neel Krishnaswami Michaelmas Term 2017-2018 1 / 24

Undefined and Unspecified Behaviour 2 / 24

Undefined and Unspecified Behaviour We have seen that C is an unsafe language 2 / 24

Undefined and Unspecified Behaviour We have seen that C is an unsafe language Programming errors can arbitrarily corrupt runtime data structures... 2 / 24

Undefined and Unspecified Behaviour We have seen that C is an unsafe language Programming errors can arbitrarily corrupt runtime data structures...... leading to undefined behaviour 2 / 24

Undefined and Unspecified Behaviour We have seen that C is an unsafe language Programming errors can arbitrarily corrupt runtime data structures...... leading to undefined behaviour Enormous number of possible sources of undefined behavior (See https://blog.regehr.org/archives/1520) 2 / 24

Undefined and Unspecified Behaviour We have seen that C is an unsafe language Programming errors can arbitrarily corrupt runtime data structures...... leading to undefined behaviour Enormous number of possible sources of undefined behavior (See https://blog.regehr.org/archives/1520) What can we do about it? 2 / 24

Tooling and Instrumentation We have seen that C is an unsafe language Programming errors can arbitrarily corrupt runtime data structures...... leading to undefined behaviour There is a great deal of undefined behaviour 3 / 24

Tooling and Instrumentation We have seen that C is an unsafe language Programming errors can arbitrarily corrupt runtime data structures...... leading to undefined behaviour There is a great deal of undefined behaviour Add instrumentation to detect unsafe behaviour! 3 / 24

Tooling and Instrumentation We have seen that C is an unsafe language Programming errors can arbitrarily corrupt runtime data structures...... leading to undefined behaviour There is a great deal of undefined behaviour Add instrumentation to detect unsafe behaviour! We will look at 3 tools: ASan, UBSan, and Valgrind 3 / 24

ASan: Address Sanitizer 4 / 24

ASan: Address Sanitizer One of the leading causes of errors in C is memory corruption: 4 / 24

ASan: Address Sanitizer One of the leading causes of errors in C is memory corruption: Out-of-bounds array accesses 4 / 24

ASan: Address Sanitizer One of the leading causes of errors in C is memory corruption: Out-of-bounds array accesses Use pointer after call to free() 4 / 24

ASan: Address Sanitizer One of the leading causes of errors in C is memory corruption: Out-of-bounds array accesses Use pointer after call to free() Use stack variable after it is out of scope 4 / 24

ASan: Address Sanitizer One of the leading causes of errors in C is memory corruption: Out-of-bounds array accesses Use pointer after call to free() Use stack variable after it is out of scope Double-frees or other invalid frees 4 / 24

ASan: Address Sanitizer One of the leading causes of errors in C is memory corruption: Out-of-bounds array accesses Use pointer after call to free() Use stack variable after it is out of scope Double-frees or other invalid frees Memory leaks 4 / 24

ASan: Address Sanitizer One of the leading causes of errors in C is memory corruption: Out-of-bounds array accesses Use pointer after call to free() Use stack variable after it is out of scope Double-frees or other invalid frees Memory leaks AddressSanitizer instruments code to detect these errors 4 / 24

ASan: Address Sanitizer One of the leading causes of errors in C is memory corruption: Out-of-bounds array accesses Use pointer after call to free() Use stack variable after it is out of scope Double-frees or other invalid frees Memory leaks AddressSanitizer instruments code to detect these errors Need to recompile 4 / 24

ASan: Address Sanitizer One of the leading causes of errors in C is memory corruption: Out-of-bounds array accesses Use pointer after call to free() Use stack variable after it is out of scope Double-frees or other invalid frees Memory leaks AddressSanitizer instruments code to detect these errors Need to recompile Adds runtime overhead 4 / 24

ASan: Address Sanitizer One of the leading causes of errors in C is memory corruption: Out-of-bounds array accesses Use pointer after call to free() Use stack variable after it is out of scope Double-frees or other invalid frees Memory leaks AddressSanitizer instruments code to detect these errors Need to recompile Adds runtime overhead Use it while developing 4 / 24

ASan: Address Sanitizer One of the leading causes of errors in C is memory corruption: Out-of-bounds array accesses Use pointer after call to free() Use stack variable after it is out of scope Double-frees or other invalid frees Memory leaks AddressSanitizer instruments code to detect these errors Need to recompile Adds runtime overhead Use it while developing Built into gcc and clang! 4 / 24

ASan Example #1 1 #include <stdlib.h> 2 #include <stdio.h> 3 4 #define N 10 5 6 int main(void) { 7 char s[n] = "123456789"; 8 for (int i = 0; i <= N; i++) 9 printf ("%c", s[i]); 0 printf("\n"); 1 return 0; 2 } 5 / 24

ASan Example #1 1 #include <stdlib.h> 2 #include <stdio.h> 3 4 #define N 10 5 6 int main(void) { 7 char s[n] = "123456789"; 8 for (int i = 0; i <= N; i++) 9 printf ("%c", s[i]); 0 printf("\n"); 1 return 0; 2 } Loop bound goes past the end of the array 5 / 24

ASan Example #1 1 #include <stdlib.h> 2 #include <stdio.h> 3 4 #define N 10 5 6 int main(void) { 7 char s[n] = "123456789"; 8 for (int i = 0; i <= N; i++) 9 printf ("%c", s[i]); 0 printf("\n"); 1 return 0; 2 } Loop bound goes past the end of the array Undefined behaviour! 5 / 24

ASan Example #1 1 #include <stdlib.h> 2 #include <stdio.h> 3 4 #define N 10 5 6 int main(void) { 7 char s[n] = "123456789"; 8 for (int i = 0; i <= N; i++) 9 printf ("%c", s[i]); 0 printf("\n"); 1 return 0; 2 } Loop bound goes past the end of the array Undefined behaviour! Compile with -fsanitize=address 5 / 24

ASan Example #2 1 #include <stdlib.h> 2 3 int main(void) { 4 int *a = 5 malloc(sizeof(int) * 100); 6 free(a); 7 return a[5]; // DOOM! 8 } 6 / 24

ASan Example #2 1 #include <stdlib.h> 2 3 int main(void) { 4 int *a = 5 malloc(sizeof(int) * 100); 6 free(a); 7 return a[5]; // DOOM! 8 } 1. array is allocated 6 / 24

ASan Example #2 1 #include <stdlib.h> 2 3 int main(void) { 4 int *a = 5 malloc(sizeof(int) * 100); 6 free(a); 7 return a[5]; // DOOM! 8 } 1. array is allocated 2. array is freed 6 / 24

ASan Example #2 1 #include <stdlib.h> 2 3 int main(void) { 4 int *a = 5 malloc(sizeof(int) * 100); 6 free(a); 7 return a[5]; // DOOM! 8 } 1. array is allocated 2. array is freed 3. array is dereferenced! 6 / 24

ASan Example #2 1 #include <stdlib.h> 2 3 int main(void) { 4 int *a = 5 malloc(sizeof(int) * 100); 6 free(a); 7 return a[5]; // DOOM! 8 } 7 / 24

ASan Example #2 1 #include <stdlib.h> 2 3 int main(void) { 4 int *a = 5 malloc(sizeof(int) * 100); 6 free(a); 7 return a[5]; // DOOM! 8 } 1. array is allocated 7 / 24

ASan Example #2 1 #include <stdlib.h> 2 3 int main(void) { 4 int *a = 5 malloc(sizeof(int) * 100); 6 free(a); 7 return a[5]; // DOOM! 8 } 1. array is allocated 2. array is freed 7 / 24

ASan Example #2 1 #include <stdlib.h> 2 3 int main(void) { 4 int *a = 5 malloc(sizeof(int) * 100); 6 free(a); 7 return a[5]; // DOOM! 8 } 1. array is allocated 2. array is freed 3. array is dereferenced! 7 / 24

ASan Example #3 1 #include <stdlib.h> 2 3 int main(void) { 4 char *s = 5 malloc(sizeof(char) * 10); 6 free(s); 7 free(s); 8 printf("%s", s); 9 return 0; 0 } 8 / 24

ASan Example #3 1 #include <stdlib.h> 2 3 int main(void) { 4 char *s = 5 malloc(sizeof(char) * 10); 6 free(s); 7 free(s); 8 printf("%s", s); 9 return 0; 0 } 1. array is allocated 8 / 24

ASan Example #3 1 #include <stdlib.h> 2 3 int main(void) { 4 char *s = 5 malloc(sizeof(char) * 10); 6 free(s); 7 free(s); 8 printf("%s", s); 9 return 0; 0 } 1. array is allocated 2. array is freed 8 / 24

ASan Example #3 1 #include <stdlib.h> 2 3 int main(void) { 4 char *s = 5 malloc(sizeof(char) * 10); 6 free(s); 7 free(s); 8 printf("%s", s); 9 return 0; 0 } 1. array is allocated 2. array is freed 3. array is double-freed 8 / 24

ASan Limitations 9 / 24

ASan Limitations Must recompile code 9 / 24

ASan Limitations Must recompile code Adds considerable runtime overhead 9 / 24

ASan Limitations Must recompile code Adds considerable runtime overhead Does not catch all memory errors 9 / 24

ASan Limitations Must recompile code Adds considerable runtime overhead Does not catch all memory errors NEVER catches unitialized memory accesses 9 / 24

ASan Limitations Must recompile code Adds considerable runtime overhead Does not catch all memory errors NEVER catches unitialized memory accesses NEVER catches unitialized memory accesses 9 / 24

ASan Limitations Must recompile code Adds considerable runtime overhead Does not catch all memory errors NEVER catches unitialized memory accesses NEVER catches unitialized memory accesses Still: a must-use tool during development 9 / 24

UBSan: Undefined Behaviour Sanitizer 10 / 24

UBSan: Undefined Behaviour Sanitizer There is lots of non-memory-related undefined behaviour in C: 10 / 24

UBSan: Undefined Behaviour Sanitizer There is lots of non-memory-related undefined behaviour in C: Signed integer overflow 10 / 24

UBSan: Undefined Behaviour Sanitizer There is lots of non-memory-related undefined behaviour in C: Signed integer overflow Dereferencing null pointers 10 / 24

UBSan: Undefined Behaviour Sanitizer There is lots of non-memory-related undefined behaviour in C: Signed integer overflow Dereferencing null pointers Pointer arithmetic overflow 10 / 24

UBSan: Undefined Behaviour Sanitizer There is lots of non-memory-related undefined behaviour in C: Signed integer overflow Dereferencing null pointers Pointer arithmetic overflow Dynamic arrays whose size is non-positive 10 / 24

UBSan: Undefined Behaviour Sanitizer There is lots of non-memory-related undefined behaviour in C: Signed integer overflow Dereferencing null pointers Pointer arithmetic overflow Dynamic arrays whose size is non-positive Undefined Behaviour Sanitizer (UBSan) instruments code to detect these errors 10 / 24

UBSan: Undefined Behaviour Sanitizer There is lots of non-memory-related undefined behaviour in C: Signed integer overflow Dereferencing null pointers Pointer arithmetic overflow Dynamic arrays whose size is non-positive Undefined Behaviour Sanitizer (UBSan) instruments code to detect these errors Need to recompile 10 / 24

UBSan: Undefined Behaviour Sanitizer There is lots of non-memory-related undefined behaviour in C: Signed integer overflow Dereferencing null pointers Pointer arithmetic overflow Dynamic arrays whose size is non-positive Undefined Behaviour Sanitizer (UBSan) instruments code to detect these errors Need to recompile Adds runtime overhead 10 / 24

UBSan: Undefined Behaviour Sanitizer There is lots of non-memory-related undefined behaviour in C: Signed integer overflow Dereferencing null pointers Pointer arithmetic overflow Dynamic arrays whose size is non-positive Undefined Behaviour Sanitizer (UBSan) instruments code to detect these errors Need to recompile Adds runtime overhead Use it while developing 10 / 24

UBSan: Undefined Behaviour Sanitizer There is lots of non-memory-related undefined behaviour in C: Signed integer overflow Dereferencing null pointers Pointer arithmetic overflow Dynamic arrays whose size is non-positive Undefined Behaviour Sanitizer (UBSan) instruments code to detect these errors Need to recompile Adds runtime overhead Use it while developing Built into gcc and clang! 10 / 24

UBSan Example #1 1 #include <limits.h> 2 3 int main(void) { 4 int n = INT_MAX; 5 int m = n + 1; 6 return 0; 7 } 11 / 24

UBSan Example #1 1 #include <limits.h> 2 3 int main(void) { 4 int n = INT_MAX; 5 int m = n + 1; 6 return 0; 7 } 1. Signed integer overflow is undefined 11 / 24

UBSan Example #1 1 #include <limits.h> 2 3 int main(void) { 4 int n = INT_MAX; 5 int m = n + 1; 6 return 0; 7 } 1. Signed integer overflow is undefined 2. So value of m is undefined 11 / 24

UBSan Example #1 1 #include <limits.h> 2 3 int main(void) { 4 int n = INT_MAX; 5 int m = n + 1; 6 return 0; 7 } 1. Signed integer overflow is undefined 2. So value of m is undefined 3. Compile with -fsanitize=address 11 / 24

UBSan Example #2 1 #include <limits.h> 2 3 int main(void) { 4 int n = 65 5 int m = n / (n - n); 6 return 0; 7 } 12 / 24

UBSan Example #2 1 #include <limits.h> 2 3 int main(void) { 4 int n = 65 5 int m = n / (n - n); 6 return 0; 7 } 1. Division-by-zero is undefined 12 / 24

UBSan Example #2 1 #include <limits.h> 2 3 int main(void) { 4 int n = 65 5 int m = n / (n - n); 6 return 0; 7 } 1. Division-by-zero is undefined 2. So value of m is undefined 12 / 24

UBSan Example #2 1 #include <limits.h> 2 3 int main(void) { 4 int n = 65 5 int m = n / (n - n); 6 return 0; 7 } 1. Division-by-zero is undefined 2. So value of m is undefined 3. Any possible behaviour is legal! 12 / 24

UBSan Example #3 1 #include <stdlib.h> 2 3 struct foo { 4 int a, b; 5 }; 6 7 int main(void) { 8 struct foo *x = NULL; 9 int m = x->a; 0 return 0; 1 } 13 / 24

UBSan Example #3 1 #include <stdlib.h> 2 3 struct foo { 4 int a, b; 5 }; 1. Accessing a null pointer is undefined 6 7 int main(void) { 8 struct foo *x = NULL; 9 int m = x->a; 0 return 0; 1 } 13 / 24

UBSan Example #3 1 #include <stdlib.h> 2 3 struct foo { 4 int a, b; 5 }; 6 7 int main(void) { 8 struct foo *x = NULL; 9 int m = x->a; 0 return 0; 1 } 1. Accessing a null pointer is undefined 2. So accessing fields of x is undefined 13 / 24

UBSan Example #3 1 #include <stdlib.h> 2 3 struct foo { 4 int a, b; 5 }; 6 7 int main(void) { 8 struct foo *x = NULL; 9 int m = x->a; 0 return 0; 1 } 1. Accessing a null pointer is undefined 2. So accessing fields of x is undefined 3. Any possible behaviour is legal! 13 / 24

UBSan Limitations 14 / 24

UBSan Limitations Must recompile code 14 / 24

UBSan Limitations Must recompile code Adds modest runtime overhead 14 / 24

UBSan Limitations Must recompile code Adds modest runtime overhead Does not catch all undefined behaviour 14 / 24

UBSan Limitations Must recompile code Adds modest runtime overhead Does not catch all undefined behaviour Still: a must-use tool during development 14 / 24

UBSan Limitations Must recompile code Adds modest runtime overhead Does not catch all undefined behaviour Still: a must-use tool during development Seriously consider using it in production 14 / 24

Valgrind 15 / 24

Valgrind UBSan and ASan require recompiling 15 / 24

Valgrind UBSan and ASan require recompiling UBSan and ASan don t catch accesses to unitialized memory 15 / 24

Valgrind UBSan and ASan require recompiling UBSan and ASan don t catch accesses to unitialized memory Enter Valgrind! 15 / 24

Valgrind UBSan and ASan require recompiling UBSan and ASan don t catch accesses to unitialized memory Enter Valgrind! Instruments binaries to detect numerous errors 15 / 24

Valgrind Example 1 #include <stdio.h> 2 3 int main(void) { 4 char s[10]; 5 for (int i = 0; i < 10; i++) 6 printf("%c", s[i]); 7 printf("\n"); 8 return 0; 9 } 16 / 24

Valgrind Example 1 #include <stdio.h> 2 3 int main(void) { 4 char s[10]; 5 for (int i = 0; i < 10; i++) 6 printf("%c", s[i]); 7 printf("\n"); 8 return 0; 9 } 1. Accessing elements of s is undefined 16 / 24

Valgrind Example 1 #include <stdio.h> 2 3 int main(void) { 4 char s[10]; 5 for (int i = 0; i < 10; i++) 6 printf("%c", s[i]); 7 printf("\n"); 8 return 0; 9 } 1. Accessing elements of s is undefined 2. Program prints unitialized memory 16 / 24

Valgrind Example 1 #include <stdio.h> 2 3 int main(void) { 4 char s[10]; 5 for (int i = 0; i < 10; i++) 6 printf("%c", s[i]); 7 printf("\n"); 8 return 0; 9 } 1. Accessing elements of s is undefined 2. Program prints unitialized memory 3. Any possible behaviour is legal! 16 / 24

Valgrind Example 1 #include <stdio.h> 2 3 int main(void) { 4 char s[10]; 5 for (int i = 0; i < 10; i++) 6 printf("%c", s[i]); 7 printf("\n"); 8 return 0; 9 } 1. Accessing elements of s is undefined 2. Program prints unitialized memory 3. Any possible behaviour is legal! 4. Invoke valgrind with binary name 16 / 24

Valgrind Limitations 17 / 24

Valgrind Limitations Adds very substantial runtime overhead 17 / 24

Valgrind Limitations Adds very substantial runtime overhead Not built into GCC/clang (plus or minus?) 17 / 24

Valgrind Limitations Adds very substantial runtime overhead Not built into GCC/clang (plus or minus?) As usual, does not catch all undefined behaviour 17 / 24

Valgrind Limitations Adds very substantial runtime overhead Not built into GCC/clang (plus or minus?) As usual, does not catch all undefined behaviour Still: a must-use tool during testing 17 / 24

Assessed Exercise See Head of Department s Announcement To be completed by noon on Monday 22 January 2018 Viva examinations 1330-1630 on Thursday 25 January 2018 Viva examinations 1330-1630 on Friday 26 January 2018 Download the starter pack from: http://www.cl.cam.ac.uk/teaching/1718/progc++/ This should contain eight files: server.c client.c rfc0791.txt rfc0793.txt message1 message2 message3 message4 18 / 24

Exercise aims Demonstrate an ability to: Understand (simple) networking code Use control flow, functions, structures and pointers Use libraries, including reading and writing files Understand a specification Compile and test code Comprehending man pages Task is split into three parts: Comprehension and debugging Preliminary analysis Completed code and testing 19 / 24

Exercise submission Assessment is in the form of a tick There will be a short viva; remember to sign up! Submission is via email to c-tick@cl.cam.ac.uk Your submission should include seven files, packed in to a ZIP file called crsid.zip and attached to your submission email: answers.txt client1.c summary.c message1.txt server1.c extract.c message2.jpg 20 / 24

Hints: IP header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version IHL Type of Service Total Length +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Identification Flags Fragment Offset +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Time to Live Protocol Header Checksum +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Destination Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Options Padding +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 21 / 24

Hints: IP header (in C) 1 #include <stdint.h> 2 3 struct ip { 4 uint8_t hlenver; 5 uint8_t tos; 6 uint16_t len; 7 uint16_t id; 8 uint16_t off; 9 uint8_t ttl; 10 uint8_t p; 11 uint16_t sum; 12 uint32_t src; 13 uint32_t dst; 14 }; 15 16 #define IP_HLEN(lenver) (lenver & 0x0f) 17 #define IP_VER(lenver) (lenver >> 4) 22 / 24

Hints: network byte order The IP network is big-endian; x86 is little-endian; ARM can be either Reading multi-byte values requires possible conversion The BSD API specifies: uint16_t ntohs(uint16_t netshort) uint32_t ntohl(uint32_t netlong) uint16_t htons(uint16_t hostshort) uint32_t htonl(uint32_t hostlong) which encapsulate the notions of host and network and their interconversion (which may be a no-op) 23 / 24