DOCSLIB.ORG

Improving System Security Through TCB Reduction

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Improving System Security Through TCB Reduction Improving System Security Through TCB Reduction Bernhard Kauer March 31, 2015 Dissertation vorgelegt an der Technischen Universität Dresden Fakultät Informatik zur Erlangung des akademischen Grades Doktoringenieur (Dr.-Ing.) Erstgutachter Prof. Dr. rer. nat. Hermann Härtig Technische Universität Dresden Zweitgutachter Prof. Dr. Paulo Esteves Veríssimo University of Luxembourg Verteidigung 15.12.2014 Abstract The OS (operating system) is the primary target of todays attacks. A single exploitable defect can be sufficient to break the security of the system and give fully control over all the software on the machine. Because current operating systems are too large to be defect free, the best approach to improve the system security is to reduce their code to more manageable levels. This work shows how the security-critical part of theOS, the so called TCB (Trusted Computing Base), can be reduced from millions to less than hundred thousand lines of code to achieve these security goals. Shrinking the software stack by more than an order of magnitude is an open challenge since no single technique can currently achieve this. We therefore followed a holistic approach and improved the design as well as implementation of several system layers starting with a newOS called NOVA. NOVA provides a small TCB for both newly written applications but also for legacy code running inside virtual machines. Virtualization is thereby the key technique to ensure that compatibility requirements will not increase the minimal TCB of our system. The main contribution of this work is to show how the virtual machine monitor for NOVA was implemented with significantly less lines of code without affecting the per- formance of its guest OS. To reduce the overall TCB of our system, other parts had to be improved as well. Additional contributions are the simplification of theOS debugging interface, the reduction of the boot stack and a new programming language called B1 that can be more easily compiled. 3 Acknowledgements First, I would like to thank my supervisor Hermann Härtig for his support as well as the freedom in choosing my research directions. Thanks are also due to the members of the OS group for uncountable discussions during my time at TU Dresden. I am particular indebted to Udo Steinberg, which I had the pleasure to share a room with. His NOVA Hypervisor proved to be an excellent base for my virtualization research. I am also grateful to Alexander Böttcher and Julian Stecklina for extending the software I have developed. During my thesis I had the privilege to get to know industrial and academic research in the US and Portugal. Thanks to Marcus Peinado and Sebastian Schoenberg for the summers at Microsoft and Intel as well as to Paulo Veríssimo and the navigators for the rewarding time and excellent coffee in Lisbon. I am grateful to all who have read and commented on drafts of this thesis. Monika Scholz, Anne Kauer, and Norman Feske deserve particular thanks for spending hours of their live to improve what I had written. The errors still remaining in this work are mine alone. Finally, I want to thank my family for always believing in me and supporting this endeavor for so a long time. Without Anne and my parents I would not have made it. Thank you all! 5 6 Contents List of Figures 11 1 Introduction 13 1.1 Motivation................................... 13 1.2 Approach.................................... 14 1.2.1 Minimizing the OS........................... 14 1.2.2 Ensuring Compatibility........................ 15 1.2.3 Additional Layers............................ 15 1.3 Contributions.................................. 16 2 A Smaller Virtualization Stack 19 2.1 Background and Related Work........................ 20 2.1.1 A short History of Virtualization................... 20 2.1.2 Virtualization Today.......................... 23 2.1.3 Securing the Virtualization Layer................... 26 2.1.4 Advanced Use Cases for Virtualization................ 28 2.2 Design...................................... 29 2.2.1 NOVA Architecture.......................... 29 2.2.2 The NOVA Microhypervisor...................... 30 2.2.3 NUL: The NOVA User-Level Environment.............. 32 2.2.4 Vancouver: A Small VMM for NOVA................ 38 2.3 Device Models................................. 42 2.3.1 Approaches to Reduce the TCB................... 42 2.3.2 Reusing an Existing VMM...................... 43 2.3.3 Implementation............................. 46 2.3.4 Implementation Details........................ 51 2.3.5 Evaluation: Code Size and Density.................. 54 2.3.6 Future Work.............................. 56 2.4 Instruction Emulator.............................. 57 2.4.1 Background............................... 57 2.4.2 First Generation: Hand-written Tables................ 58 2.4.3 Automating the Knowledge Extraction................ 58 2.4.4 Current Generation: Reuse the Assembler.............. 60 2.4.5 Summary and Future Work...................... 65 2.5 Virtual BIOS.................................. 67 2.5.1 Design.................................. 67 2.5.2 Implementation............................. 69 2.5.3 Enabling Emulators.......................... 70 7 CONTENTS 2.5.4 Summary................................ 71 2.6 Performance Evaluation............................ 71 2.6.1 Setting up the Benchmark....................... 72 2.6.2 Results................................. 74 2.6.3 Measurement Error........................... 78 2.6.4 Detailing the Overhead........................ 80 2.6.5 Performance Outlook......................... 84 2.7 Conclusions................................... 85 2.7.1 Size Outlook.............................. 86 3 TCB-aware Debugging 87 3.1 Requirements.................................. 87 3.1.1 Virtual Machines and Emulators................... 87 3.1.2 On-target versus Remote Debugger.................. 88 3.1.3 Tracing and Interactive Debugging.................. 89 3.1.4 Special Requirements for NOVA................... 90 3.2 The Vertical Debugger VDB.......................... 90 3.2.1 Reusing GDB?............................. 90 3.2.2 Design.................................. 91 3.2.3 Implementation............................. 93 3.3 Debugging without a Target Driver...................... 95 3.3.1 Choosing the Hardware........................ 96 3.3.2 Remote Access Without Runtime Code on the Target....... 97 3.3.3 Surviving a Bus-Reset......................... 98 3.3.4 Implementation............................. 100 3.3.5 Firewire Performance......................... 100 3.3.6 Related and Future Work....................... 103 3.4 Minimizing the Debug Stub.......................... 103 3.4.1 Design of a Halt and Resume Stub.................. 104 3.4.2 Debugging a NOVA system...................... 106 3.5 Summary.................................... 108 4 Simplifying the Compiler 109 4.1 Design...................................... 109 4.1.1 The Syntax............................... 110 4.1.2 Variables and Constants........................ 111 4.1.3 Operators, Functions and Control Structures............ 113 4.1.4 Discussion................................ 115 4.2 Implementation................................. 117 4.2.1 Implementation Language....................... 117 4.2.2 Let Python Parse............................ 118 4.2.3 Compiling to an Intermediate Representation............ 119 4.2.4 Optimizing the Compiler Output................... 119 4.2.5 Generating Machine Code....................... 120 4.2.6 Linking the Binary........................... 121 4.2.7 Implementing the Standard Library................. 121 4.2.8 Summary................................ 122 4.3 Evaluation.................................... 123 4.3.1 The Influence of the Optimizer.................... 123 4.3.2 Exception Handling.......................... 125 8 CONTENTS 4.3.3 System Calls: dd ............................ 127 4.3.4 Simple Calculation: wc ......................... 127 4.3.5 Complex Calculation: gunzip ..................... 130 4.3.6 Number Crunching: sha1sum ..................... 131 4.3.7 Summary................................ 133 4.4 Conclusions and Future Work......................... 133 5 Shrinking the Boot Stack 135 5.1 Background: Booting an OS on a PC..................... 135 5.1.1 The Firmware.............................. 136 5.1.2 The Bootloader............................. 136 5.1.3 The OS................................. 137 5.2 The Bootloader................................. 137 5.2.1 Features................................. 138 5.2.2 Design.................................. 138 5.2.3 Implementation............................. 140 5.2.4 Evaluation............................... 145 5.2.5 Summary................................ 146 5.3 Trusted Computing............................... 147 5.3.1 Secure Boot............................... 147 5.3.2 Trusted Computing with a Static Root of Trust for Measurement. 148 5.3.3 Trusted Computing with a Dynamic RTM.............. 149 5.3.4 Security Challenges.......................... 150 5.3.5 Summary................................ 152 5.4 ATARE: Parsing ACPI Tables with Regular Expressions.......... 152 5.4.1 Background............................... 153 5.4.2 Pattern Matching on AML...................... 154 5.4.3 The Search Algorithm......................... 156 5.4.4 Evaluation............................... 156 5.4.5 Summary................................ 159 5.5 Conclusions................................... 159 6 Conclusions 161 6.1 Techniques..................................
Load more

Recommended publications
  • User's Manual
    rBOX610 Linux Software User’s Manual Disclaimers This manual has been carefully checked and believed to contain accurate information. Axiomtek Co., Ltd. assumes no responsibility for any infringements of patents or any third party’s rights, and any liability arising from such use. Axiomtek does not warrant or assume any legal liability or responsibility for the accuracy, completeness or usefulness of any information in this document. Axiomtek does not make any commitment to update the information in this manual. Axiomtek reserves the right to change or revise this document and/or product at any time without notice. No part of this document may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of Axiomtek Co., Ltd. Trademarks Acknowledgments Axiomtek is a trademark of Axiomtek Co., Ltd. ® Windows is a trademark of Microsoft Corporation. Other brand names and trademarks are the properties and registered brands of their respective owners. Copyright 2014 Axiomtek Co., Ltd. All Rights Reserved February 2014, Version A2 Printed in Taiwan ii Table of Contents Disclaimers ..................................................................................................... ii Chapter 1 Introduction ............................................. 1 1.1 Specifications ...................................................................................... 2 Chapter 2 Getting Started ......................................
    [Show full text]
  • Installation and Configuration
    Installation and Configuration By High School Technology Services myhsts.org Recap From Previous Session ● UNIX, Linux and Open Source ● Duties of the System Administrator ● Superusers and the Root Login ● Sharing Superuser Privileges with Others (su and sudo Commands) ● TCP/IP Networking Fundamentals Planning: Hardware and Software Considerations Linux supports a wide range of PC hardware; but not even Linux supports every known device and system. Your PC must meet certain minimum requirements in order to run Linux. CPU - Linux does not support the Intel 286 and earlier processors. However, it fully supports the Intel 80386, 80486, Pentium, Pentium Pro, Pentium II, and Pentium III processors. Nevertheless, some users feel that their 80386 Linux systems respond sluggishly, particularly when running X. So, if you want optimum performance, you should install Linux on a PC having an 80486 processor or better. Linux also supports non-Intel processors such as the Cyrix 6x86 and the AMD K5 and K6. Most Linux users have systems that use Intel chips; if your system uses a non-Intel chip, you may find it more difficult to resolve possible problems. Planning: Hardware and Software Considerations Motherboard - Linux supports the standard ISA, EISA, PCI, and VESA (VLB) system buses used on most IBM-compatible PCs. Linux recently gained support for IBM's MCA bus, used in IBM's PS/2 series of computers. However, at the time of this writing, Debian GNU/Linux does not yet support the MCA bus. If you have an IBM PS/2, you may be unable to install Debian GNU/Linux (check the Debian Project web site for the latest available information on support for the MCA bus).
    [Show full text]
  • Compiler for Tiny Register Machine
    COMPILER FOR TINY REGISTER MACHINE An Undergraduate Research Scholars Thesis by SIDIAN WU Submitted to Honors and Undergraduate Research Texas A&M University in partial fulfillment of the requirements for the designation as an UNDERGRADUATE RESEARCH SCHOLAR Approved by Research Advisor: Dr. Riccardo Bettati May 2015 Major: Computer Science TABLE OF CONTENTS Page ABSTRACT .................................................................................................................................. 1 CHAPTER I INTRODUCTION ................................................................................................ 2 II BACKGROUND .................................................................................................. 5 Tiny Register Machine .......................................................................................... 5 Computer Language syntax .................................................................................. 6 Compiler ............................................................................................................... 7 III COMPILER DESIGN ......................................................................................... 12 Symbol Table ...................................................................................................... 12 Memory Layout .................................................................................................. 12 Recursive Descent Parsing .................................................................................. 13 IV CONCLUSIONS
    [Show full text]
  • Vx32: Lightweight User-Level Sandboxing on the X86
    Vx32: Lightweight User-level Sandboxing on the x86 Bryan Ford and Russ Cox Massachusetts Institute of Technology {baford,rsc}@pdos.csail.mit.edu Abstract 1 Introduction Code sandboxing is useful for many purposes, but most A sandbox is a mechanism by which a host software sandboxing techniques require kernel modifications, do system may execute arbitrary guest code in a confined not completely isolate guest code, or incur substantial environment, so that the guest code cannot compromise performance costs. Vx32 is a multipurpose user-level or affect the host other than according to a well-defined sandbox that enables any application to load and safely policy. Sandboxing is useful for many purposes, such execute one or more guest plug-ins, confining each guest as running untrusted Web applets within a browser [6], to a system call API controlled by the host application safely extending operating system kernels [5, 32], and and to a restricted memory region within the host’s ad- limiting potential damage caused by compromised ap- dress space. Vx32 runs guest code efficiently on several plications [19, 22]. Most sandboxing mechanisms, how- widespread operating systems without kernel extensions ever, either require guest code to be (re-)written in a type- or special privileges; it protects the host program from safe language [5,6], depend on special OS-specific facil- both reads and writes by its guests; and it allows the host ities [8, 15, 18, 19], allow guest code unrestricted read to restrict the instruction set available to guests. The key access to the host’s state [29, 42], or entail a substantial to vx32’s combination of portability, flexibility, and effi- performance cost [33,34,37].
    [Show full text]
  • Advanced Development of Certified OS Kernels Prof
    Advanced Development of Certified OS Kernels Zhong Shao (PI) and Bryan Ford (Co-PI) Department of Computer Science Yale University P.O.Box 208285 New Haven, CT 06520-8285, USA {zhong.shao,bryan.ford}yale.edu July 15, 2010 1 Innovative Claims Operating System (OS) kernels form the bedrock of all system software—they can have the greatest impact on the resilience, extensibility, and security of today’s computing hosts. A single kernel bug can easily wreck the entire system’s integrity and protection. We propose to apply new advances in certified software [86] to the development of a novel OS kernel. Our certified kernel will offer safe and application-specific extensibility [8], provable security properties with information flow control, and accountability and recovery from hardware or application failures. Our certified kernel builds on proof-carrying code concepts [74], where a binary executable includes a rigorous machine-checkable proof that the software is free of bugs with respect to spe- cific requirements. Unlike traditional verification systems, our certified software approach uses an expressive general-purpose meta-logic and machine-checkable proofs to support modular reason- ing about sophisticated invariants. The rich meta-logic enables us to verify all kinds of low-level assembly and C code [10,28,31,44,68,77,98] and to establish dependability claims ranging from simple safety properties to advanced security, correctness, and liveness properties. We advocate a modular certification framework for kernel components, which mirrors and enhances the modularity of the kernel itself. Using this framework, we aim to create not just a “one-off” lump of verified kernel code, but a statically and dynamically extensible kernel that can be incrementally built and extended with individual certified modules, each of which will provably preserve the kernel’s overall safety and security properties.
    [Show full text]
  • Tailored Application-Specific System Call Tables
    Tailored Application-specific System Call Tables Qiang Zeng, Zhi Xin, Dinghao Wu, Peng Liu, and Bing Mao ABSTRACT policies may be relaxed for setuid programs.1 Once a pro- The system call interface defines the services an operating gram is compromised, a uniform set of kernel services are system kernel provides to user space programs. An oper- potentially exposed to attackers as a versatile and handy ating system usually provides a uniform system call inter- toolkit. While a uniform system call interface simplifies op- face to all user programs, while in practice no programs erating system design, it does not meet the principle of least utilize the whole set of the system calls. Existing system privileges in the perspective of security, as the interface is call based sandboxing and intrusion detection systems fo- not tailored to the needs of applications. cus on confining program behavior using sophisticated finite state or pushdown automaton models. However, these au- Existing researches on system call based sandboxing and tomata generally incur high false positives when modeling intrusion detection focus on system call pattern checking program behavior such as signal handling and multithread- [16, 12, 31, 35, 7], arguments validation [35, 23, 25, 4, 3], ing, and the runtime overhead is usually significantly high. and call stack integrity verification [10, 15]. Some establish We propose to use a stateless model, a whitelist of system sophisticated models such as Finite State Automata (FSA) calls needed by the target program. Due to the simplicity [31, 35, 15, 13] and Pushdown Automata (PDA) [35, 14] we are able to construct the model via static analysis on by training [12, 31, 34, 10] or static analysis [35, 14, 15, the program's binary with much higher precision that in- 13], while others rely on manual configuration to specify the curs few false positives.
    [Show full text]
  • An ECMA-55 Minimal BASIC Compiler for X86-64 Linux®
    Computers 2014, 3, 69-116; doi:10.3390/computers3030069 OPEN ACCESS computers ISSN 2073-431X www.mdpi.com/journal/computers Article An ECMA-55 Minimal BASIC Compiler for x86-64 Linux® John Gatewood Ham Burapha University, Faculty of Informatics, 169 Bangsaen Road, Tambon Saensuk, Amphur Muang, Changwat Chonburi 20131, Thailand; E-mail: [email protected] Received: 24 July 2014; in revised form: 17 September 2014 / Accepted: 1 October 2014 / Published: 1 October 2014 Abstract: This paper describes a new non-optimizing compiler for the ECMA-55 Minimal BASIC language that generates x86-64 assembler code for use on the x86-64 Linux® [1] 3.x platform. The compiler was implemented in C99 and the generated assembly language is in the AT&T style and is for the GNU assembler. The generated code is stand-alone and does not require any shared libraries to run, since it makes system calls to the Linux® kernel directly. The floating point math uses the Single Instruction Multiple Data (SIMD) instructions and the compiler fully implements all of the floating point exception handling required by the ECMA-55 standard. This compiler is designed to be small, simple, and easy to understand for people who want to study a compiler that actually implements full error checking on floating point on x86-64 CPUs even if those people have little programming experience. The generated assembly code is also designed to be simple to read. Keywords: BASIC; compiler; AMD64; INTEL64; EM64T; x86-64; assembly 1. Introduction The Beginner’s All-purpose Symbolic Instruction Code (BASIC) language was invented by John G.
    [Show full text]
  • The Security Implications of Google Native Client
    Home Careers Contact Blog Product Services Team The Security Implications Of Google Native Client Chris | May 15th, 2009 | Filed Under: New Findings What would it look like if Google tried to unseat Flash and obsolete all desktop applications? It would look a lot like Google Native Client (NaCl): a mechanism to download a game written in C/C++ from Id Software and run it in your browser, without giving Id Software the ability to take control of your computer. Google NaCl is, on its face, a crazy-talk idea. It’s a browser plugin that downloads native x86 code from a website and runs it on your machine. If this sounds familiar, it’s because Microsoft tried it over a decade ago with ActiveX. If you’re skeptical about the idea, it’s because ActiveX was a security calamity; O.K. an ActiveX control, and it owns your machine almost completely. So the primary obstacle between Google and the future of software delivery is security. Google has a lot of interesting ideas about how to overcome that obstacle. But security people unlikely to take Google’s word for it. So Google held a contest: “we’ll publish the source code, you’ll find flaws. The winner gets $0x2000 USD.” We took the bait. And things were looking great for us. Then Skynet noticed Google, decided it was a threat, and sent a Mark Dowd unit back through time to terminate it. The contest winner hasn’t been declared yet, but as we aren’t a murderous robot made out of liquid metal, we’re guessing we didn’t take first place.
    [Show full text]
  • Leveraging Legacy Code to Deploy Desktop Applications on the Web
    Leveraging Legacy Code to Deploy Desktop Applications on the Web John R. Douceur, Jeremy Elson, Jon Howell, and Jacob R. Lorch Microsoft Research Abstract Our vision is to deliver feature-rich, desktop-class ap- Xax is a browser plugin model that enables developers plications on the web. We believe that the fastest and to leverage existing tools, libraries, and entire programs easiest way to create such apps is to leverage the ex- to deliver feature-rich applications on the web. Xax em- isting code bases of desktop applications and libraries, ploys a novel combination of mechanisms that collec- thereby exploiting the years of design, development, and tively provide security, OS-independence, performance, debugging effort that have gone into them. This ex- and support for legacy code. These mechanisms include isting code commonly expects to run in an OS pro- memory-isolated native code execution behind a narrow cess and to access OS services. However, actually run- syscall interface, an abstraction layer that provides a con- ning the code in an OS process would defeat the OS- sistent binary interface across operating systems, sys- independence required by web apps; and it would also tem services via hooks to existing browser mechanisms, impede code security, because large and complex OS and lightweight modifications to existing tool chains and system-call (or syscall) interfaces are difficult to secure code bases. We demonstrate a variety of applications and against privilege-escalation vulnerabilities [15]. libraries from existing code bases, in several languages, There is thus a trade-off between OS-independence, produced with various tool chains, running in multiple security, and legacy support.
    [Show full text]
  • Hacking the Hackers with User-Space Virtualization
    secuBT : Hacking the Hackers with User-Space Virtualization Mathias Payer Department of Computer Science ETH Zurich Abstract Two interesting scenarios are (i) sandboxing of server processes, and (ii) execution of untrusted In the age of coordinated malware distribution and code. Server daemons that offer an interface to zero-day exploits security becomes ever more im- the Internet are under constant attack. If these portant. This paper presents secuBT, a safe ex- daemons are virtualized and restricted to only spe- ecution framework for the execution of untrusted cific system calls and parameters then an exploit binary code based on the fastBT dynamic binary is unable to escalate privileges and execute unin- translator. tended code. The second scenario targets plugins secuBT implements user-space virtualization us- and other downloaded untrusted code that a user ing dynamic binary translation and adds a system would like to run in a special sandbox. Whenever call interposition framework to limit and guard the the program issues a system call, the user can de- interoperability of binary code with the kernel. cide if it is allowed or not. The sandbox limits the Fast binary translation is a key component to possible interactions between the virtualized pro- user-space virtualization. secuBT uses and ex- gram and the operating system. System calls are tends fastBT, a generator for low-overhead, table- checked depending on name, parameters, and call based dynamic (just-in-time) binary translators. location. We discuss the most challenging sources of over- Such a sandbox could be implemented as a ker- head and propose optimizations to further reduce nel module.
    [Show full text]
  • Paravirtualizing Linux in a Real-Time Hypervisor
    Paravirtualizing Linux in a real-time hypervisor Vincent Legout and Matthieu Lemerre CEA, LIST, Embedded Real Time Systems Laboratory Point courrier 172, F-91191 Gif-sur-Yvette, FRANCE {vincent.legout,matthieu.lemerre}@cea.fr ABSTRACT applications written for a fully-featured operating system This paper describes a new hypervisor built to run Linux in a such as Linux. The Anaxagoros design prevent non real- virtual machine. This hypervisor is built inside Anaxagoros, time tasks to interfere with real-time tasks, thus providing a real-time microkernel designed to execute safely hard real- the security foundation to build a hypervisor to run existing time and non real-time tasks. This allows the execution of non real-time applications. This allows current applications hard real-time tasks in parallel with Linux virtual machines to run on Anaxagoros systems without any porting effort, without interfering with the execution of the real-time tasks. opening the access to a wide range of applications. We implemented this hypervisor and compared perfor- Furthermore, modern computers are powerful enough to mances with other virtualization techniques. Our hypervisor use virtualization, even embedded processors. Virtualiza- does not yet provide high performance but gives correct re- tion has become a trendy topic of computer science, with sults and we believe the design is solid enough to guarantee its advantages like scalability or security. Thus we believe solid performances with its future implementation. that building a real-time system with guaranteed real-time performances and dense non real-time tasks is an important topic for the future of real-time systems.
    [Show full text]
  • Laboratory Experiment #1
    x86 and C refresher Lab Background: The x86 is a very widely used microprocessor, it is in Windows and Macintosh personal computers. It is important to be familiar with Intel Architecture, IA. In this lab we will be come familiar with the Intel Architecture using debuggers, assemblers, un-assemblers, and hand assembly. These tools will allow us to enter programs, assemble, execute, debug, and modify programs. Tools and techniques develop in this lab will prepare for using microcontrollers in later labs. C programs in this lab are to refresh C programming knowledge and explore C programming used in microprocessors. Also, this x86 – C refresher Lab will be preparation for using the C programming language to program microcontrollers. Objectives: To be come familiar with how microprocessors operate. To be come familiar with programming microprocessors using machine language, assembly language, and C language. To be come proficient in the use microprocessor debugging tools and techniques. To be come familiar with assemblers and their use in programming microprocessors. To understand how to hand assemble instructions for microprocessors. To understand the program development cycle (program-test-debug- modify-test-debug-repeat until done). To use tracing charts, break points, to verify and debug programs. To develop a program from a flow chart. To write documented code with flow chart and commented code. EEE174 CpE185 Laboratory S Summer 2015 X86 Lab Part 1: Introduction to Debug and C refresher Intro to DEBUG: Debug Monitor, Machine Language, and Assembly Language, Machine Instructions: MOV, SUB, ADD, JGE, INT 20h, and Debug Commands: d, e, u, r, and t Introduction: In this section, you will begin familiarizing yourself with the laboratory equipment.
    [Show full text]