ECE 598 Advanced Operating Systems Lecture 10

Similar documents
ECE 598 Advanced Operating Systems Lecture 11

ECE 471 Embedded Systems Lecture 4

ECE 471 Embedded Systems Lecture 5

ECE 498 Linux Assembly Language Lecture 1

ECE 471 Embedded Systems Lecture 6

ECE 598 Advanced Operating Systems Lecture 2

ECE 598 Advanced Operating Systems Lecture 10

Process Environment. Pradipta De

ECE 471 Embedded Systems Lecture 12

Operating Systems CMPSC 473. Process Management January 29, Lecture 4 Instructor: Trent Jaeger

ECE 471 Embedded Systems Lecture 16

ECE 598 Advanced Operating Systems Lecture 12

ECE 471 Embedded Systems Lecture 16

ECE 598 Advanced Operating Systems Lecture 14

ECE 550D Fundamentals of Computer Systems and Engineering. Fall 2017

OS lpr. www. nfsd gcc emacs ls 1/27/09. Process Management. CS 537 Lecture 3: Processes. Example OS in operation. Why Processes? Simplicity + Speed

CSCI341. Lecture 22, MIPS Programming: Directives, Linkers, Loaders, Memory

Embedded Systems Programming

SYSTEM CALL IMPLEMENTATION. CS124 Operating Systems Fall , Lecture 14

www nfsd emacs lpr Process Management CS 537 Lecture 4: Processes Example OS in operation Why Processes? Simplicity + Speed

CS 550 Operating Systems Spring Process I

Process Address Spaces and Binary Formats

Process Address Spaces and Binary Formats

Applications of. Virtual Memory in. OS Design

ECE 598 Advanced Operating Systems Lecture 14

Virtual Memory Paging

COS 318: Operating Systems

ECE 598 Advanced Operating Systems Lecture 14

ECE 574 Cluster Computing Lecture 8

This lecture is covered in Section 4.1 of the textbook.

Protecting Against Unexpected System Calls

ECE 571 Advanced Microprocessor-Based Design Lecture 12

CSCE Operating Systems Interrupts, Exceptions, and Signals. Qiang Zeng, Ph.D. Fall 2018

CSCI 4061: Virtual Memory

Jan 20, 2005 Lecture 2: Multiprogramming OS

Assembly Language Programming Linkers

OS lpr. www. nfsd gcc emacs ls 9/18/11. Process Management. CS 537 Lecture 4: Processes. The Process. Why Processes? Simplicity + Speed

ECE 598 Advanced Operating Systems Lecture 4

CS24: INTRODUCTION TO COMPUTING SYSTEMS. Spring 2015 Lecture 25

The Software Stack: From Assembly Language to Machine Code

e-pg Pathshala Subject : Computer Science Paper: Embedded System Module: Embedded Software Development Tools Module No: CS/ES/36 Quadrant 1 e-text

Linux Boot Process. Nassim Eddequiouaq LSE Summer Week 2015

ECE 471 Embedded Systems Lecture 22

Operating Systems. 09. Memory Management Part 1. Paul Krzyzanowski. Rutgers University. Spring 2015

Language Translation. Compilation vs. interpretation. Compilation diagram. Step 1: compile. Step 2: run. compiler. Compiled program. program.

Generating Programs and Linking. Professor Rick Han Department of Computer Science University of Colorado at Boulder

ECE 571 Advanced Microprocessor-Based Design Lecture 13

COS 318: Operating Systems. Overview. Andy Bavier Computer Science Department Princeton University

CSC 1600 Memory Layout for Unix Processes"

CSE506: Operating Systems CSE 506: Operating Systems

Requirements, Partitioning, paging, and segmentation

9/19/18. COS 318: Operating Systems. Overview. Important Times. Hardware of A Typical Computer. Today CPU. I/O bus. Network

CSE506: Operating Systems CSE 506: Operating Systems

Porting uclinux to MIPS

Operating Systems. Sina Meraji U of T

Executables and Linking. CS449 Spring 2016

CS 537 Lecture 2 - Processes

Physical memory vs. Logical memory Process address space Addresses assignment to processes Operating system tasks Hardware support CONCEPTS 3.

PROCESS VIRTUAL MEMORY PART 2. CS124 Operating Systems Winter , Lecture 19

ECE 471 Embedded Systems Lecture 4

The Kernel Abstraction. Chapter 2 OSPP Part I

Virtual Memory (Real Memory POV)

ECE 598 Advanced Operating Systems Lecture 22

Today s Big Adventure

Advanced Operating Systems Embedded from Scratch: System boot and hardware access. Federico Terraneo

ECE 598 Advanced Operating Systems Lecture 19

CSE 451: Operating Systems Winter Processes. Gary Kimura

Process Migration. David Zuercher CS555 Distributed Systems

MPATE-GE 2618: C Programming for Music Technology. Unit 4.1

CS 61C: Great Ideas in Computer Architecture CALL continued ( Linking and Loading)

PROCESS VIRTUAL MEMORY. CS124 Operating Systems Winter , Lecture 18

by Marina Cholakyan, Hyduke Noshadi, Sepehr Sahba and Young Cha

seven Virtual Memory Introduction

unsigned char memory[] STACK ¼ 0x xC of address space globals function KERNEL code local variables

Mon Sep 17, 2007 Lecture 3: Process Management

238P: Operating Systems. Lecture 7: Basic Architecture of a Program. Anton Burtsev January, 2018

Lec 13: Linking and Memory. Kavita Bala CS 3410, Fall 2008 Computer Science Cornell University. Announcements

The Early System Start-Up Process. Group Presentation by: Tianyuan Liu, Caiwei He, Krishna Parasuram Srinivasan, Wenbin Xu

Protection and System Calls. Otto J. Anshus

Linking. Explain what ELF format is. Explain what an executable is and how it got that way. With huge thanks to Steve Chong for his notes from CS61.

ECE 598 Advanced Operating Systems Lecture 23

CS61 Scribe Notes Lecture 18 11/6/14 Fork, Advanced Virtual Memory

CS5460/6460: Operating Systems. Lecture 21: Shared libraries. Anton Burtsev March, 2014

Outline. Outline. Common Linux tools to explore object/executable files. Revealing Internals of Loader. Zhiqiang Lin

Memory Allocation. Copyright : University of Illinois CS 241 Staff 1

COS 318: Operating Systems. Overview. Prof. Margaret Martonosi Computer Science Department Princeton University

Operating Systems. II. Processes

OS COMPONENTS OVERVIEW OF UNIX FILE I/O. CS124 Operating Systems Fall , Lecture 2

Today s Big Adventure

Processes. Johan Montelius KTH

Kernel Internals. Course Duration: 5 days. Pre-Requisites : Course Objective: Course Outline

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

Fixing/Making Holes in Binaries

ECE 471 Embedded Systems Lecture 8

TMS470 ARM ABI Migration

Introduction to Operating Systems Prof. Chester Rebeiro Department of Computer Science and Engineering Indian Institute of Technology, Madras

12: Memory Management

A process. the stack

ECE 598 Advanced Operating Systems Lecture 17

A recompilation and instrumentation-free monitoring architecture for detecting heap memory errors and exploits

Transcription:

ECE 598 Advanced Operating Systems Lecture 10 Vince Weaver http://web.eece.maine.edu/~vweaver vincent.weaver@maine.edu 22 February 2018

Announcements Homework #5 will be posted 1

Blocking vs Nonblocking Syscall Blocking system calls program stops, waits for reply before it can continue Nonblocking system call returns right away, although the result might just be no data available What if a blocking system call tried to block inside the kernel with interrupts disabled? Real OS uses queues and wakeups to put processes to sleep when blocking, not just busy spinning. 2

Userspace Executables 3

Executable Format ELF (Executable and Linkable Format, Extensible Linking Format) Default for Linux and some other similar OSes header, then header table describing chunks and where they go Other executable formats: a.out, COFF, binary blob 4

ELF Layout ELF Header Program header Text (Machine Code) Data (Initialized Data) Symbols Debugging Info... Section header 5

ELF Description ELF Header includes a magic number saying it s 0x7f,ELF, architecture type, OS type, etc. Also location of program header and section header and entry point. Program Header, used for execution: has info telling the OS what parts to load, how, and where (address, permission, size, alignment) Program Data follows, describes data actually loaded into memory: machine code, initialized data 6

Other data: things like symbol names, debugging info (DWARF), etc. DWARF backronym = Debugging with Attributed Record Formats Section Header, used when linking: has info on the additional segments in code that aren t loaded into memory, such as debugging, symbols, etc. 7

Linux Virtual Memory Map We will go over virtual memory in much greater detail later. 8

Operating System Exexcutable Info Stack shared libraries vdso mmap Heap BSS Data 0xffff ffff 0xbfff ffff Operating System Environment Strings Cmd Line Arg Strings Executable Name Padding ELF Auxiliary Vectors Environment Pointers Command Line Pointers Cmd Line Arg Count Stack Text (Executable) 0x0804 8000 Null Guard Page 0x0000 0000 9

Program Memory Layout on Linux Text: the program s raw machine code Data: Initialized data BSS: uninitialized data; on Linux this is all set to 0. Heap: dynamic memory. malloc() and brk(). Grows up Stack: LIFO memory structure. Grows down. 10

Program Layout Kernel: is mapped into top of address space, for performance reasons DANGER: MELTDOWN Command Line arguments, Environment, AUX vectors, etc., available above stack For security reasons ASLR (Address Space Layout Randomization) is often enabled. From run to run the exact addresses of all the sections is randomized, to make it harder for hackers to compromise your system. 11

Loader /lib/ld-linux.so.2 loads the executable 12

Static vs Dynamic Libraries Static: includes all code in one binary. Large binaries, need to recompile to update library code, self-contained Dynamic: library routines linked at load time. Smaller binaries, share code across system, automatically links against newer/bugfixes Lots of debate about what is better: apt-get install vs the app-store 13

How Dynamic Linking Works Can read about how things load on Linux here: https: //lwn.net/articles/630727/, https://lwn.net/ Articles/631631/ ELF executable can have interp section, which says to load /lib/ld-linker.so first This loads things up, then initialized dynamic libraries. Links things in place, updates function pointers and shared variables, offset tables, etc. Lazy-Linking is possible. Function calls just call to a 14

stub that calls into linker. Only resolves the link if you actually use it. Why is this a benefit (faster startup, not load things not need). Does add indirection every time you call. 15

How a Program is Loaded on Linux Kernel Boots init started init calls fork() child calls exec() Kernel checks if valid ELF. Passes to loader Possibly not ELF. Shell scripts, etc. 16

Loader loads it. Clears out BSS. Sets up stack. Jumps to entry address (specified by executable) Program runs until complete. Parent process returned to if waiting. Otherwise, init. 17

UCLinux Linux typically relies on MMU (virtual memory). You can run it on systems w/o virtual memory, this version is called uclinux (micro-controller Linux). Our OS in the homework is similar in design to this. 18

Flat File Format http://retired.beyondlogic.org/uclinux/bflt.htm bflt or 0x62, 0x46, 0x4C, 0x54 struct flat_hdr { char magic [4]; unsigned long rev ; /* version */ unsigned long entry ; /* Offset of first executable instruction with text segment from beginning of file */ unsigned long data_start ; /* Offset of data segment from beginning of file */ unsigned long data_end ; /* Offset of end of data segment from beginning of file */ unsigned long bss_end ; /* Offset of end of bss segment from beginning of file */ /* ( It is assumed that data_end through bss_end forms the bss segment.) */ 19

}; unsigned long stack_size ; /* Size of stack, in bytes */ unsigned long reloc_start ; /* Offset of relocation records from beginning of file */ unsigned long reloc_count ; /* Number of relocation records */ unsigned long flags ; unsigned long filler [6]; /* Reserved, set to zero */ 20

Figuring out how it actually works Spec isn t worth much Your best bet is various Wikis and blog postings (TInspire?) Actual code more useful fs/binfmt flat.c in kernel source. Making the binaries hard. Not just a simple matter of telling gcc or linker (no one has bothered yet). Most 21

people use elf2flt but not-standard and hard to even find which code repository to use. 22

Loading a flat binary load flat binary() adjust stack space for arguments (argv and envp) loading header. Uses ntohl(). Why? Endian issues. check for bflt magic check version check rlimits() [stack, etc] setup new exec() 23

allocate mem for our binary (separately handle XIP and compressed format) read code() put all of our values in mm struct (Start/stop of all sections) RELOCATION fix up any symbols that changed due to being moved. (HOW DOES THIS WORK) flush icache() zero the BSS and STACK areas setup shared libraries 24

install exec creds() set binfmt() actually copy command line args, etc, at front of stack put stack pointer in mm structure start thread() 25

Position independent code PIC/PIE Instead of loading from absolute address, uses an offset, usually in a register or PC-relative. gcc has an option -fpic to generate 26

List of offsets to pointers Relocation PIC compiles things with zero offset At load time the pointers are fixed up to have the load address Separate relocation for GOT (global offset table) which is a list of pointers at the beginning of the data segment, ending with -1 27

Flat Shared Libraries Like mini executables, can have up to 256 of them Libraries loaded in place, then the callsites are fixed up to have the right address. Also at start time the various library init routines are called 28

Execute in Place Want our text in ROM. Why? Save space, save copying. Why bad? ROM often slow, more complicated binaries (data not follow text) 29

How to load our code? RAM Disk Can we load from disk? No driver yet. We can create a RAM disk, will be loaded by our bootloader right after. Sometimes called an initrd. 30