i. Does pol/mech separation require layers?
1. Well, not really layers
i. Written after Multics
1.
Multics put heavy emphasis on
protection, raised lots of problems you might want to solve
ii. Separate mechanism and policy, to allow flexible policies
iii. Classic ÒsecondÓ system – includes every good idea
invented up to this point
iv. Written at CMU, home of object-oriented modular programming
(David Parnas)
v. How does it fit into complexity?
1.
Trying to solve problems of other
systems (e.g. protection problems)
2.
High-level base so can implement
anything, nothing proscribed
i. QUESTION: what are goals?
1.
Flexible protection
2.
Extensibility
ii. Base for a collection of OSÕs – universal applicability
1.
QUESTION: is this a reasonable goal?
Does it punt too much, because only have to solve half the problem?
iii. Expand and generalize DennisÕs capability model
iv. Use structure programming / modular programming / data
hiding
v. Allow creation of OS facilities at user level
1.
Kernel does not have:
a.
Paging
b.
Scheduling
c.
File system
d.
Directories / naming
e.
Command line interface
2.
Support arbitrary co-existence of multiple implementations of
these subsystems
i. Capabilities
1.
Reference
2.
Type
3.
Rights
a.
Kernel – standard on all objects, generally applies to
abstact properties (e.g. data, capability section, capability itself)
i. E.g.
add/ remove from capability section, add / remove from data section
b.
Auxiliary – specific to the object, interpreted by the
object
ii. Objects
1.
Name == address
2.
Type
a.
Also an object, allows creating instances of that type
3.
Representation
a.
Data == sequence of bytes
b.
C-list == set of capabilities
4.
QUESTION: why?
a.
Compare to Programming semantics
b.
Allows you to create an object out of other objects
5.
NOTE: is this used?
a.
In Windows, most kernel resources are ÒobjectsÓ with an
abstract API
i. Processes,
threads, files, devices, events, mutexes, semaphores, sections, É
ii. Common
operations: query, set security
iii. Accessed
via handles (capabilities)
iv. Handles
have common rights + object specific rights
iii. Procedures:
1.
Operations on types
a.
Note: not made explicit, but procedures are methods on an
object
b.
Note: not used for normal function calls within a program,
only when protection domain changes.
2.
Has caller-dependent parameters + caller independent
parameters (globals, statics)
a.
caller-independent specified as either data or as capabilities
3.
NOTE: in FS implementation, equal time of computation &
communication overhead
iv. Templates
– used to check / set rights on a capability
1.
Used to specify rights to newly created objects –
Òcreation templatesÓ to remove full access
2.
Used to specify rights required to invoke a procedure –
Òparameter templatesÓ
3.
Used to specify ÒamplifiedÓ rights available to the procedure
– Òamplification templateÓ
a.
Specifies required rights to call
b.
Specifies new rights available to a procedure
i. Creates
new capability with additional rights
ii. E.g.
allows a procedure access to read / manipulate data or capability part of an
object
i. Local
Name Space (LNS) = current c-list
1.
explicitly stacked on procedure calls
2.
QUESTION: why?
a.
Avoids need to create a new process on invoking a procedure
b.
Avoids need for suspending + continue in common case
3.
How generated?
a.
From procedure call
ii. Process
1.
Stack of LNS
2.
QUESTION: compare to Unix, prog. sem
a.
they communicate with another process
i. e.g.
pipes, launching one via entry procedures.
iii. Procedure
calls
1.
Invoke a procedure with parameters
a.
Invocation checks templates for the procedure
i. parameter
templates check required rights
ii. amplification
templates extend some rights
b.
Creates new entry on LNS stack with:
i. Parameter
c.
ii. Amplified
c.
iii. Procedure
c.
2.
NOTE: where does trusted code execute? In your process! Key
difference from message based systems – big implications we see later
3.
NOTE: not used for every procedure call, just cross calls
(e.g. system calls, RPCs today)
4.
Local Name Space
a.
Execution context for a procedure
b.
Parameters + stored capabilities
5.
BIG NOTE: compare to invoking trusted subsystems in Unix,
Prog. Sem, Pilot
a.
Monitor vs. messages
iv. Protection
problems
1.
How can you ensure a procedure wonÕt modify an object?
a.
kernel right MDFYRTS – prevents any modification to an
object through the capability, canÕt be amplified in
2.
How can you make sure a procedure wonÕt keep a copy of a
object?
a.
ENVRTS – prevents storing capability anywhere. Is put in
LNS but canÕt be stored in any other place.
3.
How can you prevent a procedure from leaking data in a passed
parameter?
a.
Remove MDFYRTS on the c. used to invoke the procedure –
prevents procedure from writing to anything (pretty drastic).
b.
Note: does not apply to parameters
4.
How do you revoke a capability?
a.
Alias objects – like symbolic links – as a layer
of indirection
v. QUESTION:
What can you do with this?
1.
Protected subsystems: A body of objects and code that provides
a service outside kernel, supported by protection model
2.
How implement file system?
a.
Separate out disk storage into separate subsystem
i. Basic
system: use pages as backing store
b.
Directory object ==
i. Data
part == list of names
ii. Cap.
part == semaphore + capabilities to objects
c.
File object =
i. C-List
of pages
d.
Operations + aux rights:
i. CreateFile
ii. CreateDir
iii. Remove
iv. Lookup
v. Enumerate
vi. Rename
e.
Usage
i. Get
a reference to a file system object
ii. It
has a procedure to get the root directory object
iii. The
directory object has methods for enumerating names of files
iv. Directory
object has a method for getting a C to a file object, creating a file object
v. File
objects have procedures for reading/writing
i. Bibliographic
server:
1.
Rules:
a.
Nobody except research can delete his/her entries
b.
Nobody should copy his program
c.
Wants to choose who can read annotations on entries
d.
Only trusted code should manipulate underlying data
e.
Would like to limit set of users
f.
Other users should be able to add their entries and limit
access to those entries
2.
How solve this in a file system?
a.
Hard – one file for database doesnÕt provide any
protection help – no differentiation between users & ability to read
annotations
b.
How is ownership involved?
i. Hard
for author of entries to protect that data from owner of code
3.
How solve in Unix?
a.
Multiple copies of bib program, setuid to bib owner
b.
Bib contains entries + ACL of users
4.
How solve in Prog. Sem.?
a.
Multiple copies of bib. entries, one per user
b.
Each bib. entry has a c. for bib file
c.
Different c. for each function
d.
selectively give out c. for a function to different users
5.
How solve in Hydra?
a.
New object – BIBLIO, references a file for underlying
storage
b.
Operations:
i. Update
(U)
ii. Print
(P)
iii. Print
w/o annotations (PWOA)
iv. Erase
(E)
v. All
take a capability to the bibliography and capabilities to additional data (e.g.
entries)
vi. Each
operation requires a separate bit of auxiliary rights on BIBLIO
c.
How to control:
i. Control
who gets capabilities to the procedures
ii. Control
who gets a right on a capability to BIBLIO
i. Procedure
may get more rights to an object then caller; MUST trust procedure with full
rights to all parameters even if not owned by object
ii. Slow
procedure call invocate to do anything, encourages sidestepping
iii. QUESTION: what are we to think about capabilities?
a.
Very flexible
b.
Neat idea
c.
W/o HW support, must go to
kernel on every use ˆ very expensive
iv. Naming
– there is no naming, just capabilities
v. Templates
– re-incarnated in OO languages, DCOM
1.
Not use in OS, but in middle-ware for component systems
i. QUESTION:
Why?
1.
Want flexibility to many different workloads
ii. REQUIREMENT:
must allow user-level control of low-level policies
1.
scheduling
2.
page allocation
3.
control protection
iii. QUESTION:
what are other examples of mechanisms / policies in an OS?
1.
Application installation: policy is where, what privileges
needed
2.
Prefetching / buffering
3.
Routing / forwarding
4.
Page replacement
5.
Authorization
iv. QUESTION:
What is the mechanism? What is the policy?
v. QUESTION:
if want to separate, where does the policy go?
1.
elsewhere in the kernel (a kernel extension)
2.
As parameters to kernel from invoking process
3.
Code in the invoking process
4.
Code in a trusted third party process
5.
Code in an untrusted third party process
vi. QUESTION:
what is the solution in Hydra?
1.
REQUIREMENT: if in usermode, policy code may be untrusted
2.
QUESTION: Untrusted by whom?
a.
A: a procedure
3.
QUESTION: Why?
a.
Process mixes code of different privileges
i. Unlike
prog. sem, unix, everything elsee
b.
Trusted procedure may be called from a process using a
different policy
c.
Example problem: procedure acquires lock, then descheduled
– causing denial of service
vii. QUESTION:
What are the key challenges?
1.
How do you separate the policy yet provide safety &
protection
2.
How do you do this efficiently?
3.
How do you support a wide range of policies?
4.
How much trust do you put in policies? By whom (e.g. kernel,
an application, all applications, all applications + subsystems)
5.
What is the granularity of policy (all processes, a user, an
application, a process, a procedure/LNS)
viii.
NOTE: good as a design goal.
1.
e.g. donÕt have scheduler examine process run times; use
abstract priorities that someone else computes
2.
e.g. donÕt have FS examine file ownership & user ID; use
ACLs as a layer of indirection
i. User-level
facilities may contain bugs or be malevolent
ii. Need
to provide ÒfairnessÓ among competing policies
iii. Must
allow fast action for common case – canÕt invoke user-mode code for every
decision
i. Kernel
implements key mechanisms requiring privileged access to hardware
ii. Kernel
cannot support all possible policies;
iii. Kernel
implements mechanisms that represent a policy decision
1.
Use parameterized policies – user mode code can fill in parameters of general policy
a.
Long-term goals/policies enforced at user-level
iv. Call
out to process for long-term decisions
1.
e.g. page limits
2.
e.g. scheduling parameters
3.
e.g. sleep / wakeup
i. Support
Òpolicy moduleÓ or PM responsible for scheduling policy of a process (or group
of processes)
ii. PM
not called on all decisions
iii. KMPS
mediates competing policies
iv. Definitions:
1.
Process == object, PM must have capability to a process
2.
Starting a process yields control to KMPS, where it competes
for cycles with other in-core processes. Scheduling policy set by parameters
from PM
3.
Stopping a process removes it from memory, control returns to
PM- controlling PM receives a notification
v. Operations
on a process:
1.
Start – allows process to be scheduled
a.
QUESTION: Can there not be space in the queue? A: no, it is a
queue – fixed size overhead per process
2.
Stop – stops it from running, notify PM
3.
Set PCB – set policy fields in PCB
4.
Get PCB – retrieve policy fields (e.g. runtime, É)
vi. Operations
on a Policy Object (kernel object holding current values of a policy)
1.
SetPolicy – set the policy object to be used for a
process
a.
Called by PMs to add a process to a policy
2.
RcvPolicy – used by a PM to receive policy messages
about a process
a.
E.g. to receive notification that a process has stopped
vii. Parameters
1.
Priority, processor mask, time quantum (how long it runs before
being stopped), maximum current page set (working set)
a.
QUESTION: Why do you need to set these?
2.
When process blocks, notification sent to policy object
mailbox
3.
When unblocks, PM receives notification, must restart process
viii.
Multiple PMs
1.
Would like to assign fraction of resources to each PM
ix. QUESTION:
what can you do?
1.
Batch vs. timesharing?
2.
Proportional share?
3.
Real time?
a.
A: can you share real-time with best effort? YES – use
non-real time for best-effort
x. QUESTION:
What are alternate solutions?
1.
Scheduling parameters to kernel
2.
Kernel extensions (e.g. bossa)
xi. NOTE:
key idea
1.
Separate short-term policy from long-term for efficiency.
i. Background:
1.
3 level store
2.
in LNS but not in RAM
3.
non-addressable ram (current page set)
4.
addressable ram (relocation page set) (e.g. mapped in TLB)
5.
User must manage these 3 sets
a.
CPSLAOAD – loads capability + page into memory
b.
RRLOAD – adds relocation information
6.
Only CPS for top-most (current frame) LNS must be in memory
7.
Procedures indicate what pages should be in CPS / RPS –
guarantees certain set of pages are in core and addressable
8.
KMPS assumes RPS for every runnable process is in memory
ii. Policy
choices
1.
Who handles paging to ensure pages in top CPS are in core?
Kernel or PM
a.
Kernel does most
2.
How handle competition for limited pages? Kernel has mechanism
to guarantee a # of pages to each PM
3.
Page replacement policy: kernel does part of it
iii. Policy
parameters
1.
Maximum CPS size of a process – limit of number of pages
frames used by a process
2.
If process exceeds limit, it is stopped
iv. Page
replacement policy – PM not involved!!!
1.
If process doesnÕt exceed CPS limit, may handle replacement
policy itself
2.
Sharing makes it hard for a PM to know usage of a page
3.
KEY POINT Do not require PM to be correct or trustworthy
4.
Kernel uses reference history to prioritize pages to replace
5.
Limited by high cost of invoking a PM
v. COMMENTS:
1.
QUESTON: What do you think of this as p.m separation? not very
satisfying
2.
QUESTION: Why such a limited interface? Could something better
be done?
3.
QUESTION: There is an assumption that the PM knows more than
the kernel about what to do when exceeding CPS limits; is this true? When?
a.
e.g. have a low-priority PM and try to conserve pages>
i. Data
protection
1.
Information hiding easy
a.
How?
i. store
information within an object – stored capabilities in template provide
access
ii. Provide
limited routines to access data
2.
Access control lists must be built on top of subsystems
a.
How?
i. Ask
a procedure for a capability
ii. It
consults local list, and if supported, returns a capability
iii. Can
later revoke capability (see other paper)
3.
Sharing not forced, but supported
ii. Control
protection
1.
Program must interact with potentially untrusted PM
a.
PM can start/stop, schedule, but canÕt access capabilities or
data of a process
2.
Procedure can be called from any process that can get a
capability, AND PMÕs are tied to processes ˆ procedure canÕt
restrict what PMÕs it runs with
3.
Some system routines may require certain kinds of scheduling
– e.g. spooling must be timely
a.
Each PM has system-specified, unchangeable data
b.
LNS can access this to decide whether to provide service
c.
Allows policy of whether to provide service under a PM to be
made outside kernel
i. QUESTION:
How? What then? What can calling process do?
ii. QUESTION:
This seems like a flaw in the design. What do you think?
4.
Negotiate with a PM
a.
Problem: how handle critical section with locks under
different schedulers
b.
Solution: PM may restart a process blocked on a lock before it
acquires the lock
i. Kernel
allows, but returns error from lock operation
ii. Allows
breaking out of deadlock – external negotiation of what to do when lock
is contended
iii. PROBLEM:
what does this do to the programming model?
iv. QUESTION:
Does this make it safe to share semaphores / mutexes between mutually
distrusting entities?
1.
A: NO!
c.
Problem: scheduled on wrong processor according to mask
i. Each
LNS has a mask of processors it can run on
ii. PM
notified on any operating that changes mask (e.g. changning LNS)
iii. Q:
What if processor not available?
iv. A:
PM can schedule on another processor, but mask-changing operationg fails and
process is notified of failure
v. QUESTION:
what then? What is a process supposed to do?
d.
Problem: process exceeds CPS limit
i. Q:
what should be done?
ii. A:
allow it to be restarted without increasing limit, but notify it that the
requested operation (that exceeded limit) failed
iii. QUESTION:
what then?
e.
Scheduling quanta:
i. Process
can request un-interrupted running (e.g. not removed by PM) for a period with a
# of pages.
ii. If
PMÓs policy (e.g. scheduling quanta, CPS limit) supports this, succeeds &
kernel guarantees, else fails
5.
Overall: for operations where can either hang process or fail
operation, kernel supports failure and PM can choose which policy to use
(including a mix, waiting then failing)
iii. QUESTION:
why need control protection?
1.
Protection model invokes trusted code / untrusted code in same process
i. Overall
review: good goal, limited implementation
ii. What
is value of pol/mech separation?
1.
A: Incredible. Used everywhere. But not typically as a
user-mode extension mechanism
iii. How
do you draw the line between policy and mechanism? How do you factor
performance into the design?
1.
Need some sense of workloads to estimate frequency of
event, cost of decision, value of decision
iv. Did
they achieve it? Do their mechanisms leave enough policy out?
v. What
do they give up in this model?
vi. What
are the assumptions?
vii. Is
negotiation a good idea? Makes every programmer have to assume all operations
can fail, take recovery action.
viii.
What other examples?
1.
Security policy callouts in Linux Security Modules
2.
Mach paging
3.
Read-ahead flags on Windows CreateFile – indicate
access patterns. Allows parameterized policy
4.
Bossa language for scheduling
5.
Prefetching policy – from aspect oriented
programming
6.
Extensible systems – SPIN, Vino
7.
All the configuration flags in applications
ix. Things
to think about:
1.
What are the policy decisions you want to make?
a.
E.g. when do you block / when do you return error
2.
How common are they?
3.
How similar are low-level actions of different
decisions