X86 Hardware Segmentation

Total Page:16

File Type:pdf, Size:1020Kb

X86 Hardware Segmentation Want processes to co-exist Issues in sharing physical memory Protection • - A bug in one process can corrupt memory in another - Must somehow prevent process A from trashing B’s memory - Also prevent A from even observing B’s memory (ssh-agent) Transparency • - A process shouldn’t require particular memory locations Consider multiprogramming on physical memory - Processes often require large amounts of contiguous memory • (for stack, large data structures, etc.) - What happens if pintos needs to expand? Resource exhaustion - If emacs needs more memory than is on the machine?? • - If pintos has an error and writes to address 0x7100? - Programmers typically assume machine has “enough” memory - When does gcc have to know it will run at 0x4000? - Sum of sizes of all processes often greater than physical memory - What if emacs isn’t using its memory? 1/36 2/36 Virtual memory goals Virtual memory advantages Is address Can re-locate program while running • legal? - Run partially in memory, partially on disk app. virtual address Yes, phys. addr 0x30408 0x92408 Most of a process’s memory will be idle (80/20 rule). load • gcc emacs data memory kernel To fault handler No physical idle memory idle Give each program its own “virtual” address space • kernel kernel - At run time, Memory-Management Unit relocates each load, store to actual memory. App doesn’t see physical memory - Write idle parts to disk until needed Also enforce protection • - Let other processes use memory for idle part - Prevent one app from messing with another’s memory - Like CPU virtualization: when process not using CPU, switch. And allow programs to see more memory than exists When not using a page switch it to another process. • - Somehow relocate some memory accesses to disk Challenge: VM = extra layer, could be slow 3/36 • 4/36 Idea 1: load-time linking Idea 1: load-time linking Link as usual, but keep the list of references Link as usual, but keep the list of references • • Fix up process when actually executed Fix up process when actually executed • • - Determine where process will reside in memory - Determine where process will reside in memory - Adjust all references within program (using addition) - Adjust all references within program (using addition) Problems? Problems? • • - How to enforce protection - How to move once in memory (Consider: data pointers) - What if no contiguous free region fits program? 5/36 5/36 Idea 2: base + bounds register Idea 2: base + bounds register Two special privileged registers: base and bound Two special privileged registers: base and bound • • On each load/store: On each load/store: • • - Physical address = virtual address + base - Physical address = virtual address + base - Check 0 virtual address < bound, else trap to kernel - Check 0 virtual address < bound, else trap to kernel ≤ ≤ How to move process in memory? How to move process in memory? • • - Change base register - Change base register What happens on context switch? What happens on context switch? • • - OS must re-load base and bound register - OS must re-load base and bound register 6/36 6/36 Definitions Address space Programs load/store to virtual (or logical) addresses • Actual memory uses physical (or real) addresses • VM Hardware is Memory Management Unit (MMU) • - Usually part of CPU - Accessed w. privileged instructions (e.g., load bound reg) - Translates from virtual to physical addresses - Gives per-process view of memory called address space 7/36 8/36 Base+bound trade-offs Base+bound trade-offs Advantages Advantages • • - Cheap in terms of hardware: only two registers - Cheap in terms of hardware: only two registers - Cheap in terms of cycles: do add and compare in parallel - Cheap in terms of cycles: do add and compare in parallel - Examples: Cray-1 used this scheme - Examples: Cray-1 used this scheme Disadvantages Disadvantages • • - Growing a process is expensive or impossible - No way to share code or data (E.g., two copies of bochs, both running pintos) One solution: Multiple segments • - E.g., separate code, stack, data segments - Possibly multiple data segments 9/36 9/36 Segmentation Segmentation mechanics Each process has a segment table Let processes have many base/bounds regs • • Each VA indicates a segment and offset: - Address space built from many segments • - Can share/protect memory on segment granularity - Top bits of addr select segment, low bits select offset (PDP-10) - Or segment selected by instruction or operand (means you Must specify segment as part of virtual address • need wider “far” pointers to specify segment) 10/36 11/36 Segmentation example Segmentation trade-offs virtual physical Advantages • - Multiple segments per process - Allows sharing! (how?) - Don’t need entire process in memory Disadvantages • - Requires translation hardware, which could limit performance - Segments not completely transparent to program (e.g., default segment faster or uses shorter instruction) - n byte segment needs n contiguous bytes of physical memory 2-bit segment number (1st digit), 12 bit offset (last 3) • - Makes fragmentation a real problem. - Where is 0x0240? 0x1108? 0x265c? 0x3002? 0x1600? 12/36 13/36 Fragmentation Alternatives to hardware MMU Fragmentation = Inability to use free memory • ⇒ Language-level protection (Java) Over time: • • - Single address space for different modules - Variable-sized pieces = many small holes (external frag.) - Language enforces isolation - Fixed-sized pieces = no external holes, but force internal waste - Singularity OS does this [Hunt] (internal fragmentation) Software fault isolation • - Instrument compiler output - Checks before every store operation prevents modules from trashing each other - Google Native Client does this with only about 5% slowdown [Yee] 14/36 15/36 Paging Paging trade-offs Divide memory up into small pages • Map virtual pages to physical pages • - Each process has separate mapping Allow OS to gain control on certain operations • - Read-only pages trap to OS on write - Invalid pages trap to OS on read or write - OS can change mapping and resume application Eliminates external fragmentation Other features sometimes found: • • Simplifies allocation, free, and backing storage - Hardware can set “accessed” and “dirty” bits • - Control page execute permission separately from read/write (swap) - Control caching of page Average internal fragmentation of .5 pages per • “segment” 16/36 17/36 Simplified allocation Paging data structures Pages are fixed size, e.g., 4K • - Least significant 12 (log 4K) bits of address are page offset gccphysical emacs memory - Most significant bits are page number Each process has a page table Disk • - Maps virtual page numbers to physical page numbers - Also includes bits for protection, validity, etc. On memory access: Translate VPN to PPN, • then add offset Allocate any physical page to any process • Can store idle virtual pages on disk • 18/36 19/36 Example: Paging on PDP-11 x86 Paging Paging enabled by bits in a control register (%cr0) 64K virtual memory, 8K pages • • - Only privileged OS code can manipulate control registers - Separate address space for instructions & data Normally 4KB pages - I.e., can’t read your own instructions with a load • %cr3: points to 4KB page directory Entire page table stored in registers • • - See pagedir activate in Pintos - 8 Instruction page translation registers Page directory: 1024 PDEs (page directory entries) - 8 Data page translations • - Each contains physical address of a page table Swap 16 machine registers on each context switch • Page table: 1024 PTEs (page table entries) • - Each contains physical address of virtual 4K page - Page table covers 4 MB of Virtual mem See old intel manual for simplest explanation • - Also volume 2 of AMD64 Architecture docs - Also volume 3A of latest Pentium Manual 20/36 21/36 x86 page translation x86 page directory entry Linear Address 3122 2112 11 0 Directory Table O f f s et Page−Directory Entry (4−KByte Page Table) 31 1 2 11 9 8 7 6 5 4 3 2 1 0 12 4−KByte Page P P U R Page−Table Base Address A vail G P 0 A C W / / P S D T S W Page Table 10 10 Physical Address Page Directory Available for system programmer’s use Global page (Ignored) Page size (0 indicates 4 KBytes) Page−Table Entry Reserved (set to 0) 20 A c c e s se d Directory Entry Cache disabled Write−through 32* 1024 PDE 1024 PTE = 220 Pages User/Supervisor CR3 (PDBR) × R e a d /W rite P re s e n t *32 bits aligned onto a 4−KByte boundary 22/36 23/36 x86 page table entry x86 hardware segmentation x86 architecture also supports segmentation • Page−Table Ent ry (4−KByte Page) - Segment register base + pointer val = linear address 31 12 11 9 8 7 6 5 4 3 2 1 0 - Page translation happens on linear addresses P P P U R Two levels of protection and translation check Page Base Address Avail G A D A C W / / P • T D T S W - Segmentation model has four privilege levels (CPL 0–3) - Paging only two, so 0–2 = kernel, 3 = user Available for system programmer’s use Why do you want both paging and segmentation? Global Page • Page Table Attribute Index Dirty Accessed Cache Disabled Write−Through User/Supervisor Read/Write Present 24/36 25/36 x86 hardware segmentation Making paging fast x86 architecture also supports segmentation • - Segment register base + pointer val = linear address x86 PTs require 3 memory references per load/store • - Page translation happens on linear addresses - Look up page table address in page directory Two levels of protection and translation check - Look up PPN in page table • - Segmentation model has four privilege
Recommended publications
  • Intermediate X86 Part 2
    Intermediate x86 Part 2 Xeno Kovah – 2010 xkovah at gmail All materials are licensed under a Creative Commons “Share Alike” license. • http://creativecommons.org/licenses/by-sa/3.0/ 2 Paging • Previously we discussed how segmentation translates a logical address (segment selector + offset) into a 32 bit linear address. • When paging is disabled, linear addresses map 1:1 to physical addresses. • When paging is enabled, a linear address must be translated to determine the physical address it corresponds to. • It’s called “paging” because physical memory is divided into fixed size chunks called pages. • The analogy is to books in a library. When you need to find some information first you go to the library where you look up the relevant book, then you select the book and look up a specific page, from there you maybe look for a specific specific sentence …or “word”? ;) • The internets ruined the analogy! 3 Notes and Terminology • All of the figures or references to the manual in this section refer to the Nov 2008 manual (available in the class materials). This is because I think the manuals <= 2008 organized and presented much clearer than >= 2009 manuals. • When I refer to a “frame” it means “a page- sized chunk of physical memory” • When paging is enabled, a “linear address” is the same thing as a “virtual memory ” “ ” address or virtual address 4 The terrifying truth revealed! And now you knowAHHHHHHHH!!!…the rest of the story.(Nah, Good it’s not so bad day. :)) 5 Virtual Memory • When paging is enabled, the 32 bit linear address space can be mapped to a physical address space less than 32 bits.
    [Show full text]
  • I386-Engine™ Technical Manual
    i386-Engine™ C/C++ Programmable, 32-bit Microprocessor Module Based on the Intel386EX Technical Manual 1950 5 th Street, Davis, CA 95616, USA Tel: 530-758-0180 Fax: 530-758-0181 Email: [email protected] http://www.tern.com Internet Email: [email protected] http://www.tern.com COPYRIGHT i386-Engine, VE232, A-Engine, A-Core, C-Engine, V25-Engine, MotionC, BirdBox, PowerDrive, SensorWatch, Pc-Co, LittleDrive, MemCard, ACTF, and NT-Kit are trademarks of TERN, Inc. Intel386EX and Intel386SX are trademarks of Intel Coporation. Borland C/C++ are trademarks of Borland International. Microsoft, MS-DOS, Windows, and Windows 95 are trademarks of Microsoft Corporation. IBM is a trademark of International Business Machines Corporation. Version 2.00 October 28, 2010 No part of this document may be copied or reproduced in any form or by any means without the prior written consent of TERN, Inc. © 1998-2010 1950 5 th Street, Davis, CA 95616, USA Tel: 530-758-0180 Fax: 530-758-0181 Email: [email protected] http://www.tern.com Important Notice TERN is developing complex, high technology integration systems. These systems are integrated with software and hardware that are not 100% defect free. TERN products are not designed, intended, authorized, or warranted to be suitable for use in life-support applications, devices, or systems, or in other critical applications. TERN and the Buyer agree that TERN will not be liable for incidental or consequential damages arising from the use of TERN products. It is the Buyer's responsibility to protect life and property against incidental failure. TERN reserves the right to make changes and improvements to its products without providing notice.
    [Show full text]
  • Multiprocessing Contents
    Multiprocessing Contents 1 Multiprocessing 1 1.1 Pre-history .............................................. 1 1.2 Key topics ............................................... 1 1.2.1 Processor symmetry ...................................... 1 1.2.2 Instruction and data streams ................................. 1 1.2.3 Processor coupling ...................................... 2 1.2.4 Multiprocessor Communication Architecture ......................... 2 1.3 Flynn’s taxonomy ........................................... 2 1.3.1 SISD multiprocessing ..................................... 2 1.3.2 SIMD multiprocessing .................................... 2 1.3.3 MISD multiprocessing .................................... 3 1.3.4 MIMD multiprocessing .................................... 3 1.4 See also ................................................ 3 1.5 References ............................................... 3 2 Computer multitasking 5 2.1 Multiprogramming .......................................... 5 2.2 Cooperative multitasking ....................................... 6 2.3 Preemptive multitasking ....................................... 6 2.4 Real time ............................................... 7 2.5 Multithreading ............................................ 7 2.6 Memory protection .......................................... 7 2.7 Memory swapping .......................................... 7 2.8 Programming ............................................. 7 2.9 See also ................................................ 8 2.10 References .............................................
    [Show full text]
  • Xv6 Booting: Transitioning from 16 to 32 Bit Mode
    238P Operating Systems, Fall 2018 xv6 Boot Recap: Transitioning from 16 bit mode to 32 bit mode 3 November 2018 Aftab Hussain University of California, Irvine BIOS xv6 Boot loader what it does Sets up the hardware. Transfers control to the Boot Loader. BIOS xv6 Boot loader what it does Sets up the hardware. Transfers control to the Boot Loader. how it transfers control to the Boot Loader Boot loader is loaded from the 1st 512-byte sector of the boot disk. This 512-byte sector is known as the boot sector. Boot loader is loaded at 0x7c00. Sets processor’s ip register to 0x7c00. BIOS xv6 Boot loader 2 source source files bootasm.S - 16 and 32 bit assembly code. bootmain.c - C code. BIOS xv6 Boot loader 2 source source files bootasm.S - 16 and 32 bit assembly code. bootmain.c - C code. executing bootasm.S 1. Disable interrupts using cli instruction. (Code). > Done in case BIOS has initialized any of its interrupt handlers while setting up the hardware. Also, BIOS is not running anymore, so better to disable them. > Clear segment registers. Use xor for %ax, and copy it to the rest (Code). 2. Switch from real mode to protected mode. (References: a, b). > Note the difference between processor modes and kernel privilege modes > We do the above switch to increase the size of the memory we can address. BIOS xv6 Boot loader 2 source source file executing bootasm.S m. Let’s 2. Switch from real mode to protected mode. expand on this a little bit Addressing in Real Mode In real mode, the processor sends 20-bit addresses to the memory.
    [Show full text]
  • X86 Memory Protection and Translation
    2/5/20 COMP 790: OS Implementation COMP 790: OS Implementation Logical Diagram Binary Memory x86 Memory Protection and Threads Formats Allocators Translation User System Calls Kernel Don Porter RCU File System Networking Sync Memory Device CPU Today’s Management Drivers Scheduler Lecture Hardware Interrupts Disk Net Consistency 1 Today’s Lecture: Focus on Hardware ABI 2 1 2 COMP 790: OS Implementation COMP 790: OS Implementation Lecture Goal Undergrad Review • Understand the hardware tools available on a • What is: modern x86 processor for manipulating and – Virtual memory? protecting memory – Segmentation? • Lab 2: You will program this hardware – Paging? • Apologies: Material can be a bit dry, but important – Plus, slides will be good reference • But, cool tech tricks: – How does thread-local storage (TLS) work? – An actual (and tough) Microsoft interview question 3 4 3 4 COMP 790: OS Implementation COMP 790: OS Implementation Memory Mapping Two System Goals 1) Provide an abstraction of contiguous, isolated virtual Process 1 Process 2 memory to a program Virtual Memory Virtual Memory 2) Prevent illegal operations // Program expects (*x) – Prevent access to other application or OS memory 0x1000 Only one physical 0x1000 address 0x1000!! // to always be at – Detect failures early (e.g., segfault on address 0) // address 0x1000 – More recently, prevent exploits that try to execute int *x = 0x1000; program data 0x1000 Physical Memory 5 6 5 6 1 2/5/20 COMP 790: OS Implementation COMP 790: OS Implementation Outline x86 Processor Modes • x86
    [Show full text]
  • Protected Mode - Wikipedia
    2/12/2019 Protected mode - Wikipedia Protected mode In computing, protected mode, also called protected virtual address mode,[1] is an operational mode of x86- compatible central processing units (CPUs). It allows system software to use features such as virtual memory, paging and safe multi-tasking designed to increase an operating system's control over application software.[2][3] When a processor that supports x86 protected mode is powered on, it begins executing instructions in real mode, in order to maintain backward compatibility with earlier x86 processors.[4] Protected mode may only be entered after the system software sets up one descriptor table and enables the Protection Enable (PE) bit in the control register 0 (CR0).[5] Protected mode was first added to the x86 architecture in 1982,[6] with the release of Intel's 80286 (286) processor, and later extended with the release of the 80386 (386) in 1985.[7] Due to the enhancements added by protected mode, it has become widely adopted and has become the foundation for all subsequent enhancements to the x86 architecture,[8] although many of those enhancements, such as added instructions and new registers, also brought benefits to the real mode. Contents History The 286 The 386 386 additions to protected mode Entering and exiting protected mode Features Privilege levels Real mode application compatibility Virtual 8086 mode Segment addressing Protected mode 286 386 Structure of segment descriptor entry Paging Multitasking Operating systems See also References External links History https://en.wikipedia.org/wiki/Protected_mode
    [Show full text]
  • Chapter 2 Powerpc Register Set
    Chapter 2 PowerPC Register Set 20 20 This chapter describes the register organization defined by the three levels of the PowerPC U architecture—user instruction set architecture (UISA), virtual environment architecture V (VEA), and operating environment architecture (OEA). The PowerPC architecture defines O register-to-register operations for all computational instructions. Source data for these instructions are accessed from the on-chip registers or are provided as immediate values embedded in the opcode. The three-register instruction format allows specification of a target register distinct from the two source registers, thus preserving the original data for use by other instructions and reducing the number of instructions required for certain operations. Data is transferred between memory and registers with explicit load and store instructions only. Note that the handling of reserved bits in any register is implementation-dependent. Software is permitted to write any value to a reserved bit in a register. However, a subsequent reading of the reserved bit returns 0 if the value last written to the bit was 0 and returns an undefined value (may be 0 or 1) otherwise. This means that even if the last value written to a reserved bit was 1, reading that bit may return 0. 2.1 PowerPC UISA Register Set The PowerPC UISA registers, shown in Figure 2-1, can be accessed by either user- or U supervisor-level instructions (the architecture specification refers to user-level and supervisor-level as problem state and privileged state respectively). The general-purpose registers (GPRs) and floating-point registers (FPRs) are accessed as instruction operands.
    [Show full text]
  • A Comparison of Protection Lookaside Buffers and the PA-RISC
    rI3 HEWLETT ~~PACKARD A Comparison ofProtection Lookaside Buffers and the PA·RISC Protection Architecture John Wilkes, Bart Sears Computer Systems Laboratory HPL-92-55 March 1992 processor architecture, Eric Koldinger and others at the University of single address space, 64­ Washington Department of Computer Science have bitaddressing, protection, proposed a new model for memory protection in PA-RISe, protection single-address-space architectures. This paper lookaside buffers, PLB, compares the Washington proposal with what translation lookaside already exists in PA-RISC, and suggests some buffers,TLB, cache incremental improvements to the latter that would indexing, virtually­ provide most of the benefits of the former. addressed caches Internal Accession Date Only © Copyright Hewlett-Packard Company 1992 1 Introduction A recent technical report by Eric Koldinger and others [Koldinger91] proposes a new model for managing protectioninformationinsingle address space processors. This paper is one outcome of discussions withthe authors about the real differences betweentheir proposal and the scheme usedinPA-RISC[Lee89,HPPA90]:it offers a restatement of the newproposal, a comparisonwith the existing PA-RISCarchitecture, and some thoughts onhow the PA-RISCarchitecture mightbe extended in the future to provide some of the benefits that the PLBidea was trying to achieve. The reader is assumed to be familiar withmodem TLB,cache and processor architectures; with luck, sufficient information is provided in this paper that detailed prior knowledge about either the Washington proposal or PA-RISCisn't required. Example To help illustrate some of the finer points of the different protectionmodels, anexample based on the LRPC work of Brian Bershad is used [Bershad90] (see Figure 1).
    [Show full text]
  • Intel® 64 and IA-32 Architectures Software Developer's Manual
    Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3B: System Programming Guide, Part 2 NOTE: The Intel® 64 and IA-32 Architectures Software Developer's Manual consists of five volumes: Basic Architecture, Order Number 253665; Instruction Set Reference A-M, Order Number 253666; Instruction Set Reference N-Z, Order Number 253667; System Programming Guide, Part 1, Order Number 253668; System Programming Guide, Part 2, Order Number 253669. Refer to all five volumes when evaluating your design needs. Order Number: 253669-029US November 2008 INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANT- ED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. UNLESS OTHERWISE AGREED IN WRITING BY INTEL, THE INTEL PRODUCTS ARE NOT DESIGNED NOR IN- TENDED FOR ANY APPLICATION IN WHICH THE FAILURE OF THE INTEL PRODUCT COULD CREATE A SITUA- TION WHERE PERSONAL INJURY OR DEATH MAY OCCUR. Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the absence or characteristics of any features or instructions marked "reserved" or "unde- fined." Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them.
    [Show full text]
  • AMD 64-Bit Technology
    Preliminary Information AMD 64-Bit Technology The AMD x86-64™ Architecture Programmers Overview Publication # 24108 Rev: A Issue Date: August 2000 Preliminary Information © 2000 Advanced Micro Devices, Inc. All rights reserved. The contents of this document are provided in connection with Advanced Micro Devices, Inc. (“AMD”) products. AMD makes no representations or warranties with respect to the accuracy or completeness of the contents of this publication and reserves the right to make changes to specifications and product descriptions at any time without notice. No license, whether express, implied, arising by estoppel or otherwise, to any intellectual property rights is granted by this publication. Except as set forth in AMD’s Standard Terms and Conditions of Sale, AMD assumes no liability whatsoever, and disclaims any express or implied warranty, relating to its products including, but not limited to, the implied warranty of merchantability, fitness for a particular purpose, or infringement of any intellectual property right. AMD’s products are not designed, intended, authorized or warranted for use as components in systems intended for surgical implant into the body, or in other applications intended to support or sustain life, or in any other applica- tion in which the failure of AMD’s product could create a situation where per- sonal injury, death, or severe property or environmental damage may occur. AMD reserves the right to discontinue or make changes to its products at any time without notice. Trademarks AMD, the AMD logo, x86-64, AMD Athlon, and combinations thereof are trademarks of Advanced Micro Devices, Inc. MMX is a trademark of Intel Corporation.
    [Show full text]
  • Operating Systems & Virtualisation Security Knowledge Area
    Operating Systems & Virtualisation Security Knowledge Area Issue 1.0 Herbert Bos Vrije Universiteit Amsterdam EDITOR Andrew Martin Oxford University REVIEWERS Chris Dalton Hewlett Packard David Lie University of Toronto Gernot Heiser University of New South Wales Mathias Payer École Polytechnique Fédérale de Lausanne The Cyber Security Body Of Knowledge www.cybok.org COPYRIGHT © Crown Copyright, The National Cyber Security Centre 2019. This information is licensed under the Open Government Licence v3.0. To view this licence, visit: http://www.nationalarchives.gov.uk/doc/open-government-licence/ When you use this information under the Open Government Licence, you should include the following attribution: CyBOK © Crown Copyright, The National Cyber Security Centre 2018, li- censed under the Open Government Licence: http://www.nationalarchives.gov.uk/doc/open- government-licence/. The CyBOK project would like to understand how the CyBOK is being used and its uptake. The project would like organisations using, or intending to use, CyBOK for the purposes of education, training, course development, professional development etc. to contact it at con- [email protected] to let the project know how they are using CyBOK. Issue 1.0 is a stable public release of the Operating Systems & Virtualisation Security Knowl- edge Area. However, it should be noted that a fully-collated CyBOK document which includes all of the Knowledge Areas is anticipated to be released by the end of July 2019. This will likely include updated page layout and formatting of the individual Knowledge Areas KA Operating Systems & Virtualisation Security j October 2019 Page 1 The Cyber Security Body Of Knowledge www.cybok.org INTRODUCTION In this Knowledge Area, we introduce the principles, primitives and practices for ensuring se- curity at the operating system and hypervisor levels.
    [Show full text]
  • Chapter 3 Protected-Mode Memory Management
    CHAPTER 3 PROTECTED-MODE MEMORY MANAGEMENT This chapter describes the Intel 64 and IA-32 architecture’s protected-mode memory management facilities, including the physical memory requirements, segmentation mechanism, and paging mechanism. See also: Chapter 5, “Protection” (for a description of the processor’s protection mechanism) and Chapter 20, “8086 Emulation” (for a description of memory addressing protection in real-address and virtual-8086 modes). 3.1 MEMORY MANAGEMENT OVERVIEW The memory management facilities of the IA-32 architecture are divided into two parts: segmentation and paging. Segmentation provides a mechanism of isolating individual code, data, and stack modules so that multiple programs (or tasks) can run on the same processor without interfering with one another. Paging provides a mech- anism for implementing a conventional demand-paged, virtual-memory system where sections of a program’s execution environment are mapped into physical memory as needed. Paging can also be used to provide isolation between multiple tasks. When operating in protected mode, some form of segmentation must be used. There is no mode bit to disable segmentation. The use of paging, however, is optional. These two mechanisms (segmentation and paging) can be configured to support simple single-program (or single- task) systems, multitasking systems, or multiple-processor systems that used shared memory. As shown in Figure 3-1, segmentation provides a mechanism for dividing the processor’s addressable memory space (called the linear address space) into smaller protected address spaces called segments. Segments can be used to hold the code, data, and stack for a program or to hold system data structures (such as a TSS or LDT).
    [Show full text]