* Rejection of ownership, why?
* What is the important tasks of CALL mechanism in Hydra?
	- parameter checking? check if caller has sufficient capabilities
		- what to check?
			+ check type mismatch
			+ check rights
	- may amplify right if needed (for protected subsystem)
	- then build LSN list...
	
* What is walk right?
	- give a capability and a integer slot --> produce the capability indexed
	by the integer from the C-list of the object.
	- Hence LSN not only contains objects named by capabilities name in the LSN
	list alone, but also contain the CLOSURE of objects reachable along the 
	path such that every capability along the path grant the walk right.

* Why need walk right?
	- to prevent access to presentation of an object
	- for example, users do not have walk right, but procedures need walk
	right to do the job, hence when user call procedure, walk right is amplify
	
* Why Hydra needs such complex and object-based protection mechanism?
  Isn't address space protection, and privileged mode enough (like in Unix).
	- Well, since Hydra is not really an operating system, just such a 
	kernel (like Nucleus) on which different operating system can be build
	as user programs
	--> hence, user programs need to protect themselves from unauthorized access
	That why we need such protection mechanism as in Hydra

* Type object?
	- contain capabilities for procedures to operate on instance of objects.
	- responsible for:
		+ creating new object of its type
		+ performing all operation on those objects
		
* We all knows in Nucleus, a parent is like an Operating Systems of its
  children. How can you build a new operating system in Hydra?
	- create new type objects that support new kinds of resources.

* Why does Hydra reject strict hierarchy?
	+ too powerful
	+ use and possible abuse of higher level authority is unchecked
	+ not flexible

* In Nucleus, a parent can schedule its children by stop, start ...? 
  How about in Hydra?
	- through process capability. A parent (or scheduler) can contains
	capabilities all process it manage. Each capability specifies rights
	of operation on those process, including start, stop, what ever.
	
* procedure-based vs. process-based:
	- fine-grained
	- current domain (what objects it can access) of a process depends on 
	the procedure it execute currently (LSN)
	- but expensive, at procedure-based level

* Capability in a Hydra Call can be a path. What is the implication?
	- you don't need to perform a FULL search to build the LSN
	- only need to search when you need it, i.e. when you want to access some
	thing with that capability

* What is software capability?
	- If hw does not support capability, then the system needs to emulate it
	- How, every capability base operation need to trap to kernel
	- A Hydra call needs to trap to the kernel all so. Why? so that kernel
	can check if the system have sufficient capability --> slow

* What are restrictions that a caller may not want the called procedure to do?
  How to solve?
	- modify the representation of an object
	- retain the capability after return
	- duplicate info from object (or the capability it self)
	Solution: special bits in capability, and kernel enforce it

* How Hydra support protected subsystem?
	- using Type manager, i.e the type object
	- localize knowledge of representation and implementation of each type
	to its type manager.
	- user can call type manager procedure to create and manipulate objects
	but cannot directly manipulate objects.
	E.g.: say i want to modify a file. I cannot modify it directly.
	All i have is a capability to call the procedure Modify. 
	This capability specify the call privilege. 
	But the modify procedure, once called, will amplify rights, so that
	on behalf of me, it will be able to modify the file.
	
	Why this help prevent a virus. Say i accidentally run a virus.
	In unix, that virus run on my ID, hence can access any files of mine.
	But in Hydra, that virus doesn't have the capability to call the modify
	procedure in the type manager.

* What is protected subsystem anyway?
	- set of data and procedure that can only be access in a secure manner,
	i.e. through some entry point. (data cannot be access directly ...)
	- other def:
	+ a collection of program and data segments that is *encapsulated* so that
		> other executing programs cannot read or write those segments
		> cannot disrupt the intended operation of the component programs,
		> can invoke the programs (of the protected subsystem) by calling
		designated entry points.	

* Implementation of protected subsystem in hydra?
	- type manager
	- templates: checking and amplify capabilities
	
* In Nucleus, a parent process can enforce policies about resource usage
  and scheduling among its children? How can we do it in Hydra?
	- process object, process capability, which as right to stop, start, etc

* When protection checking is done?
	- through procedure call, using templates

**HYDRA**

# ABSTRACT
- object-based operation system
- new generalized notion of "resource", called object
- mechanism with objects: creation, sharing, protection of reference to object
- above mechanisms provide basis for extension in two direction:
	1) creation of new facilities
	2) creation of highly *secure* system

# Design Philosophy
- similar to nucleus, i.e, provide a collection of every basic mechanisms
  from which arbitrary set of OS facilities and policies can be conveniently,
  flexibly, efficiently, reliably constructed
- Main considerations (I pick 3 among 6)
	*Separation of mechanism and policy*
	*Flexibility*: i.e. rejection of strict hierarchical layering
	*Protection*
- Mechanisms in Hydra: intended to support the *abstracted notion of a resource*
	+ creation and representation of new *types* of resources
	+ operation defined on types of resources
	+ protected access to instances of resources within control execution domain
	+ controlled passing of control and resources between execution domains
- This paper mainly talks about:
	+ generalized notion of resource
	+ definition of execution domain (Logical Name Space: LSN)
	+ protection mechanism which control access to resource within a domain

# OVERVIEW OF THE HYDRA ENVIRONMENT
- (for detail description of objects and Types, read Levy's paper)
- every object in hydra has a data part and a C-list
- Capability: reference (i.e. addressing) + access rights to an object
	+ manipulated only by kernel
	+ hence, impossible to forge
- There primitives objects provided by kernel for creating and manipulating
  execution environment:
	+ Procedure 
	+ LNS (local name space)
	+ process
- *Procedure Object*
	+ abstraction of the intuitive notion of procedure or subroutine
	+ has some code and data
	+ has protection facilities
	+ has a capabilities list (C-list) which:
		> defines which object the procedure may refers
		> what actions it may performs on those object
	+ each procedures has two groups of capabilities:
		> caller independent: correspond to those objects that the procedure
		  always access (static), can be specified at procedure creation time
		> caller dependent: correspond to those objects that are considered
		  as parameters, can only be specified at call/execution time
		  ==> this caller dependent capabilities is specified using template
		  (3 types of template: parameter, amplification (similar to setuid),
			and creation template)
	+ in some sense, this is a static entity
- LSN: local name space
	+ execution environment of a procedure when that procedure is called
	+ unique for each invocation (hence, there can be different LSNs for
	  a single procedure, because that procedure may be called many time)
	+ disappear after the procedure terminates
	+ how LSN is created: by combining caller-independent capabilities with
	  the caller-dependent actual parameter (give at call time)
	  ==> hence LSN is list of capabilities at execution time
	!Note: when there is a call to a procedure, a new LSN will be created by
	above mechanism --> call to a procedure is costly
- Detail on how LSN is created: by using template in procedure object
	+ Template: characterize actual parameters expected by the procedure
	+ But we cannot blindly trust the parameters passed by caller
	+ Hence, checking is done here with support from template
		> This is heart of protection-checking mechanism
		> Template defines the checking to be performed:
			* The capability type field of the parameter must match with 
			  that of the template
			* The rights in the parameter capability need to be at least as
			  privileged as those required by the template
		> If caller's rights are adequate, a capability is constructed in the 
		  new LSN which references the objection. Note that rights of this 
		  capability is created by *merging* rights in both parameter and 
		  template.
		==> Implication: a callee may have greater freedom to operate on an 	
		object than the caller who passed it as a parameter, but the caller can 
		in no way obtain that freedom for himself
		(similar to setUID... in case of amplication)
		==> this potential expansion is key to obtain flexibility
- CALL mechanism (summary)
	+ a body of code tell kernel that it wish to call a procedure
	+ kernel does the checking above (using template)
	+ If ok, kernel creates new LSN
	+ The caller's LSN is replaced by the new LSN (when called procedure 
	  executes)
	+ When the procedure finish, return the the caller by way of the kernel
	+ Kernel will delete callee's LSN and restore that of caller
	(We see that LSN is like activation here)
- Process: a unit of scheduling (to make use of multiple processor)
	+ smallest entity which can be independently scheduled for execution
	+ a record of changes of environment induced by a sequence of calls
	+ stack of LNS's which represents the cumulative state of a single 
	  sequential task
	+ communication between process: message passing and semaphore

# PROTECTION MECHANISM (important)
- protection is mechanism, security is policy
- provide a set of concepts and facilities on which a highly secure system
  *may* be built, but *not* to inherently provide that security
  ==> security is depends on policy that applies those mechanisms
- rejection of hierarchical system structure, ... why?
	+ too powerful
	+ use and possible abuse of higher level authority is unchecked
	+ not flexible
- hence, try to maintain order in a nonhierarchical environment
- every thing is view as object, and a reference to that object, called     
  capability
- Each object has: (more on this in Henry's paper)
	+ unique name
	+ type part: unique name of a distinguished object which servers as 
	  the representative of such class (like class in Java)
	+ representation: contains data part and capability part
		> data part can only be manipulated, give appropriate capability
		> capability part can only be manipulated by kernel functions
		  This part contains capabilities for other objects
- The kernel examines the rights list and prevents the operation when a 
  protection failure occurs (i.e. when the requestor does not have the 
  appropriate rights).

- Question: how does Hydra provide flexibility?
	+ no hierarchical structure
	+ every thing is center around object and capability in a flat structure

- How to change execution domains (and the protection too): CALL and RETURN
- CALL mechanism: instantiate a procedure
	+ create an LSN for the procedure's execution domain
	+ transfer control to the code body
	+ what need to be done? parameter checking and may be right amplification
	+ How that can be done? by templates, each contain type attribute and rights
		> if type mismatches, checking fails.
		> templates contain regular rights use for checking, and may contain
		  *new* rights
		==> Implication: a callee may have greater freedom to operate on an 	
		object than the caller who passed it as a parameter, but the caller can 
		in no way obtain that freedom for himself
		(similar to setUID... in case of amplification)

# PATH NAMES and THE WALK RIGHT
- The walk primitive is a one-level coercion which, given a capability and a 
  nonnegative integer, produces the capability which occupies the specified 
  position in the capability part of the object named by the parameter 
  capability. The walk primitive, like all kernel primitives, is an access right 
  protected by the "kernel rights" bits in a capability.
==> ability to get a capability in the referred procedure's C-list

- Because of the walk primitive, the environment of a procedure does not consist 
  of the objects named by capabilities in its LNS alone. Rather, it is the  
  **closure** of the set of objects reachable along a path (originating in the 
  LNS) such that every capability along the path (except possibly the last)    
  grant the walk right
- Hence, all kernel primitives accept path names as parameters, and the walk
  right is checked at each step along the path
- Why path names and walk right?
	+ significant reduction in the number of capabilities needed in an LNS
	+ and more important, is that the walk right (or rather the lack of it) is 
	used to prevent access to the representation of an object
	(through what)

# SYSTEM AND SUBSYSTEM
- refer to the description of similar concepts in Salter's paper
- from the above mechanism (object, capability, protection, LSN), operating
  systems can be built:
	+ a user environment consists of a collection of resources (objects) of 
	  various types and procedures which operate on them
	+ user A's environment may not be the same with user's B environment
	  or may partially overlaps

==> This flexibility stems form:
	+ rejection of hierarchical structure
	+ nature of objects and capability, as well as protection mechanism

# EXAMPLES
- see papers

# LESSON FROM HYDRA
- many good ideas still alive today:
	+ object oriented programming
	+ the first to present its user a uniform model of the abstract object as 
	  the fundamental system resources
	+ flat system with great flexibility
	+ generalized protected control transfer call
- But why HYDRA not successful:
	1. try to be overly general, hence not optimize for common case
	   E.g: Access to Representation of object is directly restricts to type 
	   manager,as well as any user with sufficient capability. To support this, 	
	   Hydra define a large set of generic object rights (thus enable user with 
	   sufficient capability to access). But in usual cases, only type manager 
	   is allow to access the object, and it must amplify the needed rights 
	   through amplification template. 
	==> it would be simpler to restrict representation access to type managers
	    who are implicitly give all rights to their object's representation
	    (hence, get rid of amplification complexity and over head)
	2. Hydra also attempts to solve some complex protection problems with
	   special bit rights. For example, once a caller gives a capability 
	   to the callee, it may not restrict the callee not to leak any information
	   from the object referred by the capabilities.
	 	But:
		+ it is not always possible for a procedure to operate correctly without
		some special rights 
		+ it is difficult for caller to know what effect of such restriction
		on called routine
	3. Lack of hardware support in implementing capability and object, hence
	lot of overhead (for example, when domain change, need to do a lot of copy)
	Another example: call, capability checking, need to trap to the kernel
	and kernel do the work
	==> developer tends to use domain change infrequently, hence make less use
	of multiprocessor (opposed to Hydra original goals)
	4. Hydra object's are expensive
	5. Not use very much by the programmers at CMU
	(not like UNIX) --> hence slow to response to the need,