Chapter11 Windows8

Case Study 2: Windows 8
Chapter 11
Tanenbaum & Bos, Modern Operating Systems: 4th ed., Global Edition (c) 2015 Pearson Education Limited. All rights reserved.
History of Windows through
Windows 8.1
Figure 11-1. Major releases in the history of Microsoft

operating systems for desktop PCs.
2000s: NT-based Windows (1)
Figure 11-2. DEC Operating Systems developed by Dave Cutler.
2000s: NT-based Windows (2)
Figure 11-3. The Win32 API allows programs to run

on almost all versions of Windows.
Programming Windows (1)
Figure 11-4. The programming layers in Modern Windows

Programming Windows (2)
Figure 11-5. The components used to build NT subsystems.

The Native NT Application
Programming Interface (1)
Figure 11-6. Common categories of

kernel-mode object types.
The Native NT Application
Programming Interface (2)
Figure 11-7. Examples of native NT API calls that use handles

to manipulate objects across process boundaries.
The Win32 Application
Programming Interface
Figure 11-8. Examples of Win32 API calls and the

native NT API calls that they wrap.
The Windows Registry (1)
Figure 11-9. The registry hives in Windows. HKLM is a

short-hand for HKEY LOCAL MACHINE.
The Windows Registry (2)
Figure 11-10. Some of the Win32 API calls

for using the registry
Operating System Structure
Figure 11-11. Windows kernel-mode organization.
The Hardware Abstraction Layer
Figure 11-12. Some of the hardware

functions the HAL manages
Dispatcher Objects
Figure 11-13. dispatcher_header data structure embedded in

many executive objects (dispatcher objects).
The Device Drivers (1)
Figure 11-14. Simplified depiction of device stacks for two NTFS file volumes.
The I/O request packet is passed from down the stack. The appropriate
routines from the associated drivers are called at each level in the stack. The
device stacks themselves consist of device objects allocated specifically to
each stack.
The Device Drivers (2)
Figure 11-14. Simplified depiction of device stacks for two NTFS file volumes.
The I/O request packet is passed from down the stack. The appropriate
routines from the associated drivers are called at each level in the stack. The
device stacks themselves consist of device objects allocated specifically to
each stack.
Implementation
of the Object
Manager
Figure 11-15. The structure of an

executive object
managed by the object manager
Handles (1)
Figure 11-16. Handle table data structures for a minimal

table using a single page for up to 512 handles.
Handles (2)
Figure 11-17. Handle table data structures for a maximal

table of up to 16 million handles.
The Object Name Space (1)
Figure 11-18. The object procedures supplied when

specifying a new object type.
Figure 11-19. Some typical directories in the object name space.
Use of parse procedure:
1.Executive component passes Unicode pathname for
namespace
2.Object manager searches through directories and
symbolic links
3.Object manager calls the Parse procedure for object
type
4.I/O manager creates IRP, allocate file object, send
request to stack of I/O devices
5.IRP passed down the I/O stack until it reaches device
object representing the file system instance
6.Device objects encountered as the IRP heads toward
the file system represent file system filter drivers
7.File system device object has a link to file system
driver object
8.NTFS fills in file object and returns it to I/O manager,
which returns back up through all devices on the stack
9.Object manager is finished with its namespace lookup
10.Final step is to return back to the user-mode caller
Figure 11-20. I/O and object manager steps for

creating/opening a file and getting back a file handle.
Figure 11-21. Some common executive object types

managed by the object manager.
Figure 11-21. Some common executive object types

managed by the object manager.
Jobs, Processes, Threads, Fibers
Figure 11-22. The relationship between jobs, processes, threads and

fibers. Jobs and fibers are optional; not all processes are in jobs or
contain fibers.
Thread Pools and User-Mode
Scheduling (1)
Key elements of UMS implementation:

1.User-mode switching
2.Re-entering the user-mode scheduler
3.System call completion
Thread Pools and User-Mode
Scheduling (2)
Figure 11-23. Basic concepts used for CPU

and resource management.
Job, Process, Thread, and Fiber
Management API Calls (1)
Differences from UNIX:
1.Actual search path for finding program to execute
buried in library code for Win32, but managed more
explicitly in UNIX.
2.Current working directory is a kernel-mode concept in
UNIX but a user-mode string in Windows.
3.UNIX parses command line and passes array of
parameters, while Win32 leaves argument parsing up to
individual program.
4.Inheritance of file descriptors in UNIX a property the
handle. In Windows is also property of handle to process
creation.
5.New processes directly passed information about primary
window in Win32. Passed as parameters to GUI
applications in UNIX.
6.Windows does not have SETUID bit as property of the
executable, but one process can create a process that runs
as a different user (with proper token)
7.Process and thread handle returned from Windows
can be used at any time to modify new process/thread in
many ways.
UNIX only makes modifications to new process between
fork and exec calls, and only in limited ways
Implementation of Processes
and Threads (1)
Figure 11-24. Some of the Win32 calls for managing

processes, threads, and fibers.
Implementation of Processes
and Threads (2)
Figure 11-24. Some of the Win32 calls for managing

processes, threads, and fibers.
Scheduling (1)
Conditions that invoke scheduling
1.A running thread blocks on a semaphore, mutex,
event, I/O, etc.
2.Thread signals an object (e.g., does an up on a
semaphore).
3.The quantum expires.
4.An I/O operation completes.
5.A timed wait expires.
Scheduling (2)
Figure 11-25. Mapping of Win32 priorities to

Windows priorities.
Scheduling (3)
Figure 11-26. Windows supports 32 priorities for threads.

Scheduling (4)
Figure 11-27. An example of priority inversion.

Memory Management
Fundamental Concepts
Figure 11-28. Virtual address space layout for three user processes
on the x86. The white areas are private per process. The shaded
areas are shared among all processes.
Memory-Management System Calls
Figure 11-29. The principal Win32 API functions for

managing virtual memory in Windows.
Implementation of Memory
Management
Figure 11-30. Mapped regions with their shadow pages on disk.

The lib.dll file is mapped into two address spaces at the same time.
Page Fault Handling (1)
Figure 11-31. A page table entry (PTE) for a mapped page on

the Intel x86 and AMD x64 architectures.
Page Fault Handling (2)
Categories of page faults:
1.The page referenced is not committed.
2.Attempted access to a page in violation of the
permissions.
3.A shared copy-on-write page was about to be
modified.
4.The stack needs to grow.
5.The page referenced is committed but not currently
mapped in.
The Page Replacement Algorithm (1)
Figure 11-32. The Windows self-map entries are used to map

the physical pages of the page tables and page directory into
kernel virtual addresses (shown for 32-bit PTEs).
The Page Replacement Algorithm (2)
Three levels of activity by the working-set

manager:
1.Lots of memory available
2.Memory getting tight
3.Memory is tight
Physical Memory Management (1)
Figure 11-33. Some of the major fields in the page frame

database for a valid page.
Physical Memory Management (2)
Figure 11-34. The various page lists and the

transitions between them.
Input/Output API Calls
Figure 11-35. Native NT API calls for performing I/O.

Device Drivers
Figure 11-36. A single level in a device stack.
I/O Request Packets
Figure 11-37. The major fields of an I/O Request Packet.
Device
Stacks
Figure 11-38. Windows

allows drivers to be
stacked to work with a
specific instance of a
device. The stacking is
represented by device
objects.
Implementation of the NT File System (1)
Figure 11-39. The NTFS master file table.

Implementation of the NT File System (2)
Figure 11-40. The attributes used in MFT records.
Storage Allocation (1)
Figure 11-41. An MFT record for a three-run, nine-block stream.
Figure 11-42. A file that requires three MFT

records to store all its runs.
Figure 11-43. The MFT record for a small directory.
File Compression
Figure 11-44. (a) An example of a 48-block file being compressed to 32

blocks. (b) The MFT record for the
file after compression.
Security in Windows 8
Security properties inherited from NT:
1.Secure login with antispoofing measures.
2.Discretionary access controls.
3.Privileged access controls.
4.Address space protection per process.
5.New pages must be zeroed before being
mapped in.
6.Security auditing.
Fundamental Security Concepts
Figure 11-45. Structure of an access token.
Security API Calls (1)
Figure 11-46. An example

security descriptor for a file.
Security API Calls (2)
Figure 11-47. The principal Win32 API functions for security.
Security Mitigations
Figure 11-48. Some of the principal

security mitigations in Windows.
End
Chapter 11

Chapter11 Windows8

Uploaded by

Document Informationclick to expand document information

Copyright:

Available Formats

Chapter11 Windows8

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter11 Windows8

Uploaded by

Copyright:

Available Formats

Case Study 2: Windows 8

Figure 11-1. Major releases in the history of Microsoft

Figure 11-2. DEC Operating Systems developed by Dave Cutler.

Figure 11-3. The Win32 API allows programs to run

Figure 11-4. The programming layers in Modern Windows

Figure 11-5. The components used to build NT subsystems.

Figure 11-6. Common categories of

Figure 11-7. Examples of native NT API calls that use handles

Figure 11-8. Examples of Win32 API calls and the

Figure 11-9. The registry hives in Windows. HKLM is a

Figure 11-10. Some of the Win32 API calls

Figure 11-11. Windows kernel-mode organization.

Figure 11-12. Some of the hardware

Figure 11-13. dispatcher_header data structure embedded in

Figure 11-15. The structure of an

Figure 11-16. Handle table data structures for a minimal

Figure 11-17. Handle table data structures for a maximal

Figure 11-18. The object procedures supplied when

Figure 11-19. Some typical directories in the object name space.

Figure 11-20. I/O and object manager steps for

Figure 11-21. Some common executive object types

Figure 11-21. Some common executive object types

Figure 11-22. The relationship between jobs, processes, threads and

Key elements of UMS implementation:

Figure 11-23. Basic concepts used for CPU

Figure 11-24. Some of the Win32 calls for managing

Figure 11-24. Some of the Win32 calls for managing

Figure 11-25. Mapping of Win32 priorities to

Figure 11-26. Windows supports 32 priorities for threads.

Figure 11-27. An example of priority inversion.

Figure 11-29. The principal Win32 API functions for

Figure 11-30. Mapped regions with their shadow pages on disk.

Figure 11-31. A page table entry (PTE) for a mapped page on

Figure 11-32. The Windows self-map entries are used to map

Three levels of activity by the working-set

Figure 11-33. Some of the major fields in the page frame

Figure 11-34. The various page lists and the

Figure 11-35. Native NT API calls for performing I/O.

Figure 11-36. A single level in a device stack.

Figure 11-37. The major fields of an I/O Request Packet.

Figure 11-38. Windows

Figure 11-39. The NTFS master file table.

Figure 11-40. The attributes used in MFT records.

Figure 11-41. An MFT record for a three-run, nine-block stream.

Figure 11-42. A file that requires three MFT

Figure 11-43. The MFT record for a small directory.

Figure 11-44. (a) An example of a 48-block file being compressed to 32

Figure 11-45. Structure of an access token.

Figure 11-46. An example

Figure 11-47. The principal Win32 API functions for security.

Figure 11-48. Some of the principal

You might also like