[cgl_discussion] Invitation for Participation on the Hardened Drivers Project

[Rhoads, Rob]

Project Invitation:
------------------
This is an invitation to all engineers involved with OSDL 
Carrier Grade Linux, that have an interest in device drivers 
and hardened drivers in particular, to participate in the Open
Source Hardened Driver Project hosted on SourceForge. 

The immediate goal for CGL members is to formally review the current
Harden Device Driver draft specification. I would like to do this in
the open and invite you to participate via the Hardened Driver
mailing list on SourceForge. I think it is critical for the success
of this project to seek input from Linux kernel developer community
and I plan on publicizing this project on the Linux Kernel mailing 
list in the immediate future. Your input and feedback would be 
greatly appreciated on this project.

If you are interested please sign up on the Hardened Driver mailing
list (see links below) and grab a copy of the Hardened Driver spec 
on the web page. I will be sending out, on that mailing list, more 
info and a proposed review schedule for the document.

On the project page you will also find links to related projects and
source code for the kernel header files, defined within the 
specification and a sample driver which use those APIs.

On this bottom of this e-mail you will also find the Hardened Driver
description/overview that appears in the CGL Arch Spec.


Project Links:
-------------
o The Driver Hardening website:  
  http://hardeneddrivers.sourceforge.net

o Hardened Drivers (Draft) Specification: 
  http://hardeneddrivers.sourceforge.net/downloads/DDH-Spec-0.5h.pdf

o The SourceForge project related info:
  http://sourceforge.net/projects/hardeneddrivers

o Hardened Drivers Mailing List Info (subscribe here):
  http://lists.sourceforge.net/mailman/listinfo/hardeneddrivers-discuss


Hardened Driver Project Overview:
--------------------------------
Device drivers have traditionally been a significant source of
software faults. For this reason, they are of key concern in 
improving the availability and stability of the operating system.
Their higher rate of faults can be explained in part by the fact 
that drivers run in kernel space, but because they are only used 
with specific hardware, they can never receive the same level of 
field-testing as the kernel itself. A critical element in creating
an OSDL CGL environment is to reduce the likelihood of faults 
in key drivers, a methodology called driver hardening. 

A device driver is typically implemented with emphasis on the 
proper operation of the hardware. Attention to how it will 
function in the event of hardware faults is often minimal. 
Hardened drivers, on the other hand, are designed with the 
assumption that the underlying hardware that they control will
fail. They need to respond to such failures by handling faults
gracefully, limiting the impact on the overall system. 
Hardened device drivers must continue to operate when the 
hardware has failed, or is not present, and must not allow
the propagation of corrupt data from a failed device to other 
components of the system.

Hardened device drivers must also be active participants in 
the recovery of detected faults, by locally recovering them 
or by reporting them to higher-level system management software 
that subsequently instructs the driver to take a specific action.

The goal of a hardened driver in OSDL CGL is to provide an 
environment in which hardware and software failures are 
transparent to the applications using their services. The 
way to effectively achieve this goal is for the driver 
developer to analyze a driver's software design and implement 
appropriate changes to improve stability, reliability and 
availability, and to provide instrumentation for management 
middleware.

Improving driver stability and reliability includes such measures
as ensuring that all wait loops are limited with a timeout, 
validating input and output data and structuring the driver to
anticipate hardware errors. Improving availability includes adding 
support for device hot swapping and validating the driver with fault 
injection. Instrumentation for management middleware includes 
functions such as reporting of statistical indicators and logging of 
pertinent events to enable postmortem analysis in the event of a 
failure.

To minimize instability contributed by device drivers and to further
enhance the availability of OSDL CGL based systems, OSDL CGL defines 
requirements for a device driver to be considered a hardened driver. 
OSDL CGL defines different device driver hardening traits and the 
required programming interfaces to support these hardening traits.

A driver can support four hardening traits:
·	Hardening with code robustness
·	Hardening with event logging
·	Hardening with diagnostics
·	Hardening with resource monitoring and statistics

Device drivers for network interface cards, physical storage, and
logical storage should be hardened for use with OSDL CGL

+=+=+
Rob Rhoads                     mailto:rob.rhoads at intel.com
Staff Software Engineer        office: 503-677-5498
Intel Corporation

This email message solely contains my own personal views, and not
necessarily those of my employer.