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

[Jeff Garzik]

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.

	Jeff