Nooks review

From: David Coleman \(Roxio Inc\) (v-davcol_at_windows.microsoft.com)
Date: Wed Jan 21 2004 - 15:31:57 PST

  • Next message: Gail Rahn: "Review of Nooks"

    Nooks is a clever idea in which it isolates and protects the kernel from
    buggy drivers via an isolation layer between the driver and the kernel.
    The basic principle involved is to design for fault resistance not fault
    tolerance and to protect against poorly written but not malicious
    drivers. The goal is to provide isolation (and thus protection) and the
    ability to recover from errors without requiring modifications to
    existing drivers thus achieving backward compatibility with the large
    quantity of drivers in the field (estimated to be over 130,000 drivers
    for the Windows platform).

     

    Basically, Nooks sits between the OS kernel and driver. All calls from
    the driver to the kernel go through Nooks and vice-versa by hooking the
    entry points of both. Each driver that Nooks isolates has its own
    writeable address space with the rest of kernel address space set to
    read-only access. An Object Manager effectively marshals data between
    the kernel and the driver. It appears that drivers that run off of the
    end of arrays (writing), corrupting the stack and returning to random
    places, corrupting kernel data structures, etc. are the class of bugs
    that Nooks protects against the most.

     

    The paper claims it would port well to the Windows operating systems. I
    think there might be problems attempting to do so. First, file system
    drivers have a particularly incestuous relationship with other drivers
    and kernel data structures and might be difficult to recover from (of
    course dismounting volumes does work, so there's precedent for this type
    of behavior). Given that Windows uses a layered driver model and that
    individual drivers create the Device Objects that make up the layers,
    I'd be curious to know if the Nooks architecture would consider these
    Device Objects to be kernel data structures and thus protected by the
    Object Manager. If so, performance would probably suffer greatly on the
    Windows platform as the protection mechanisms would have to be invoked
    multiple times per I/O. Also Plug and Play and power management issues
    might also complicate the implementation of the Object Manager when
    events such as surprise removals happen. If not, isolating an entire
    device stack would probably be sufficient and would allow fairly easy
    recovery from crashes. However, the protections would not be as great
    due to the fact that Device Objects are referenced in a wide variety of
    areas and thus a driver would be able to corrupt a Device Object and the
    corruption would not be caught.

     

    Another issue I foresee with a real-world implementation of Nooks is
    simply that the performance hit would be too large and clever (devious)
    driver writers would find methods of getting around the architecture to
    improve performance. One thing that OS designers fail to take into
    account is, instead being a generic tool for supporting hardware on the
    OS, drivers are a source of competitive advantage for companies.
    Drivers need to do special things to support the uniqueness of the
    hardware they are running and to add value and functionality in addition
    to maximizing performance. As such, the first driver writer in a
    product class to circumvent Nooks (assuming that is possible - it seems
    like it would be given the design principle of assuming buggy but not
    malicious drivers), either for performance or functionality reasons,
    would force everyone in that group do so as well or face unfavorable
    product reviews.

     

    Another hurdle for Nooks to overcome is that drivers sometimes have to
    rely on some clever or ingenious "workarounds" (hacks) in order to get
    things working correctly. Sometimes these hacks are quite ugly and
    involve modifying the code of other drivers in the stack or hooking
    system calls to intercept or modify behavior. Nooks would seriously
    impact these efforts and might prevent support of certain devices.

     

    The recovery concept is very interesting. I'm not sure that it couldn't
    be implemented on Windows today simply by tearing down and rebuilding
    the stack simulating a device removal (I'm oversimplifying).

     

    Nooks is a very interesting concept that may or may not work in a
    production environment. I truly believe that most consumers will choose
    speed over reliability (as long as it is "reliable enough"). It seems
    like the complexity and inter-relationships of drivers and devices and
    the kernel under Windows would make the implementation very complicated
    but I think it would certainly be an interesting project.

     


  • Next message: Gail Rahn: "Review of Nooks"

    This archive was generated by hypermail 2.1.6 : Wed Jan 21 2004 - 15:32:04 PST