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

    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/

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