Messages in this thread | | | Date | Mon, 23 Sep 2002 21:41:46 -0400 | From | Jeff Garzik <> | Subject | Re: [Hardeneddrivers-discuss] RE: [cgl_discussion] Some Initial Comments on DDH-Spec-0.5h.pdf |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |