DOCSLIB.ORG

CS 162: Operating Systems and Systems Programming Lecture 4: Threads and Concurrency

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
CS 162: Operating Systems and Systems Programming Lecture 4: Threads and Concurrency CS 162: Operating Systems and Systems Programming Lecture 4: Threads and Concurrency Sept 10, 2019 Instructor: David E. Culler https://cs162.eecs.berkeley.edu Read: A&D 5.1-3, 5.7.1 HW 1 due 9/18 Groups and Section Pref Wed 9/10/19 cs162 Fa19 L08 Proj 1 released, Design doc1 Tues Recall: Multiplexing Processes • Snapshot of each process in its PCB • Only one thread active at a time per core… • Give out CPU to different processes • Scheduling • Policy Decision • Give out non-CPU resources • Memory/IO • Another policy decision Process Control Block 9/10/19 cs162 Fa19 L08 2 TCB, Stacks and Recall: Context Switch Register Mgmt 9/10/19 cs162 Fa19 L08 3 Recall: Lifecycle of a process / thread Scheduler dispatches proc/thread to run: existing proc context_switch to it terminated “forks” a new proc ready running exit syscall Create OS repr. of proc or abort • Descriptor • Address space interrupt, syscall, • Thread(s) sleep, blocking call • … Queue for scheduling completion waiting • OS juggles many process/threads using kernel data structures • Proc’s may create other process (fork/exec) • All starts with init process at boot Pintos: process.c 9/10/19 cs162 Fa19 L08 4 Recall: Process Management • exit – terminate a process • fork – copy the current process • exec – change the program being run by the current process • wait – wait for a process to finish • kill – send a signal (interrupt-like notification) to another process • sigaction – set handlers for signals 9/10/19 cs162 Fa19 L08 5 Recall: Process Management child fork pid = fork(); exec main () { if (pid == 0) ... exec(...); else } wait(pid); pid = fork(); if (pid == 0) exec(...); parent else wait(pid); pid = fork(); if (pid == 0) wait exec(...); else wait(pid); 9/10/19 cs162 Fa19 L08 6 User/OS Threading Models Simple One-to-One Threading Model Almost all current implementations 9/10/19 Many-to-One cs162 Fa19 L08 Many-to-Many 7 Single vs. Multithreaded Processes 9/10/19 cs162 Fa19 L08 8 To d ay • What, Why, and How of Threads • Kernel-Supported User Threads • Coordination among Threads • Synchronization • Implementing Synchronization • User-level Threads 9/10/19 cs162 Fa19 L08 9 Definitions • A thread is a single execution sequence that represents a separately schedulable task • Protection is an orthogonal concept • Can have one or many threads per protection domain • Single threaded user program: one thread, one protection domain • Multi-threaded user program: multiple threads, sharing same data structures, isolated from other user programs • Multi-threaded kernel: multiple threads, sharing kernel data structures, capable of using privileged instructions 9/10/19 cs162 Fa19 L08 10 Threads Motivation • Operating systems need to be able to handle multiple things at once (MTAO) • processes, interrupts, background system maintenance • Servers need to handle MTAO • Multiple connections handled simultaneously • Parallel programs need to handle MTAO • To achieve better performance • Programs with user interfaces often need to handle MTAO • To achieve user responsiveness while doing computation • Network and disk bound programs need to handle MTAO • To hide network/disk latency • Sequence steps in access or communication 9/10/19 cs162 Fa19 L08 11 Silly Example for Threads Imagine the following program: main() { ComputePI(“pi.txt”); PrintClassList(“classlist.txt”); } • What is the behavior here? • Program would never print out class list • Why? ComputePI would never finish 9/10/19 cs162 Fa19 L08 12 Adding Threads • Version of program with Threads (loose syntax): main() { thread_fork(ComputePI, “pi.txt” )); thread_fork(PrintClassList, “classlist.txt”)); } • thread_fork: Start independent thread running given procedure • What is the behavior here? • Now, you would actually see the class list • This should behave as if there are two separate CPUs CPU1 CPU2 CPU1 CPU2 CPU1 CPU2 Time 9/10/19 cs162 Fa19 L08 13 More Practical Motivation Back to Jeff Dean's "Numbers everyone should know" Handle I/O in separate thread, avoid blocking other progress 9/10/19 cs162 Fa19 L08 14 Little Better Example for Threads? Imagine the following program: main() { … ReadLargeFile(“pi.txt”); RenderUserInterface(); } • What is the behavior here? • Still respond to user input • While reading file in the background 9/10/19 cs162 Fa19 L08 15 Voluntarily Giving Up Control • I/O – e.g. keypress • Waiting for a signal from another thread • Thread makes system call to wait • Thread executes thread_yield() • Relinquishes CPU but puts calling thread back on ready queue 9/10/19 cs162 Fa19 L08 16 Adding Threads • Version of program with Threads (loose syntax): main() { thread_fork(ReadLargeFile, “pi.txt” ); thread_fork(RenderUserInterface, “classlist.txt”); } • thread_fork: Start independent thread running given procedure • What is the behavior here? • Now, you would actually see the class list • This should behave as if there are two separate CPUs CPU1 CPU2 CPU1 CPU2 CPU1 CPU2 Time 9/10/19 cs162 Fa19 L08 17 Switching Threads • Consider the following code blocks: Thread S Thread T func A() { A A B(); } B(while) B(while) growth func B() { yield yield while(TRUE) { yield(); Stack run_new_thread run_new_thread } switch switch } • Two threads, S and T, each run A Thread S's switch returns to Thread T's (and vice versa) 9/10/19 cs162 Fa19 L08 18 Aren't we still switching contexts? • Yes, but much cheaper than switching processes • No need to change address space • Some numbers from Linux: • Frequency of context switch: 10-100ms • Switching between processes: 3-4 μsec. • Switching between threads: 100 ns 9/10/19 cs162 Fa19 L08 19 Processes vs. Threads Process 1 Process N • Switch overhead: threads threads • Same process: low Mem. Mem. • Different proc.: high IO IO • Protection … state … … state • Same proc: low CPU CPU CPU CPU state state state state • Different proc: high • Sharing overhead CPU OS • Same proc: low sched. • Different proc: high 1 thread at a time CPU (1 core) 9/10/19 cs162 Fa19 L08 20 Processes vs. Threads Process 1 Process N • Switch overhead: threads threads • Same process: low Mem. Mem. • Different proc.: high IO IO • Protection … state … … state • Same proc: low CPU CPU CPU CPU state state state state • Different proc: high • Sharing overhead CPU OS • Same proc: low sched. • Different proc: high 4 threads at a time Core Core Core Core 1 2 3 4 9/10/19 cs162 Fa19 L08 21 Example: Multithreaded Server serverLoop() { connection = AcceptNewConnection(); (thread_)fork(ServiceWebPage, connection); } • One process/thread per connection, many concurrent connections • Process (isolation) vs Thread (performance) • How fast is creating threads? • Better than fork(), but still overhead • Problem: What if we get a lot of requests? • Might run out of memory (thread stacks) • Schedulers usually have trouble with too many threads 9/10/19 cs162 Fa19 L08 22 Web Server: Thread Pools • Bounded pool of worker threads • Allocated in advance: no thread creation overhead • Queue of pending requests • Limited number of requests in progress Request Master Client Thread Queue Thread Pool Response 9/10/19 cs162 Fa19 L08 23 Multiprocessing vs Multiprogramming • Multiprocessing: Multiple cores • Multiprogramming: Multiple Jobs/Processes • Multithreading: Multiple threads/processes • What does it mean to run two threads concurrently? • Scheduler is free to run threads in any order and interleaving A Multiprocessing B C A B C Multiprogramming A B C A B C B 9/10/19 cs162 Fa19 L08 24 Thread vs. Process State • Process-wide state: • Memory contents (global variables, heap) • I/O bookkeeping • Thread-”local" state: • CPU registers including program counter • Execution stack • Kept in Thread Control Block 9/10/19 cs162 Fa19 L08 25 Shared vs. Per-Thread State Shared Per−Thread Per−Thread State State State Thread Control Thread Control Heap Block (TCB) Block (TCB) Stack Stack Information Information Saved Saved Global Registers Registers Variables Thread Thread Metadata Metadata Stack Stack Code 9/10/19 cs162 Fa19 L08 26 Memory Footprint: Two Threads • Two sets of CPU registers Stack 1 • Two sets of Stacks • Issues: Stack 2 Space Address • How do we position stacks relative to each other? • What maximum size should we choose for the stacks? Heap • What happens if threads violate this? • How might you catch violations? Global Data • User threads need ‘proper’ stacks Code • System threads may be very constrained 9/10/19 cs162 Fa19 L08 27 Yield is covered, what about I/O? CopyFile Stack growth Stack read Trap to OS kernel_read run_new_thread switch • User code invokes syscall • IO operation initiated (more later) • Run new thread, switch • Really, same thing as before • Just put the thread on a different queue 9/10/19 cs162 Fa19 L08 28 Preempting a Thread • What happens if thread never does any I/O, never waits, and never yields control? • Must find way that dispatcher can regain control! • Interrupts: signals from hardware or software that stop the running code and jump to kernel • Timer: like an alarm clock that goes off every some milliseconds • Interrupt is a hardware-invoked mode switch • Handled immediately, no scheduling required 9/10/19 cs162 Fa19 L08 29 Example: Network Interrupt Raise priority (set mask) ... Ints Save registers add $r1,$r2,$r3 PC saved Reenable Ints subi $r4,$r1,#4 Dispatch to Handler slli $r4,$r4,#2 Disable All … Kernel Mode ... Transfer Network Packet Pipeline Flush from hardware to Kernel Buffers ... … lw $r2,0($r4) Restore PC Restore registers lw $r3,4($r4) Enable all User Mode Clear current Int External Interrupt External
Load more

Recommended publications
  • Draft SP 800-125A Rev. 1, Security Recommendations for Server
    The attached DRAFT document (provided here for historical purposes), released on April 11, 2018, has been superseded by the following publication: Publication Number: NIST Special Publication (SP) 800-125A Rev. 1 Title: Security Recommendations for Server-based Hypervisor Platforms Publication Date: June 2018 • Final Publication: https://doi.org/10.6028/NIST.SP.800-125Ar1 (which links to https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-125Ar1.pdf). • Related Information on CSRC: Final: https://csrc.nist.gov/publications/detail/sp/800-125a/rev-1/final 1 Draft NIST Special Publication 800-125A 2 Revision 1 3 4 Security Recommendations for 5 Hypervisor Deployment on 6 ServersServer-based Hypervisor 7 Platforms 8 9 10 11 12 Ramaswamy Chandramouli 13 14 15 16 17 18 19 20 21 22 23 C O M P U T E R S E C U R I T Y 24 25 Draft NIST Special Publication 800-125A 26 Revision 1 27 28 29 30 Security Recommendations for 31 Server-based Hypervisor Platforms 32 33 Hypervisor Deployment on Servers 34 35 36 37 Ramaswamy Chandramouli 38 Computer Security Division 39 Information Technology Laboratory 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 April 2018 56 57 58 59 60 61 U.S. Department of Commerce 62 Wilbur L. Ross, Jr., Secretary 63 64 National Institute of Standards and Technology 65 Walter Copan, NIST Director and Under Secretary of Commerce for Standards and Technology 66 67 Authority 68 69 This publication has been developed by NIST in accordance with its statutory responsibilities under the 70 Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C.
    [Show full text]
  • Synchronization Spinlocks - Semaphores
    CS 4410 Operating Systems Synchronization Spinlocks - Semaphores Summer 2013 Cornell University 1 Today ● How can I synchronize the execution of multiple threads of the same process? ● Example ● Race condition ● Critical-Section Problem ● Spinlocks ● Semaphors ● Usage 2 Problem Context ● Multiple threads of the same process have: ● Private registers and stack memory ● Shared access to the remainder of the process “state” ● Preemptive CPU Scheduling: ● The execution of a thread is interrupted unexpectedly. ● Multiple cores executing multiple threads of the same process. 3 Share Counting ● Mr Skroutz wants to count his $1-bills. ● Initially, he uses one thread that increases a variable bills_counter for every $1-bill. ● Then he thought to accelerate the counting by using two threads and keeping the variable bills_counter shared. 4 Share Counting bills_counter = 0 ● Thread A ● Thread B while (machine_A_has_bills) while (machine_B_has_bills) bills_counter++ bills_counter++ print bills_counter ● What it might go wrong? 5 Share Counting ● Thread A ● Thread B r1 = bills_counter r2 = bills_counter r1 = r1 +1 r2 = r2 +1 bills_counter = r1 bills_counter = r2 ● If bills_counter = 42, what are its possible values after the execution of one A/B loop ? 6 Shared counters ● One possible result: everything works! ● Another possible result: lost update! ● Called a “race condition”. 7 Race conditions ● Def: a timing dependent error involving shared state ● It depends on how threads are scheduled. ● Hard to detect 8 Critical-Section Problem bills_counter = 0 ● Thread A ● Thread B while (my_machine_has_bills) while (my_machine_has_bills) – enter critical section – enter critical section bills_counter++ bills_counter++ – exit critical section – exit critical section print bills_counter 9 Critical-Section Problem ● The solution should ● enter section satisfy: ● critical section ● Mutual exclusion ● exit section ● Progress ● remainder section ● Bounded waiting 10 General Solution ● LOCK ● A process must acquire a lock to enter a critical section.
    [Show full text]
  • Designing and Implementing the OP and OP2 Web Browsers
    Designing and Implementing the OP and OP2 Web Browsers CHRIS GRIER, SHUO TANG and SAMUEL T. KING, University of Illinois at Urbana-Champaign Current web browsers are plagued with vulnerabilities, providing hackers with easy access to computer systems via browser-based attacks. Browser security efforts that retrofit existing browsers have had lim- ited success because the design of modern browsers is fundamentally flawed. To enable more secure web browsing, we design and implement a new browser, called the OP web browser, that attempts to improve the state-of-the-art in browser security. We combine operating system design principles with formal methods to design a more secure web browser by drawing on the expertise of both communities. Our design philosophy is to partition the browser into smaller subsystems and make all communication between subsystems sim- ple and explicit. At the core of our design is a small browser kernel that manages the browser subsystems and interposes on all communications between them to enforce our new browser security features. To show the utility of our browser architecture, we design and implement three novel security features. First, we develop flexible security policies that allow us to include browser plugins within our security framework. Second, we use formal methods to prove useful security properties including user interface invariants and browser security policy. Third, we design and implement a browser-level information-flow tracking system to enable post-mortem analysis of browser-based attacks. In addition to presenting the OP browser architecture, we discuss the design and implementation of a second version of OP, OP2, that includes features from other secure web browser designs to improve on the overall security and performance of OP.
    [Show full text]
  • Practical Session 1, System Calls a Few Administrative Notes…
    Operating Systems, 142 Tas: Vadim Levit , Dan Brownstein, Ehud Barnea, Matan Drory and Yerry Sofer Practical Session 1, System Calls A few administrative notes… • Course homepage: http://www.cs.bgu.ac.il/~os142/ • Contact staff through the dedicated email: [email protected] (format the subject of your email according to the instructions listed in the course homepage) • Assignments: Extending xv6 (a pedagogical OS) Submission in pairs. Frontal checking: 1. Assume the grader may ask anything. 2. Must register to exactly one checking session. System Calls • A System Call is an interface between a user application and a service provided by the operating system (or kernel). • These can be roughly grouped into five major categories: 1. Process control (e.g. create/terminate process) 2. File Management (e.g. read, write) 3. Device Management (e.g. logically attach a device) 4. Information Maintenance (e.g. set time or date) 5. Communications (e.g. send messages) System Calls - motivation • A process is not supposed to access the kernel. It can’t access the kernel memory or functions. • This is strictly enforced (‘protected mode’) for good reasons: • Can jeopardize other processes running. • Cause physical damage to devices. • Alter system behavior. • The system call mechanism provides a safe mechanism to request specific kernel operations. System Calls - interface • Calls are usually made with C/C++ library functions: User Application C - Library Kernel System Call getpid() Load arguments, eax _NR_getpid, kernel mode (int 80) Call sys_getpid() Sys_Call_table[eax] syscall_exit return resume_userspace return User-Space Kernel-Space Remark: Invoking int 0x80 is common although newer techniques for “faster” control transfer are provided by both AMD’s and Intel’s architecture.
    [Show full text]
  • Isolation, Resource Management, and Sharing in Java
    Processes in KaffeOS: Isolation, Resource Management, and Sharing in Java Godmar Back, Wilson C. Hsieh, Jay Lepreau School of Computing University of Utah Abstract many environments for executing untrusted code: for example, applets, servlets, active packets [41], database Single-language runtime systems, in the form of Java queries [15], and kernel extensions [6]. Current systems virtual machines, are widely deployed platforms for ex- (such as Java) provide memory protection through the ecuting untrusted mobile code. These runtimes pro- enforcement of type safety and secure system services vide some of the features that operating systems pro- through a number of mechanisms, including namespace vide: inter-application memory protection and basic sys- and access control. Unfortunately, malicious or buggy tem services. They do not, however, provide the ability applications can deny service to other applications. For to isolate applications from each other, or limit their re- example, a Java applet can generate excessive amounts source consumption. This paper describes KaffeOS, a of garbage and cause a Web browser to spend all of its Java runtime system that provides these features. The time collecting it. KaffeOS architecture takes many lessons from operating To support the execution of untrusted code, type-safe system design, such as the use of a user/kernel bound- language runtimes need to provide a mechanism to iso- ary, and employs garbage collection techniques, such as late and manage the resources of applications, analogous write barriers. to that provided by operating systems. Although other re- The KaffeOS architecture supports the OS abstraction source management abstractions exist [4], the classic OS of a process in a Java virtual machine.
    [Show full text]
  • The Deadlock Problem
    The deadlock problem More deadlocks mutex_t m1, m2; Same problem with condition variables void p1 (void *ignored) { • lock (m1); - Suppose resource 1 managed by c1, resource 2 by c2 lock (m2); - A has 1, waits on 2, B has 2, waits on 1 /* critical section */ c c unlock (m2); Or have combined mutex/condition variable unlock (m1); • } deadlock: - lock (a); lock (b); while (!ready) wait (b, c); void p2 (void *ignored) { unlock (b); unlock (a); lock (m2); - lock (a); lock (b); ready = true; signal (c); lock (m1); unlock (b); unlock (a); /* critical section */ unlock (m1); One lesson: Dangerous to hold locks when crossing unlock (m2); • } abstraction barriers! This program can cease to make progress – how? - I.e., lock (a) then call function that uses condition variable • Can you have deadlock w/o mutexes? • 1/15 2/15 Deadlocks w/o computers Deadlock conditions 1. Limited access (mutual exclusion): - Resource can only be shared with finite users. 2. No preemption: - once resource granted, cannot be taken away. Real issue is resources & how required • 3. Multiple independent requests (hold and wait): E.g., bridge only allows traffic in one direction - don’t ask all at once (wait for next resource while holding • - Each section of a bridge can be viewed as a resource. current one) - If a deadlock occurs, it can be resolved if one car backs up 4. Circularity in graph of requests (preempt resources and rollback). All of 1–4 necessary for deadlock to occur - Several cars may have to be backed up if a deadlock occurs. • Two approaches to dealing with deadlock: - Starvation is possible.
    [Show full text]
  • Fair K Mutual Exclusion Algorithm for Peer to Peer Systems ∗
    Fair K Mutual Exclusion Algorithm for Peer To Peer Systems ∗ Vijay Anand Reddy, Prateek Mittal, and Indranil Gupta University of Illinois, Urbana Champaign, USA {vkortho2, mittal2, indy}@uiuc.edu Abstract is when multiple clients are simultaneously downloading a large multimedia file, e.g., [3, 12]. Finally applications k-mutual exclusion is an important problem for resource- where a service has limited computational resources will intensive peer-to-peer applications ranging from aggrega- also benefit from a k mutual exclusion primitive, preventing tion to file downloads. In order to be practically useful, scenarios where all the nodes of the p2p system simultane- k-mutual exclusion algorithms not only need to be safe and ously overwhelm the server. live, but they also need to be fair across hosts. We pro- The k mutual exclusion problem involves a group of pro- pose a new solution to the k-mutual exclusion problem that cesses, each of which intermittently requires access to an provides a notion of time-based fairness. Specifically, our identical resource called the critical section (CS). A k mu- algorithm attempts to minimize the spread of access time tual exclusion algorithm must satisfy both safety and live- for the critical resource. While a client’s access time is ness. Safety means that at most k processes, 1 ≤ k ≤ n, the time between it requesting and accessing the resource, may be in the CS at any given time. Liveness means that the spread is defined as a system-wide metric that measures every request for critical section access is satisfied in finite some notion of the variance of access times across a homo- time.
    [Show full text]
  • Cali: Compiler-Assisted Library Isolation
    Cali: Compiler-Assisted Library Isolation Markus Bauer Christian Rossow CISPA Helmholtz Center for Information Security CISPA Helmholtz Center for Information Security Saarbrücken, Saarland, Germany Saarbrücken, Saarland, Germany [email protected] [email protected] ABSTRACT the full program’s privileges and address space. This lack of privi- Software libraries can freely access the program’s entire address lege separation and memory isolation has led to numerous critical space, and also inherit its system-level privileges. This lack of sepa- security incidents. ration regularly leads to security-critical incidents once libraries We can significantly reduce this threat surface by isolating the contain vulnerabilities or turn rogue. We present Cali, a compiler- library from the main program. In most cases, a library (i) neither assisted library isolation system that fully automatically shields a requires access to the entire program’s address space, (ii) nor needs program from a given library. Cali is fully compatible with main- the full program’s privileges to function properly. In fact, even line Linux and does not require supervisor privileges to execute. We complex libraries such as parsers require only limited interaction compartmentalize libraries into their own process with well-defined with the program and/or system. Conceptually, there is thus little security policies. To preserve the functionality of the interactions need to grant an untrusted library access to the program or to between program and library, Cali uses a Program Dependence critical system privileges. Basic compartmentalization principles Graph to track data flow between the program and the library dur- thus help to secure a program from misuse by untrusted code.
    [Show full text]
  • Interprocess Communication 1 Processes • Basic Concept to Build
    Interprocess Communication 1 Processes • Basic concept to build the OS, from old IBM mainframe OS to the most modern Windows • Used to express the requirements to be met by an OS – Interleave the execution of multiple processes, to maximize CPU utilization while providing good response time – Allocate resources to processes using a policy while avoiding deadlocks – Support interprocess communications and user creation of processes to help structuring applications • Background – Computer platform * Collection of hardware resources – CPU, memory, I/O modules, timers, storage devices – Computer applications * Developed to perform some task * Input, processing, output – Efficient to write applications for a given CPU * Common routines to access computer resources across platforms * CPU provides only limited support for multiprogramming; software manages sharing of CPU and other re- sources by multiple applications concurrently * Data and resources for multiple concurrent applications must be protected from other applications • Process – Abstraction of a running program – Unit of work in the system – Split into two abstractions in modern OS * Resource ownership (traditional process view) * Stream of instruction execution (thread) – Pseudoparallelism, or interleaved instructions – A process is traced by listing the sequence of instructions that execute for that process • Modeling sequential process/task – Program during execution – Program code – Current activity – Process stack * Function parameters * Return addresses * Temporary variables –
    [Show full text]
  • Introduction to Operating Systems Learning Outcomes What Is An
    Learning Outcomes • High-level understand what is an operating Introduction to Operating system and the role it plays Systems • A high-level understanding of the structure of operating systems, applications, and the relationship between them. Chapter 1 – 1.3 • Some knowledge of the services provided by Chapter 1.5 – 1.9 operating systems. • Exposure to some details of major OS concepts. 2 What is an Operating System? 3 4 Block Diagram of Haswell Platform Architecture http://www.pcquest.com Role 1: The Operating System is Disk Users an Abstract Machine • Extends the basic hardware with added Memory functionality • Provides high-level abstractions – More programmer friendly CPU – Common core for all applications Network • E.g. Filesystem instead of just registers on a disk controller Bandwidth • It hides the details of the hardware – Makes application code portable 5 6 1 Structural (Implementation) View: the Role 2: The Operating System Operating System is the Privileged is a Resource Manager Component • Responsible for allocating resources to users and processes Applications Applications Applications • Must ensure User Mode Requests (System Calls) – No Starvation Privileged Mode – Progress – Allocation is according to some desired policy Operating System • First-come, first-served; Fair share; Weighted fair share; limits (quotas), etc… – Overall, that the system is efficiently used Hardware 7 8 The Operating System is Operating System Kernel Privileged • Portion of the operating system that is • Applications should not be able to interfere
    [Show full text]
  • Sealing OS Processes to Improve Dependability and Security
    Sealing OS Processes to Improve Dependability and Safety Galen Hunt, Mark Aiken, Manuel Fähndrich, Chris Hawblitzel, Orion Hodson, James Larus, Steven Levi, Bjarne Steensgaard, David Tarditi, and Ted Wobber Microsoft Research One Microsoft Way Redmond, WA 98052 USA [email protected] ABSTRACT General Terms In most modern operating systems, a process is a Design, Reliability, Experimentation. hardware-protected abstraction for isolating code and data. This protection, however, is selective. Many common Keywords mechanisms—dynamic code loading, run-time code Open process architecture, sealed process architecture, sealed generation, shared memory, and intrusive system APIs— kernel, software isolated process (SIP). make the barrier between processes very permeable. This paper argues that this traditional open process architecture 1. INTRODUCTION exacerbates the dependability and security weaknesses of Processes debuted, circa 1965, as a recognized operating modern systems. system abstraction in Multics [48]. Multics pioneered As a remedy, this paper proposes a sealed process many attributes of modern processes: OS-supported architecture, which prohibits dynamic code loading, self- dynamic code loading, run-time code generation, cross- modifying code, shared memory, and limits the scope of process shared memory, and an intrusive kernel API that the process API. This paper describes the implementation permitted one process to modify directly the state of of the sealed process architecture in the Singularity another process. operating system,
    [Show full text]
  • Download Distributed Systems Free Ebook
    DISTRIBUTED SYSTEMS DOWNLOAD FREE BOOK Maarten van Steen, Andrew S Tanenbaum | 596 pages | 01 Feb 2017 | Createspace Independent Publishing Platform | 9781543057386 | English | United States Distributed Systems - The Complete Guide The hope is that together, the system can maximize resources and information while preventing failures, as if one system fails, it won't affect the availability of the service. Banker's algorithm Dijkstra's algorithm DJP algorithm Prim's algorithm Dijkstra-Scholten algorithm Dekker's algorithm generalization Smoothsort Shunting-yard algorithm Distributed Systems marking algorithm Concurrent algorithms Distributed Systems algorithms Deadlock prevention algorithms Mutual exclusion algorithms Self-stabilizing Distributed Systems. Learn to code for free. For the first time computers would be able to send messages to other systems with a local IP address. The messages passed between machines contain forms of data that the systems want to share like databases, objects, and Distributed Systems. Also known as distributed computing and distributed databases, a distributed system is a collection of independent components located on different machines that share messages with each other in order to achieve common goals. To prevent infinite loops, running the code requires some amount of Ether. As mentioned in many places, one of which this great articleyou cannot have consistency and availability without partition tolerance. Because it works in batches jobs a problem arises where if your job fails — Distributed Systems need to restart the whole thing. While in a voting system an attacker need only add nodes to the network which is Distributed Systems, as free access to the network is a design targetin a CPU power based scheme an attacker faces a physical limitation: getting access to more and more powerful hardware.
    [Show full text]