Screen Version

School of Computer Science & Engineering
University of New South Wales
 Advanced Operating Systems 
 COMP9242 2002/S2 

OS Extensibility

• Linux loadable kernel modules:
  • Run as part of the kernel ==> no protection.
  • Unsuitable for OS extension/customisation by users.
• User-level servers (Mach, Windows-NT):
  • based on message-based communication with servers,
  • performance problems ==> migrate extensions into kernel.
  • newer systems try to do better (e.g. SawMill)

Existing approaches to OS extensibility (cont'd)

• Safe kernel extensions by trusted code (e.g. SPIN[BSP$^+$95]):
  • extensions must be programmed in type-safe language (Modula-3),
  • restrictive programming model,
  • large trusted computing base,
  • unconvincing performance.
• Safety by sandboxing kernel extensions (e.g. Vino[SESS96]):
  • poor performance.

What's wrong?

• Kernel extensions create huge security problems.
  • Kernel code is inherently unrestricted.
  • Imposition of restrictions results in cost and complexity.
• User-level extensions can be secure but:
  • have potential performance problems, and
  • need to be supported by an appropriate framework.

What's needed?

User-level extensibility can be made to work if[EH01b]:

• Performance can be ensured.
  • Requires fast inter-process communication.
  • Has been demonstrated (L4, Pebble, Mungi).
• Security can be guaranteed.
  • Extensions operate within ``normal'' OS protection system.
  • Will work if OS protection is strong and flexible enough.
• A framework for extensions is provided which supports:
  • transparent invocation of extended services,
  • low overhead extension and customisation of extensions,
  • software technology to minimise complexity.