Safety of OS Part I: SPIN Dealing with Disaster:Vino

1
Safety of OS Part ISPINDealing with
DisasterVino

• cs530 2001 Fall
• Instructor Joonwon Lee

2
SPIN Introduction

• Extensibility
• determined by interfaces to services and
  resources
• what for? performance and functionality
• Safety
• protect the kernel from new extensions
• Performance
• low overhead for communications between
  extensions and the kernel
• Extensible systems have tensions between them
• solve it using a language

3
Language Features Modula-3

• Encapsulation separation of interface and
  implementation modules
• restrict visibility from outside the module
• Strong typing
• prevents software from accessing arbitrary memory
• a pointer can refer only to the object of right
  type
• runtime feature
• Storage Management
• returned memory objects cannot be reused by other
  modules

4
SPIN Protection Model - Capability

• Capability
• pointer is used as a capability
• type checking enhances safety
• Protection domains
• set of accessible names
• name space is managed at language level
• a domain has a set of safe objects
• objects verified by the compiler or by the kernel
• symbols exported by each object are exported from
  the domain
• dynamic linking is controlled through names

5
Extension Model

• Controls communications between extensions and
  the kernel Extensions may
• passively monitor the kernel
• provide hints to the kernel
• replace the kernel module
• Event Handler
• event names are controlled (language feature
  again)
• extensions may replace the handler
• each event is associated with a primary handler
  which controls the privilege of extensions

6
Extension Examples

• Defines events for functions to be
  extended/replaced
• system event
• user request
• Memory Managements
• request for memory allocations, address
  translations, sharing,
• page faults, ..
• Thread management
• scheduler activations
• blocking for user level thread
• All these extensions are under safe control of
  the interfaces

7
VINO Approaches

• extension mechanisms
• Scout
• several versions of specialized kernels are
  prepared
• administrator chooses a particular kernel for a
  particular application environment
• this is not an extension
• static
• SPIN, VINO
• applications download code into the kernel
• dynamic customization
• can be applied to microkernel and monolithic
  kernel

8
Graft

• graft
• user code inserted into the kernel
• can corrupt the kernel
• buggy graft
• malicious graft
• needed kernel protection from graft
• memory protection
• read/write inappropriate data
• execution of bad instructions
• resource protection
• monopolizing may degrade system performance and
  jeopardize the acceptable performance of
  applications
• focus of this paper

9
Graft (2)

• graft model
• a thread inside the kernel
• stack and heap of its own
• VM protection is expensive even it is not
  impossible
• SFI is used
• kernel logs graft actions
• to undo if the grafts misbehave
• why a graft is dangerous
• it runs in the kernel mode
• can corrupt any part of the system
• most kernel interfaces are open to it
• most procedure interfaces
• unlike well-defined syscall interface
• we can restrict the interfaces open to a graft
• tradeoff between safety and graft functionality
• system relies on a graft

10
Graft Misbehaviors

• illegal data access
• VM mechanism cannot be used
• in kernel mode, a graft can bypass address
  translation
• use of safe language or SFI
• need to verify that a graft is made by such a
  tool
• sometimes, a graft needs to access only to meta
  data not the actual data
• need to differentiate protection for meta data
  from the one for actual data
• resource hoarding
• resources of interest
• CPU, memory, network, synchronization
• treat a graft like a user level process
• preempt a graft for a sharable resource
• terminate a graft for an exclusive resource

11
Graft Misbehaviors(2)

• access to incorrect interface
• to change a global policy
• scheduling, memory allocation
• to shutdown
• to access private data
• antisocial behavior
• a graft does not do what it has agreed to do
• when a (scheduling) graft affects only the
  members of the group, it is acceptable
• a graft should not affect the processes in other
  group
• covert denial of service
• when a kernel asks a graft of a decision, the
  graft may never returns --- the kernel cannot
  make any progress
• timeout mechanism is needed

12
Restrictions on Grafts

• grafts must be preemptible
• grafts cannot hold kernel locks or limited kernel
  resource for excessive periods of time
• grafts cannot access memory to which they have
  not been granted permission
• grafts cannot call functions that alter or return
  data that the graft is not allowed to access
• grafts cannot replace restricted kernel functions

13
Restrictions on Grafts (2)

• the kernel must not execute grafts that are not
  known to be safe
• grafts must not call functions to which they have
  not been granted access
• malicious grafts can only affect applications
  that have agreed to use them
• the kernel must be able to make progress even
  with a faulty graft in its path

14
The Vino Grafting Architecture

• Vino overview
• a collection objects
• an inner kernel
• a set of resources
• an extension is a transaction
• can be undone
• modes of extension
• replacing a method on an object
• overrides default policy
• handler for a given event
• new kernel level services

15
Kernel Transaction Support

• when a graft is inserted, a wrapper is interposed
• it begins a transaction and calls the graft
• when the graft returns to the wrapper without any
  problem, the wrapper commits the transaction
• redo log is not necessary
• when a transaction must be aborted,
• transaction manager invokes undo operations
• using the undo call stack
• returns error to the graft stub
• invoke default function
• nest transactions
• when a transaction aborts, it just returns abort
  state to the parent transaction
• when it commits, the undo call stack is merged
  with parents

16
Aborting a Graft

• time-constrained resources
• when a graft is holding it for too long, other
  processes cannot make progress
• lock
• for every lockable resource, a timeout value is
  assigned
• the value depends on the type resource
• when a thread blocks on such a resource, it
  schedules a time-out
• when it goes off, the lock holding thread is
  aborted
• quantity-constrained resources
• a graft should not use it too much
• memory, buffer, ....
• each graft thread is given a limit for each
  resource
• these limits are assigned when a graft is
  installed
• ticket delegation in lottery scheduling

17
Graft Code Safety

• a list of graft-callable functions is defined by
  the OS developer
• a graft is checked if it makes other calls
• indirect function call is checked at run time
• by inspecting if it is on the list
• hashing is used for searching the list
• graft-callable functions performs the same level
  checking that syscalls do
• how to verify that a graft comes through SFI
  tool?
• digital signature

18
Installing a graft

• a method graft
• kernel has predefined graft points (ob, method)
• a user process invokes a syscall for installing a
  graft
• install_graft(function, graft_point)
• kernel finds the address of the function to be
  replaced
• get a space for the graft
• assign the address of graft to the calling
  instruction
• if instruction is not modifiable, use a table for
  indirect function call

19

• an event graft
• mechanism
• kernel defines only the event types to be
  processed
• user defines new graft points to the kernel
• using syscall
• also user installs a graft at the graft point
• difference from the method graft
• method applies only to an object while an event
  can be applied to the whole kernel
• a new graft can be added without replacing old
  one

20
The Cost of Graft Protection

• base path - w/o any indirections needed for graft
• VINO path - with indirections but w/o actual use
  of graft
• null path - using a minimal size graft
• unsafe path - full graft with transaction but w/o
  SFI checks
• safe path -everything
• abort path - when a safe path raises an abort

21
Workload Taxonomy

• block box read ahead
• complex graft function
• prioritization graft page eviction
• find a process or a memory frame
• stream graft encryption/decryption
• handles stream data

22
Example Read-Ahead

• backgrounds
• most file access is sequential
• asynchronously prefetches data to buffer cache
• some applications, however, want different policy
• application-controlled prefetching
• unable to exploit data layout(kernel information)
• kernel cannot distinguish prefetching from normal
  reading
• treat them at the same priority
• workload
• fetch a data form a DB random access but
  applications have hints
• application places (location, size) in the shared
  buffer for prefetching
• compute on it

23
Cost of Read-Ahead

• costs
• base path 0.5
• VINO path (w/ indirection) 1.5
• null path 67.0
• trans begin 36.0
• null graft 2.0
• trans commit 28.0
• unsafe path 104.0
• lock 33.0
• graft 2.0
• L1 cache miss 2.0
• safe path 107.0
• SFI checks 3.0
• comparison
• summation of 1K integers 137.0

24
Example 2 Page Eviction

• requirements of external pager
• must be fast since it affects the whole
  performance
• the validity of the return value must be
  detectable
• a graft shouldnt allocate more memory for the
  applications than without the graft
• mechanism
• when needed, a global pager selects a victim
• if the owner of the victim has its own pager the
  kernel passes the victim number and the list of
  pages owned
• the external pager decides a new victim
• the kernel verifies the validity of the new
  victim
• if invalid (or inappropriate), use the formerly
  chosen victim
• cost 316 (page fault 18000)

25
Example 3 External Scheduler

• motivation
• when multiple processes cooperate, user level
  applications know best about which process should
  be given more CPU
• mechanism
• schedule-delegate function
• each kernel thread has it
• selects another thread to be scheduled
• client server example
• a graft scans 64 entries list
• cost
• 154
• difficult to measure the benefit
• compare these numbers with scheduler activations

26
Experience

• C problem
• no garbage collection even though it is
  object-oriented
• SFI overhead
• compiler level protection looks nice
• the use of constrained language is still
  controversial
• tradeoffs
• restricting graft interface
• user demands vary as time goes by
• OS developer cannot predict all these demands
• overhead for checking malices
• the more kernel opens its interfaces to grafts
  the more safety checking is needed
• right decision is very difficult to obtain

27
Experience (2)

• grain size of extension
• each extension should be encapsulated
• to be replaced
• to be protected
• fine grain extension is more customizable
• at the cost of more function calls
• abstraction of graft
• thread
• easy to protect kernel from it
• more indirect function calls
• function
• naturally what a graft is supposed to be
• more difficult to protect the kernel