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

Jeff Garzik jgarzik at pobox.com
Mon Sep 23 18:41:46 PDT 2002

Gustafson, Geoffrey R wrote:
> Most of what makes a 'good' driver is common for all purposes - things you
> mention like don't make the system hang, don't cause fatal exceptions. But
> there are some things that would be different between a desktop, embedded
> system, enterprise server, or carrier server. For instance, when there is a
> tradeoff between reliability and performance; when reliability is king, it
> might be wise to do an insane amount of parameter checking to offset the
> merest chance of an undetected bug crashing a system.

This is not a valid example.  We do not make tradeoffs between 
performance and reliability.  Reliability _always_ comes first.  If it 
did not, it's a bug.

> Regarding the question: why not just fix the "bad" drivers? Drivers that are
> actually bad are probably for obscure hardware that is not really of
> concern. The purpose is to take good drivers and make sure they meet the
> last few percent of the objective standard of 'good'.

What exactly does this mean?  Can you give a concrete example of taking 
an existing driver and updating it for that last few percent?

[I venture to guess that Intel doesn't know yet what is necessary, but 
that's just a guess.]

> Another good point was about enforcement. Just because something is hardened
> at one point, doesn't necessarily mean some of the rules won't get
> accidentally violated by patches later on. So it either requires periodic
> reevaluation or strong buy-in from the respective maintainers. At least part
> of the beauty of open source is it _can_ be evaluated by an objective third
> party, if someone chose to do that.

It depends on what needs to be "enforced."  If its compliance to 
existing APIs, that's pretty much a given.  Non-compliance would be a bug.

> You asked several times for objective data, and I agree that would be great.
> However, drivers _are_ in the unique position of being both privileged code
> and yet specific to certain hardware. Thus they are capable of more damage
> than user-space code, but (on average) can't have been tested in as many
> configurations as core kernel code. So at least without data, they are a
> very logical starting point.

That's still not a concrete example :)  We already knew you were talking 
about drivers.

Does Intel even have --one-- example of a driver that could be hardened?

It seems to me Intel is writing a spec for an abstract objective, IOW 
writing a solution when the problem hasn't even been defined yet. 
Please define the problem ("<this> API needs updating to harden 
drivers") not the solution ("add <this> API and drivers will be hardened").

Finally, and this bears repeating -- I am very encouraged by Intel's 
participation, and initiative in hardening Linux drivers.  I actively 
encourage this effort, and think that Intel's resources can 
[potentially] dramatically improve the overall quality of Linux kernel 
drivers.  Guys, you have an excellent opportunity here ;-)  Please 
listen to the feedback from kernel developers, we are the guys in the 
trenches doing the Real Life software engineering day in and day out.


More information about the cgl_discussion mailing list