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
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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Sep 23 2002 - 22:00:41 EST