`
`
`MOve,xze
`Jeenye
`-SYSTE!I
`
`system
`
`Mobile operating
`
`
`Multithread
`system
`
`Ay
`
`z Deadlock i
`
`eR——
`
`2
`Load
`balancing 9
`
`Blue scream
`of death@
`
` Process
`
`scheduler
`
`
`
`
`bRiBS Embedded
`
`
`a algorithm
`Ostrich
`oie system
`-
`y'
`
`
`
`Race
`
`i Bed DeUA
`KX VAUS AUS,
`
`iF" "Vy
`oe Interrupt
`
` management
`
`DRERYWSQC
` Dual core
`ENBAUM
`
`
`
`
`Bootin
`the ¢
`computer
`
`
`
`Linux
`system
`
`IPR2023-01465
`CrowdStrike EX1007 Page 1
`
`IPR2023-01465
`CrowdStrike EX1007 Page 1
`
`
`
`Library of Congress Cataloging-in-Publication Data on File.
`
`Editorial Director, Computer Science, Engineering, and Advanced Mathematics: Marcia J. Horton
`Executive Editor: Tracy Dunkelberger
`Editorial Assistant: Melinda Haggerty
`Associate Editor: ReeAnne Davies
`Senior Managing Editor: Scott Disanno
`Production Editor: Irvin Zucker
`Cover Concept: AndrewS. Tanenbaum and Tracy Dunkelberger
`Cover Design: Tamara Newnam
`CoverIllustrator: Steve Lefkowitz
`Interior design: Andrew S. Tanenbaum
`Typesetting: Andrew S. Tanenbaum
`Art Director: Kenny Beck
`Art Editor: Gregory Dulles
`MediaEditor: David Alick
`Manufacturing Manager: Alan Fischer
`Manufacturing Buyer: Lisa McDowell
`Marketing Manager: Mack Patterson
`
`Upper Saddle River, NJ 07458
`
`© 2008 Pearson Education,Inc.
`Pearson Prentice Hall
`Pearson Education, Inc.
`
`All rights reserved. No part of this book may be reproduced in any form or by any means, without permission in writing from the
`publisher.
`
`.
`™.
`:
`Pearson Prentice Hall’™ is a trademark of Pearson Education, Inc.
`The author and publisher of this book have used their best efforts in preparing this book. These efforts include the development,
`research, and testing of the theories and programsto determine their effectiveness. The author and publisher make no warranty of any
`kind, expressed or implied, with regard to these programsor the documentation contained in this book. The author and publisher
`shall not be liable in any event for incidental or consequential damagesin connection with, or arising out of, the
`furnishing, performance,or use of these programs.
`
`Printed in the United States of America
`
`1098765432 1
`
`ISBN O-13-600663-4
`978-0-13-b00b633-2
`
`Pearson Education Ltd., London
`Pearson Education Australia Pty. Ltd., Sydney
`Pearson Education Singapore, Pte. Ltd.
`Pearson Education North Asia Ltd., Hong Kong
`Pearson Education Canada, Inc., Toronto
`Pearson Educacién de Mexico, S.A. de C.V.
`Pearson Education—Japan, Tokyo
`Pearson Education Malaysia, Pte. Ltd.
`Pearson Education, Inc., Upper Saddle River, New Jersey
`
`IPR2023-01465
`CrowdStrike EX1007 Page 2
`
`IPR2023-01465
`CrowdStrike EX1007 Page 2
`
`
`
`60
`
`INTRODUCTION
`
`CHAP,
`
`|
`
`With Windows,the situation is radically different. To start with, the library
`calls and the actual systemcalls are highly decoupled. Microsoft has defined a set
`of procedures called the Win32 API (Application Program Interface) that pro-
`grammers are expected to use to get operating system services. This interface jg
`(partially) supported on all versions of Windows since Windows 95. By decou-
`pling the interface from the actual system calls, Microsoft retains the ability to
`change the actual system calls in time (even from release to release) without
`invalidating existing programs. What actually constitutes Win32 is also slightly
`ambiguous because Windows 2000, Windows XP, and WindowsVista have many
`new calls that were notpreviously available.
`In this section, Win32 meansthe in-
`terface supported byall versions of Windows.
`The number of Win32 API calls is extremely large, numbering in the
`thousands. Furthermore, while many of them do invoke system calls, a substantial
`numberare carried out entirely in user space. As a consequence, with Windowsit
`is impossible to see what is a system call (i.e., performed by the kernel) and what
`is simply a user-spacelibrary call.
`In fact, what is a system call in one version of
`Windows may be donein user space in a different version, and vice versa. When
`we discuss the Windowssystem calls in this book, we will use the Win32 proce-
`dures (where appropriate) since Microsoft guarantees that these will be stable
`over time. But it is worth remembering that not all of them are true system calls
`(i.e., traps to the kernel).
`The Win32 API has a huge numberof calls for managing windows, geometric
`figures, text, fonts, scrollbars, dialog boxes, menus, and other features of the GUI.
`To the extent that the graphics subsystem runs in the kernel (true on some ver-
`sions of Windowsbutnot onall), these are system calls; otherwise they are justli-
`brary calls. Should we discuss these calls in this book or not? Since they are not
`really related to the function of an operating system, we have decided notto, even
`though they may be carried out by the kernel. Readers interested in the Win32
`API should consult one of the many books on the subject (e.g., Hart, 1997; Rector
`and Newcomer, 1997; and Simon, 1997).
`Even introducing all the Win32 API calls here is out of the question, so we
`will restrict ourselves to those calls that roughly correspondto the functionality of
`the UNIX calls listed in Fig. 1-18. These are listed in Fig. 1-23.
`Let us nowbriefly go through thelist of Fig. 1-23. CreateProcess creates a
`new process.
`It does the combined work of fork and execve in UNIX.
`It has many
`parameters specifying the properties of the newly created process. Windows does
`not have a process hierarchy as UNIX does sothere is no conceptof a parent proc-
`ess and a child process. After a process is created,
`the creator and createe are
`equals. WaitForSingleObject is used to wait for an event. Many possible events
`can be waited for, If the parameter specifies a process, then the caller waits for
`the specified process to exit, which is done using ExitProcess.
`The next six calls operate onfiles and are functionally similar to their UNIX
`counterparts although they differ in the parameters and details. Still, files can be
`
`IPR2023-01465
`CrowdStrike EX1007 Page 3
`
`IPR2023-01465
`CrowdStrike EX1007 Page 3
`
`
`
`
`
`interface
`
`
`|
`
`
`
`Library
`
`Standardsutility programs
`(shell, editors, compliers etc)
`
`Standard library
`(open, close, read, write, fork, etc)
`
`System
`call
`interface
`
`730
`
`CASE STUDY1: LINUX
`
`CHAP. 19
`
`I look for patterns in files. Please enter your pattern.”’ After getting the pattern,
`grep prompts for a file name. Thenit asksif there are any morefile names. Fina).
`ly, it summarizes whatit is going to do and asksif that is correct. While this king
`of user interface may besuitable for rank novices, it drives skilled programmers
`up the wall. What they wantis a servant, not a nanny.
`
`10.2.2 Interfaces to Linux
`
`A Linux system can be regarded as a kind of pyramid, as illustrated jn
`Fig. 10-1. At the bottom is the hardware, consisting of the CPU, memory, disks, a
`monitor and keyboard, and other devices. Running on the bare hardwareis the op-
`erating system.
`Its function is to control the hardware and provide a system cal]
`interface to all the programs. These system calls allow user programsto create
`and manageprocesses, files, and other resources.
`
`User
`interface
`
`Users
`
`|
`
`User
`mode
`
`Linux operating system
`(process management, memory management,
`Kernel mode
`
`the file system, I/O, etc)
`yt
`
`
`Hardware
`(CPU, memory,disks, terminals, etc)
`
`
`Figure 10-1. The layers in a Linux system.
`
`Programs make system calls by putting the arguments in registers (or some-
`times, on the stack), and issuing trap instructions to switch from user modeto ker-
`nel mode. Since there is no way to write a trap instruction in C, a library is pro-
`vided, with one procedure per system call. These procedures are written in assem-
`bly language, but can be called from C. Each onefirst puts its arguments in the
`proper place, then executes the trap instruction. Thus to execute the read system
`call, a C program can call the read library procedure. As an aside,it is the library
`interface, and not the system call interface, that is specified by POSIX.
`In other
`words, POSIX tells which library procedures a conformant system must supply,
`what their parameters are, what they must do, and what results they must return.
`It does not even mentionthe actual system calls.
`
`IPR2023-01465
`CrowdStrike EX1007 Page 4
`
`IPR2023-01465
`CrowdStrike EX1007 Page 4
`
`
`
`
`
`SEC. 10.3
`
`PROCESSES IN LINUX
`
`755
`
`or modify the affinity requirements of a select thread. Finally,
`the scheduler per-
`forms periodic load balancing across runqueues of different C
`PUs to ensure that
`the system load Is well balanced, while still meeting certain pe
`formanceor affin-
`ity requirements.
`The scheduler considers only runnable tasks, which are placed on the ap-
`propriate runqueue. Tasks which are not runnable and are waiting on various I/O
`operations or other kernel events are placed on anotherdata structure, waitqueue,
`A waitqueue is associated with each eventthat tasks may wait on. The head of the
`waitqueue includes a pointerto a linked list of tasks and a spinlock. The spinlock
`is necessary sO as to ensure that the waitqueue can be concurrently manipulated
`through both the main kernel code andinterrupt handlers or other asynchronous
`invocations.
`In fact, the kernel code contains synchronization variables in numerous loca-
`tions. Earlier Linux kernels had just one big kernel lock (BLK). This proved
`highly inefficient, particularly on multiprocessor platforms, since it prevented
`processes on different CPUs from executing kernel code concurrently. Hence,
`many new synchronization points were introduced at muchfiner granularity.
`
`10.3.5 Booting Linux
`
`the following steps
`Details vary from platform to platform, but in general
`represent the boot process. When the computerstarts, the BIOS performs Power-
`On-Self-Test (POST) andinitial device discovery and initialization, since the OS’
`boot process may rely on access to disks, screens, keyboards, and so on. Next, the
`first sector of the bootdisk, the MBR (Master Boot Record), is read into a fixed
`memory location and executed. This sector contains a small (512-byte) program
`that loads a standalone program called boot from the boot device, usually an IDE
`or SCSIdisk. The boot programfirst copiesitself to a fixed high-memory address
`to free up low memory for the operating system.
`Once moved, boot reads the root directory of the boot device. To dothis,it
`must understandthefile system and directory format, which is the case with some
`bootloaders
`such as GRUB (GRand Unified Bootloader). Other popular
`bootloaders, such asIntel’s LILO,do notrely on any specific filesystem. Instead,
`they need a block map and low-level addresses, which describe physical sectors,
`heads, and cylinders, to find the relevant sectors to be loaded.
`Then boot reads in the operating system kernel and jumpsto it. At this point,
`it has finished its job and the kernelis running.
`The kernel start-up code is written in assembly language and is highly ma-
`chine dependent. Typical work includes setting up the kernel stack,identifying the
`CPU type, calculating the amount of RAM present, disabling interrupts, enabling
`the MMU,andfinally calling the C-language main procedure to start the main
`part of the operating system.
`
`IPR2023-01465
`CrowdStrike EX1007 Page 5
`
`IPR2023-01465
`CrowdStrike EX1007 Page 5
`
`
`
`756
`
`CASE STUDY1: LINUX
`
`CHAP. 19
`
`The C code also has considerable initialization to do, but this is more logical
`than physical.
`It starts out by allocating a message buffer to help debug boot
`problems.
`Asinitialization proceeds, messages are written here about what is
`happening, so that they can befished out after a bootfailure by a special diagnos-
`tic program. Think of this as the operating system’s cockpit flight recorder (the
`black box investigators look for after a plane crash).
`Next the kernel data structures are allocated. Most are fixed size, but a few
`such as the page cache and certain page table structures, depend on the amount of
`RAMavailable.
`At this point the system begins autoconfiguration. Using configuration files
`telling what kinds of I/O devices mightbe present, it begins probing the devicesto
`see which onesactually are present. If a probed device responds to the probe, it is
`added to a table of attached devices.
`If it fails to respond, it is assumed to be
`absent and ignored henceforth. Unlike traditional UNIX versions, Linux device
`drivers do not need tobestatically linked and may be loaded dynamically (as can
`all versions of MS-DOS and Windows,incidentally).
`The arguments for and against dynamically loading drivers are interesting and
`worth stating briefly. The main argument for dynamic loading is that a single bi-
`nary can be shipped to customers with divergent configurations and have it auto-
`matically load the drivers it needs, possibly even over a network. The main argu-
`ment against dynamic loading is security. If you are runningasecuresite, such as
`a bank’s database or a corporate Webserver, you probably want to makeit impos-
`sible for anyone to insert random code into the kernel. The system administrator
`may keep the operating system sources and object files on a secure machine, do
`all system builds there, and ship the kernel binary to other machines overa local
`area network. If drivers cannot be loaded dynamically, this scenario prevents ma-
`chine operators and others who know the superuser password from injecting mali-
`cious or buggy code into the kernel. Furthermore, at large sites, the hardware con-
`figuration is known exactly at
`the time the system is compiled and linked.
`Changes are sufficiently rare that having to relink the system when a new hard-
`ware device is addedis not an issue.
`Onceall the hardware has been configured, the next thing to do is to carefully
`handcraft process 0, set up its stack, and run it. Process 0 continuesinitialization,
`doing things like programmingthe real-time clock, mountingthe rootfile system,
`and creating init (process 1) and the page daemon (process2).
`Init checksits flags to see if it is supposed to come up single user or mul-
`tiuser.
`In the formercase, it forks off a process that executess the shell and waits
`for this process to exit.
`In the latter case, it forks off a process that executes the
`system initialization shell script, /etc/rc, which can do file system consistency
`checks, mountadditional file systems, start daemon processes, and so on. Then it
`reads /etc/ttys, which lists the terminals and some of their properties. For each
`enabled terminal, it forks off a copy ofitself, which does some housekeeping and
`then executess a program called getty.
`
`IPR2023-01465
`CrowdStrike EX1007 Page 6
`
`IPR2023-01465
`CrowdStrike EX1007 Page 6
`
`
`
`PROCESSESIN LINUX
`
`757
`
`SEC. 10.3
`Getty sets the line speed and other properties for each line (some of which
`may be modems,for example), and then types
`login:
`on the terminal's screen and tries to read the user’s name from the keyboard.
`When someonesits downat the terminal and provides a login name, gefty termi-
`nates by executing /binhlogin, the login program. Login then asks for a password,
`encrypts it, and verifies it against the encrypted password stored in the password
`file, /ete/passwd. If it is correct, login replaces itself with the user’s shell, which
`then waits forthe first command.If it is incorrect, /oginjust asks for another user
`
`name. This mechanism is shown in Fig. 10-11 for a system with three terminals.
`% cp fi f2
`
`Process 0
`
`
`
`Terminal 2
`
`Figure 10-11. The sequence of processes used to boot some Linux systems.
`
`In the figure, the getty process running for terminal0 is still waiting for input.
`On terminal 1, a user has typed a login name, so getty has overwritten itself with
`login, which is asking for the password. A successful login has already occurred
`on terminal 2, causing the shell to type the prompt (%). The user then typed
`
`cp fi f2
`
`which has caused the shell to fork off a child process and have that process exe-
`cute the cp program. The shell is blocked, waiting for the child to terminate, at
`which time the shell will type another prompt and read from the keyboard. If the
`user at terminal 2 had typed cc instead of cp, the main program of the C compiler
`would have been started, which in turn would have forked off more processes to
`run the various compilerpasses.
`
`IPR2023-01465
`CrowdStrike EX1007 Page 7
`
`IPR2023-01465
`CrowdStrike EX1007 Page 7
`
`
`
`829
`PROGRAMMING WINDOWSVISTA
`SEC. 11.2
`‘al
`prefix strings, like "\\").
`In Win32, files are accessed relative to drive
`special P
`;
`oa.
`jettel- The NT directory \DosDevices contains a set of symbolic links from
`drive letters to the actual device objects. For example \DosDevices\C: might be
`4 link to \Device \HarddiskVolumel. This directory also contains links for other
`win32 devices, such as COM1:, LPTI:, and NUL:(forthe serial andprinter ports,
`and the all-important null device),
`\DosDevices is really a symbolic link to \??
`which was chosen for efficiency. Another NT directory, \BaseNamedObjects is
`ysed to store miscellaneous named kernel-mode objects accessible through the
`win32 API. These include synchronization objects like semaphores, shared mem-
`ory, timers, and communication ports. MS-DOS and device names.
`In addition to low-level system interfaces we have described, the Win32 API
`also supports many functions for GUI operations, including all the calls for man-
`aging the graphical interface of the system. There are calls for creating, destroy-
`ing, managing and using windows, menus, tool bars, status bars, scroll bars, dia-
`log boxes, icons, and many more items that appear on the screen. There are calls
`for drawing geometric figures, filling them in, managing the color palettes they
`use, dealing with fonts, and placing icons on the screen. Finally, there are calls
`for dealing with the keyboard, mouse and other human input devices as well as
`audio, printing, and other output devices.
`The GUI operations work directly with the win32k.sys driver using special in-
`terfaces to access these functions in kernel mode from user-modelibraries. Since
`these calls do not involve the core system calls in the NTOS executive, we will
`not say more about them.
`
`11.2.3 The WindowsRegistry
`
`The root of the NT namespace is maintained in the kernel. Storage, such as
`file system volumes, is attached to the NT namespace. Since the NT namespace
`is constructed afresh every time the system boots, how does the system know
`about any specific details of the system configuration? The answer is that Win-
`dows attaches a special kind of file system (optimized for small files) to the NT
`namespace. This file system is called the registry. The registry is organized into
`separate volumescalled hives. Each hive is kept in a separate file (in the direc-
`tory C:\ Windows \ system32 \ config \ of the boot volume). When a Windowssys-
`tem boots, one particular hive named SYSTEMis loaded into memory by the same
`boot program that loads the kernel and other boot files, such as boot drivers, from
`the boot volume.
`Windowskeeps a great deal of crucial information in the SYSTEM hive,in-
`cluding information about what drivers to use with what devices, what software to
`run initially, and many parameters governing the operation of the system. This
`information is used even by the boot program itself to determine which drivers are
`boot drivers, being needed immediately upon boot. Such drivers include those
`
`IPR2023-01465
`CrowdStrike EX1007 Page 8
`
`IPR2023-01465
`CrowdStrike EX1007 Page 8
`
`
`
`830
`
`CASE STUDY 2: WINDOWSVISTA
`
`CHAP.
`
`||
`
`that understandthe file system and disk drivers for the volume containing the op-
`erating system itself.
`Other configuration hives are used after the system boots to describe infor-
`mation about the software installed on the system, particular users, and the classes
`of user-mode COM (Component Object-Model) objects that are installed on the
`system. Login information for local users is kept in the SAM (Security Access
`Manager)hive. Information for network users is maintained by the /sass service in
`the SECURITY hive, and coordinated with the network directory servers so that
`users can have a common account name and password across an entire network.
`A list of the hives used in WindowsVista is shownin Fig. 11-11.
`
`
`
`Use
`Mounted name
`HKLM TEM
`OS configuration information, used by kernel
`SYSTEM
`
`
`HKLM DWARE
`In-memory hive recording hardware detected
`HARDWARE
`
`HKLM BCD*
`Boot Configuration Database
`HKLM
`Local user accountinformation
`HKLM URITY
`Isass’ account and other security information
`
`HKEY_USERS .DEFAULT|Default hive for new users
`HKEY_USERS<userid>
`User-specific hive, kept in home directory 7
`
`HKLM TWARE
`Application classes registered by COM
`
`COMPONENTS|HKLMNENTS Manifests and dependencies for sys. componer
`
`Figure 11-11. The registry hives in Windows Vista. HKLM isa short-hand for
`HKEY_LOCAL_MACHINE.
`
`Prior to the introduction of the registry, configuration information in Windows
`was kept in hundredsof.ini (initialization) files spread across the disk. Theregis-
`try gathers these files into a central store, which is available early in the process
`of booting the system. This is important for implementing Windows plug-and-
`play functionality. But the registry has become very disorganized as Windows
`has evolved. There are poorly defined conventions about how the configuration
`information should be arranged, and many applications take an ad hoc approach.
`Mostusers, applications, and all drivers run with full privileges, and frequently
`modify system parameters in the registry directly—sometimes interfering with
`each other and destabilizing the system.
`The registry is a strange cross between a file system and a database, and yet
`really unlike either. Entire books have been written describing the registry (Born,
`1998; Hipson, 2000; and Ivens, 1998), and many companies have sprungup to sell
`special software just to manage the complexity of the registry.
`To explore the registry Windows has a GUI program called regedit that al-
`lows you to open and explore the directories (called keys) and data items (called
`values). Microsoft’s new PowerShell scripting language can also be useful for
`walking through the keys and valuesofthe registry as if they were directories and
`
`IPR2023-01465
`CrowdStrike EX1007 Page 9
`
`IPR2023-01465
`CrowdStrike EX1007 Page 9
`
`
`
`sec.
`
`11.2
`
`PROGRAMMING WINDOWSVISTA
`
`831
`
`files. A more interesting tool to use is procmon, which is available from Micro-
`<oft’s tools’ Website: www.microsoft. com/technet/sysinternals.
`~
`Procmon watchesall the registry accessesthat take place in the system andis
`very illuminating. Some programs will access the same key over and overtens of
`thousands of times.
`.
`.
`As the name implies, regedit allows users to edit the registry—but be very
`careful if you ever do.
`It is very easy to render your system unable to boot, or
`damage the installation of applications so that you cannot fix them without a lot of
`wizardry. Microsoft promised to clean up the registry in future releases, but for
`nowit is a huge mess—far more complicated than the configuration information
`maintained in UNIX.
`Beginning with Windows Vista Microsoft has introduced a kernel-based
`transaction manager with support for coordinated transactions that span bothfile
`system and registry operations. Microsoft plans to use this facility in the future to
`avoid some of the metadata corruption problems that occur when software instal-
`lation does not complete correctly and leaves aroundpartial state in the system di-
`rectories and registry hives.
`The registry is accessible to the Win32 programmer. There are calls to create
`and delete keys, look up values within keys, and more. Some of the more useful
`ones are listed in Fig. 11-12.
`
`
`
`Description
`Win32 API function
`
`
`
`RegCreateKeyEx
`Create a newregistry key
`RegDeleteKey
`Delete a registry key
`
`
`RegOpenKeyEx
`Opena keyto get a handletoit
`
`
`
`RegEnumKeyEx
`Enumerate the subkeys subordinate to the key of the handle
`RegQueryValueEx
`Look up the data for a value within a key
`
`
`
`
`
`Figure 11-12. Some of the Win32 APIcalls for using the registry
`
`When the system is turned off, most of the registry information is stored on
`the disk in the hives. Becausetheir integrity is so critical to correct system func-
`tioning, backups are made automatically and metadata writes are flushed to disk
`(0 prevent corruption in the event of a system crash. Loss of the registry requires
`reinstalling all software on the system.
`
`11.3 SYSTEM STRUCTURE
`
`In the previous sections we examined Windows Vista as seen by the pro-
`stammer writing code for user mode. Now weare going to look under the hood
`'0 see how the system is organized internally, what the various components do,
`
`IPR2023-01465
`CrowdStrike EX1007 Page 10
`
`IPR2023-01465
`CrowdStrike EX1007 Page 10
`
`
`
`gpc. 113
`
`SYSTEM STRUCTURE
`
`847
`
`There are other drivers that also implement such arrangements, which Windows
`calls mini-ports. The shared functionality is in a class driver. For example,
`common functionality for SCSI or IDE disks or USB devices is supplied by a
`class driver, which mini-port drivers for each particular type of such devices link
`to as alibrary.
`We will not discuss any particular device driverin this chapter, but will pro-
`vide more detail about how the I/O managerinteracts with device drivers in Sec.
`{1.7.
`
`11.3.2 Booting WindowsVista
`
`Getting an operating system to run requires several steps. When a computer
`is turned on, the CPU is initialized by the hardware, and thensetto start executing
`a program in memory. But the only available code is in some form of nonvolatile
`CMOS memorythatis initialized by the computer manufacturer (and sometimes
`updated by the user, in a process called flashing). On most PC’s this initial pro-
`oram is the BIOS (Basic Input/Output System) which knows how to talk to the
`standard types of devices found on a PC. The BIOSbrings up WindowsVista by
`first loading small bootstrap programs found at the beginning of the disk drive
`partitions.
`The bootstrap programs know how to read enough information off a file sys-
`tem volume to find the standalone Windows BootMgrprogram in the root direc-
`tory. BootMgrdetermines if the system had previously been hibernated or wasin
`stand-by mode(special power-saving modes that allow the system to turn back on
`without booting).
`If so, BootMgr loads and executes WinResume.exe. Otherwise
`it loads and executes WinLoad.exe to perform a fresh boot. WinLoad loads the
`boot components of the system into memory:
`the kernel/executive (normally
`ntoskrnl.exe),
`the HAL (hal.dil),
`the file containing the SYSTEM hive,
`the
`Win32k.sys driver containing the kernel-mode parts of the Win32 subsystem, as
`well as images of any other drivers that are listed in the SYSTEM hive as boot
`drivers—meaning they are needed whenthe system first boots.
`Once the Windows boot components are loaded into memory, control is given
`to low-level code in NTOS which proceedstoinitialize the HAL, kernel and exec-
`utive layers, link in the driver images, and access/update configuration data in the
`SYSTEM hive. After all
`the kernel-mode components are initialized, the first
`user-mode process is created using for running the smss.exe program (which is
`like /etc/init in UNIX systems).
`The Windowsboot programs have logic to deal with common problemsusers
`encounter when booting the system fails. Sometimesinstallation of a bad device
`driver, or running a program like regedit (which can corrupt the SYSTEM hive),
`will prevent
`the system from booting normally. There is support for ignoring
`recent changes and booting to the /ast known good configuration of the system.
`Other boot options include safe-boot which turns off many optional drivers and
`
`IPR2023-01465
`CrowdStrike EX1007 Page 11
`
`IPR2023-01465
`CrowdStrike EX1007 Page 11
`
`
`
`861
`
`SEC. 11.3
`SYSTEM STRUCTURE
`Windows Vista makes significant use Of user-mode service processes to ex-
`tend the functionality of the system. Some of these services are strongly
`tied x
`the 0peration of kernel-mode components, such as /sass.exe which is the local fo
`curity authentication service which manages the token objects that represent
`yser-identity, as well as managing encryption keys used by the file system. The
`uiser-mode plug-and-play manager is responsible for determining the correct driv-
`er to use When a new hardware device 1s encountered,installing it, and telling the
`kernel to load it. Many facilities provided by third parties, such as antivirus and
`digital rights management, are implemented as a combination of kernel-mode
`drivers and user-mode services.
`In WindowsVista taskmgr.exe has a tab whichidentifies the services running
`on the system. (Earlier versions of Windowswill showalist of services with the
`net start command). Multiple services can be seen to be running in the same
`rocess (svchost.exe). Windowsdoesthis for many of its own boot-time services
`to reduce the time needed to start up the system. Services can be combined into
`the same process as long as they can safely operate with the same security creden-
`tials.
`Within each of the shared service processes, individual services are loaded as
`DLLs. They normally share a poolof threads using the Win32 threadpool facility,
`so that only the minimal number of threads needs to be running acrossall the
`resident services.
`Services are common sources of security vulnerabilities in the system because
`they are often accessible remotely (depending on the TCP/IP firewall and IP Se-
`curity settings), and not all programmers whowrite services are as careful as they
`should be to validate the parameters and buffers that are passed in via RPC.
`The number of services running constantly in Windowsis staggering. Yet
`few of those services ever receive a single request, thoughif they doit is likely to
`be from an attacker attempting to exploit a vulnerability. As a result more and
`more services in Windowsare turned off by default, particularly on versions of
`Windows Server.
`
`11.4 PROCESSES AND THREADS IN WINDOWSVISTA
`
`Windows has a number of concepts for managing the CPU and grouping re-
`sources together.
`In the following sections we will examine these, discussing
`some of the relevant Win32 API calls, and show how they are implemented.
`
`11.4.1 Fundamental Concepts
`i WindowsVista processes are containers for programs. They hold the virtu-
`al a
`ei ass space, the handles that refer to kernel-mode objects, and threads.
`In
`th
`role as a container for threads they hold commonresources used for thread
`
`IPR2023-01465
`CrowdStrike EX1007 Page 12
`
`IPR2023-01465
`CrowdStrike EX1007 Page 12
`
`
`
`INPUT/OUTPUT IN WINDOWSVISTA
`pc. 17
`11.7.3 Implementation of 1/O
`
`901
`
`the power
`The Windows I/O system consists of the plug-and-play services,
`manager,
`the V/O manager, and the device driver model. Plug-and-play detects
`changes in hardware configuration and builds or tears down the device stacks for
`each device, as well as causing the loading and unloading of device drivers. The
`power manager adjusts the powerstate of the I/O devices to reduce system power
`consumption whendevices are not in use. The I/O managerprovides support for
`manipulating 1/O kernel objects, and IRP-based operations like loCallDrivers and
`loCompleteRequest. But most of the work required to support Windows I/O is
`implemented by the device drivers themselves.
`
`Device Drivers
`
`To make sure that device drivers work well with the rest of Windows Vista,
`Microsoft has defined the WDM (Windows Driver Model) that device drivers
`are expected to conform with. The WDM wasdesigned to work with both Win-
`dows 98 and NT-based Windowsbeginning with Windows 2000, allowing care-
`fully written drivers to be compatible with both systems. Thereis a development
`kit (the WindowsDriver Kit) that is designed to help driver writers produce con-
`formant drivers. Most Windowsdriversstart out by copying an appropriate sam-
`ple driver and modifying it.
`Microsoft also provides a driver verifier which validates manyof the actions
`of drivers to be sure that they conform to the WDM requirements for the structure
`and protocols for I/O requests, memory management, and so on. Theverifier
`ships with the system, and administrators can control it by running verifier.exe,
`which allows them to configure which drivers are to be checked and how exten-
`sive (i.e., expensive) the checks should be.
`Even with all the support for driver development andverification, it is still
`very difficult to write even simple drivers in Windows, so Microsoft has built a
`system of wrappers called the WDF (Windows Driver Foundation) that runs on
`top of WDMand simplifies many of the more common requirements, mostly re-
`lated to correct interaction with power managementand plug-and-play operations.
`To further simplify driver writing, as well as increase the robustness o