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.