[lkml]   [2002]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:29    [W:0.033 / U:0.300 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site