its about part of windows

1. The Windows Operating
System

2. Goals
• Hardware-portable
– Used to support MIPS, PowerPC and Alpha
– Currently supports x86, ia64, and amd64
– Multiple vendors build hardware
• Software-portable
– POSIX, OS2, and Win32 subsystems
• OS2 is dead
• POSIX is still supported—separate product
• Lots of Win32 software out there in the world

3. Goals
• High performance
– Anticipated PC speeds approaching
minicomputers and mainframes
– Async IO model is standard
– Support for large physical memories
– SMP was an early design goal
– Designed to support multi-threaded processes
– Kernel has to be reentrant

4. Process Model
• Threads and processes are distinct
• Process:
– Address space
– Handle table (Handles => file descriptors)
– Process default security token
• Thread:
– Execution Context
– Optional thread-specific security token

5. Tokens
• “Who you are”—list of identities
– Each identity is a SID
• Also contains Privileges
– Shutdown, Load drivers, Backup, Debug…
• Can be passed through LPC ports and
named pipe requests
– Server side can use this to selectively
impersonate the client.

6. Object Manager
• Uniform interface to kernel mode objects.
• Handles are 32bit opaque integers
• Per-process handle table maps handles to
objects and permissions on the objects
• Implements refcount GC
– Pointer count—total number of references
– Handle count—number of open handles

7. Object Manager
• Implements an object namespace
– Win32 objects are under BaseNamedObjects
– Devices under Device
• This includes filesystems
– Drive letters are symbolic links
• ??C: => the appropriate filesystem device
• Some things have other names
– Processes and threads are opened by
specifying a CID: (Process.Thread)

8. Standard operations on handles
• CloseHandle()
• DuplicateHandle()
– Takes source and destination process
– Very useful for servers
• WaitForSingleObject(),
WaitForMultipleObjects()
– Wait for something to happen
– Can wait on up to 64 handles at once

9. Security Descriptors
• Each object has a Security Descriptor
– Owner—special SID, CREATOR_OWNER
– Group—special SID, CREATOR_GROUP
– DACL
• Discretionary Access Control List
• List of SIDs and granted or denied access rights
– SACL
• System Access Control List
• List of SIDs and access rights to be audited

10. Access Rights
typedef struct _ACCESS_MASK {
USHORT SpecificRights;
UCHAR StandardRights;
UCHAR AccessSystemAcl : 1;
UCHAR Reserved : 3;
UCHAR GenericAll : 1;
UCHAR GenericExecute : 1;
UCHAR GenericWrite : 1;
UCHAR GenericRead : 1;
} ACCESS_MASK;

11. Security Use
• Objects are referred to via handles
• Security checks occur when an object is
opened
– Open requests contain a mask of requested
access rights
– If granted to the token by the DACL, the
handle contains those access rights
• Access rights are checked on use
– Just a bit test—very fast

12. Object Open
evt = OpenEvent(EVENT_MODIFY_STATE,
FALSE, "SomeName");
– Finds the event object by name
– Walks the DACL, looking for token SIDs
– Keeps looking until all permissions are
granted
– If access is granted, inserts a handle to the
object into the process’s handle table, with
EVENT_MODIFY_STATE access

13. Object Use
SetEvent(evt);
– SetEvent() requires EVENT_MODIFY_STATE
access, and an event object.
– The kernel looks up the handle in the
process’s handle table.
– Checks to make sure that it maps to an event
object, and that the granted access bits
contain the EVENT_MODIFY_STATE bit.
– If all is good, the event is set.

14. Object Use
WaitForSingleObject(evt)
– WaitForSingleObject() requires a
synchronization object (like an event) and
SYNCHRONIZE access.
– evt maps to an event object
– SYNCHRONIZE access was not requested
when the handle was inserted.
– Even if the DACL permits it, the wait fails.

15. Types of Objects
• Events
– State is set or clear.
– Can clear when a wait completes (auto-reset)
• Mutexes
– Can be acquired by a single thread at a time.
– Automatically release when owner exits.
• Semaphores
– Maintain a count
– Waits decrement the count

16. More objects
• Threads, Processes, Timers—like events
• Registry Keys
– Manipulate data in the registry—centralized
store of system configuration info.
• LPC Ports
– Fast local RPC
– Security tokens can transfer over LPC calls
• Files

17. Files & IO
• File objects maintain a current offset, and
a pointer to the underlying stream.
• Default internal model is asynchronous
– Synchronous IO just waits for the IO to
complete
– Async IO can set an event, or run a callback
in the thread which queued the IO, or post a
message to an IO completion port.
• Each request is an IRP

18. IRPs
• Maintain state of IO requests, independent
of the thread working on the IO
• IRPs are handed off through the device
stack to their destinations
– Threads process IRPs
– Initiating thread processes the IRP until a
device returns STATUS_PENDING
– Subsequent processing can be done in kernel
worker threads

19. Interrupts
IRQL—Interrupt Request Level:
0 => PASSIVE_LEVEL
Processor is running threads
All usermode code is at IRQL 0
1 => APC_LEVEL; threads, APCs disabled
2 => DISPATCH_LEVEL
• Running as the processor: can’t stop!
• Can’t take a page fault
• Only locks available are KSPIN_LOCKs

20. Interupts
3-26 => Device Interrupt Service Routines
• Device interrupts are mapped to an IRQL and an
interrupt service routine; ISR is called at that IRQL
27 => PROFILE_LEVEL—profiling
28 => CLOCK2_LEVEL—clock interrupt
29 => IPI_LEVEL—interprocessor interrupt
• Requests another processor to do something
30 => POWER_LEVEL—power failure
31 => HIGH_LEVEL—interrupts disabled

21. Interrupts
• Hardware signals an interrupt
• Interrupt’s ISR runs at device IRQL
– Has to be fast; get off the processor and allow
other ISRs to run
– Typically queues a DPC, acknowledges the
interrupt, and returns
• DPC—Delayed Procedure Call
– Further processing at DISPATCH_LEVEL
– Queues work to kernel worker threads

22. IO Completion
• Driver calls IO Manager to complete the
IRP
• IO Manager queues a kernel mode APC to
the initiating thread
• APC: Asynchronous Procedure Call
– Kernel mode APC preempts thread execution
– Writes data back to user mode in the context
of the thread which initiated the IO
– Signals completion of the IO

23. IO Cache
• Classic: block cache
– Page mappings translate directly to blocks on
the underlying partition.
• Windows: stream cache
– Page mappings are offsets within a stream.
– IO Cache Manager uses the same mappings.
– All cache management (trimming) is
centralized in the memory manager
– All modifications show up in mapped views.

24. Virtual Memory
• Sections—another object type
– Can be created to map a file
– Can also be created off the pagefile
– Optionally named, for shared memory
• Reservation
– Range of VA which will not be handed out for
some other purpose
• Committed
– VA which actually maps to something

25. Aside: CreateProcess
• Just a user mode Win32 API
{
NtCreateFile(&file, szImage);
NtCreateSection(&sec, file);
NtCreateProcess(&proc, sec);
NtCreateThread(&thrd, proc);
}
WaitForSingleObject(proc);

26. Virtual Memory
• Memory Manager maintains processor-
specific page table entry mappings.
– Some parts of the address space are shared
between processes—for instance, the kernel’s
address space and the per-session space.
• On a pagefault, mm reads in the data
• Pages can be mapped without the
appropriate access… what to do?

27. Signals
• With threads, signals don’t work very well.
• Some software designs expect to touch
inaccessible memory.
– Large structured files
– Concurrent garbage collection
– SLists
• Single global handler has to somehow
know about all possible situations.

28. Structured Exception Handling
• Exceptions unwind the stack
– Almost like C++!
– C++ matches against a type hierarchy
– SEH calls exception filter code—filters are
Turing-complete.
• Two ways to deal with exceptions:
– try/finally
– try/except

29. try/finally
res = AllocateSomeResource();
try {
SomeOperation(res);
} finally {
if (AbnormalTermination()) {
FreeSomeResource(res);
}
}
return res;

30. try/except
try {
SomeOperationWhichMayAV();
} except (Filter(
GetExceptionCode(),
GetExceptionInformation())) {
DoSomethingElse();
}

31. try/except
• GetExceptionCode()
– A code indicating the cause of the exception
• GetExceptionInformation()
– Additional code-specific info
– The full processor context
• Filter decides what to do
– EXCEPTION_EXECUTE_HANDLER
– EXCEPTION_CONTINUE_SEARCH
– EXCEPTION_CONTINUE_EXECUTION

32. Structured Exception Handling
• On x86, TEB points to stack of
EXCEPTION_REGISTRATION_RECORD
– auto structs, pointing to handler code
– pushed by function prolog
– popped by function epilog
• On exception, RtlDispatchException()
walks the list.
– Runs the filters to figure out what to do
– Calls handler functions

33. Structured Exception Handling
• On x86, there’s some overhead with
pushing and popping the registration
record
• On ia64, there is no overhead
– Stack traces are reliable
– It’s always possible to look up the handler
• Exception handling is very slow
– Especially on ia64
• Used only for truly exceptional conditions

34. Structured Exception Handling
• Used in kernel mode too!
– Most user mode access will just work
– Still need to validate address ranges & data
– Works great for SMP when another thread
might be in the middle of modifying the
address space
– Expected read exceptions are returned as
status codes from system calls
– Expected writes are returned as SUCCESS
– Unexpected => buggy kernel => blue screen

35. Top-level Exception Filter
• Top frame on each thread defines a
catchall exception filter
• Top-level exception filter:
– Notifies the debugger (if being debugged)
– Launches a just-in-time debugger (if set up)
– Loads faultrep.dll to report the failure

36. Faultrep.dll
• faultrep.dll offers to report the failure back
to Microsoft
• We analyze the failures
– A significant number are recognized instantly;
we can tell the user what happened and how
to fix it.
– The others go through the standard triage
process; developers analyze the dumps and
figure out what happened.

37. OCA
• 67 million machines running XP
• Tens of thousands of drivers
• Over 100 drivers on any given machine
• One bug in one driver => Crash
• A significant number of crashes come
from third-party drivers (some of which
ship on the CD)
• Lots of different problems, though

38. Driver Verifier
• Controlled by verifier.exe
• Special-pool’s allocations
– Detects allocation overruns & use after free
• Validates some behaviors
– IRQL—touching paged memory?
– DMA buffers
• Can inject failures—useful for testing
behavior under sub-optimal conditions

39. Stress
• Every night, a couple hundred machines
run stress on the latest build
• Stress exercises filesystems, memory,
GUI, scheduler, &c, trying to uncover low-
memory handling problems and race
conditions
• Every morning, the stress test team
triages failed machines
• Developers debug the failures

40. Questions?