[cgl_discussion] Re: [Hardeneddrivers-discuss] Some Initial Comments on DDH-Spec-0.5h.pdf

Jeff Garzik jgarzik at pobox.com
Mon Sep 23 16:51:48 PDT 2002

Good comments...  let me respond in general, mainly to the 
specification/draft and not you directly.

Andy Pfiffer wrote:
> 	I'm not sure I fully understand the problem/feature that is
> 	attempting to be addressed by this specification.  I have a hunch,
> 	but I don't see it expressed clearly and unambiguously
> 	at the beginning of the document.


> 	Is that correct?  It would be most helpful if there were
> 	real-world examples (or statistics) cited to indicate that
> 	non-hardended drivers were the obstacle for carrier-grade
> 	use of Linux,


> 	Generic question: why not just fix the "bad" drivers?

I think any CGL/hardened effort that _ignores_ bad drivers in favor of 
implementing coding standards and APIs will likely be laughed out of the 
room :)

Andy's question is -not- flippant [at least to me], but a key one WRT 
CGL and hardened drivers.

> 	Generic question: why not focus the "hardening effort" on the
> 	edges of the kernel interfaces, rather than on a driver-by-driver
> 	basis?  Specifically: why not put the "professional paranoia"
> 	into all of the kernel code that calls into drivers, and all
> 	of the routines commonly called by drivers?  One could move
> 	from a model of "this driver is hardened" to "all drivers
> 	are suspect until proven otherwise."  Wouldn't that address
> 	90% of the perceived problem up front, rather than spending 100%
> 	effort to "harden" one driver at a time?

I think a good and useful effort can be put into improving existing 
kernel APIs and code such that it becomes (a) easier to write a 
"hardened" driver, and (b) more difficult to write a buggy/unstable driver.

> 	General comment: the specification, as written, does not address
> 	an way to enforce compliance, largely because the Stability
> 	and Reliability section is based upon the list of Good Coding
> 	Practices.

I do not think it is possible to enforce compliance.

> Re: What is a Hardened Driver?
>   "fault handling"
>   "fault recovery"
>   "fault prediction"
>   "fault analysis"
> 	I'd recommend moving this closer to the beginning of the
> 	specification.  My hunch is that "driver hardening" is
> 	really about just these four items.


>   Quote:
> 	"A typical device driver design focuses on the normal,
> 	 proper operation of the hardware; attention to driver
> 	 behavior in the event of hardware faults is often minimal."
[again, note I am responding to the draft and not Andy]

This statement says a lot to me about the perspectives here...  a 
typical device driver design should always include factors that make it 

And I echo Andy's comment.  Let's see -concrete- examples, not 
pie-in-the-sky guesses.

> 	My opinion after reading this section that a "hardened driver"
> 	is equivalent to a "good driver", and that "hardened with diagnostics"
> 	is equivalent to a "good driver with standard diagnostics", and
> 	"hardened with instrumentation" is a "good driver with standard
> 	instrumentation."


finally, let me make the general comment that any new APIs are going to 
be looked upon with much skepticism by the general kernel community, 
unless Intel makes concrete its abstract goals, and makes a concrete 
effort to actually point out flaws that need fixing.


More information about the cgl_discussion mailing list