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.

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.

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.

Next: Mungi Component Model Up: 12-mungi Previous: Mandatory Access Control in

Gernot Heiser 2002-10-24