Patent Document

BACKGROUND OF THE INVENTION  
         [0001]    The WINDOWS driver model (WDM) is a driver technology developed by the MICROSOFT Corporation that supports drivers which are compatible for WINDOWS 98, 2000, ME AND XP. WDM allots some of the work of the device driver to portions of the code that are integrated into the operating system. These portions of code handle low-level buffer management, including direct memory access (DMA) and plug-n-play (PnP) device enumeration.  
           [0002]    A DRIVER_OBJECT data structure, corresponding to a single loaded device driver according to WDM, contains a table of function pointers referred to as the dispatch table. The numerical values used to index into the table, namely to find specific functions, are called function codes and are given symbolic names that refer to a type of input/output (IO) such as READ and WRITE or refer to other requests such as CREATE, DEVICE_CONTROL and PnP.  
           [0003]    The function located in the table at the corresponding index is expected to implement logic for carrying out such an IO request. The operating system delivers IO request packets (IRPs) to these functions. The operating system also, for each IRP, identifies the device for which the request is intended, in the form of a DEVICE_OBJECT data structure. Such a DEVICE_OBJECT was previously initialized by the driver and represents a single device handled (driven) by the driver. A driver defines its own dispatch functions and inserts them into the dispatch table in its DRIVER_OBJECT at the time the driver initializes itself.  
           [0004]    A device node (devnode) is the context (set of data structures and configuration storage) representing a single device within a WDM operating system. If the device is active (connected and enabled for use), then (in the kernel) such a context will include a stack of device object structures, typically one per driver in the layered driver architecture for that type of device. By convention, stacks are said to be built from the bottom up (with the device being below the bottom of the stack) and dismantled from the top down. It is noted that being lower in the stack connotes being closer in terms of directness of communication to the device, while higher connotes being farther away.  
           [0005]    Device objects (DOs) in the stack fall into one of three categories. The bottom-most device object is created by the driver for the bus that provides access to the device and is called the physical device object (PDO). The bus driver provides raw communications capability to the device, but little in the way of higher-level device-specific functionality.  
           [0006]    Typically a function device object (FDO) is created by a driver which provides access to device-specific and higher-level capabilities of the device. An FDO will be located higher in the device stack than a PDO. In addition to the PDO and FDO, there may optionally be one or more filter device objects (FiDOs). Such FiDOs may be located in the device stack between the PDO and FDO, or above the FDO.  
           [0007]    [0007]FIG. 1 is a software block diagram that illustrates the layered relationships of objects according to the WDM architecture. Such a WDM architecture  100  includes a device  102  and a bus  104  to which the device  102  is physically connected. A host computing device  105  is also connected to the bus  104 . The host  105  includes a variety of software such as an enumerator of bus devices (hereafter DO enumerator)  110 , application  106 , a PnP manager  108 , a bus function driver  112 , and a device function driver  116 . It is noted that there also may be one more lower filter drivers and one or more upper filter drivers or none at all.  
           [0008]    When a device  102  is connected to a bus  104 , the bus driver  112  notifies the operating system of a change on the bus. The operating system, i.e., the PnP manager  108 , issues a query to the bus  104  via an IRP sent downward in the layered architecture instructing the bus function driver  112  to discover (or enumerate) the devices currently connected to the bus  104 . In response to this query, the bus function driver  112  generates PDOs for any newly-connected/discovered devices and provides a set of pointers to the newly-generated PDOs as well as previously-existing PDOs (corresponding to previously albeit currently connected devices). Strictly speaking, the set of DOs represented by the returned pointers are not PDOs until the operating system, namely the PnP manager, examines the set and becomes aware of these DOs.  
           [0009]    The PnP manager  108  locates and loads into volatile memory (if not already loaded) the function driver and any filter drivers for the newly-connected devices. It then gives each filter driver and/or function driver an opportunity to create and attach corresponding FiDOs or FDOs to the stacks rooted in the new PDOs, respectively. Ultimately, an application  106  can access a device  102  i.e., consume the functional abilities of the device  102 , by passing IRPs through the stack.  
           [0010]    When the device is to be disconnected or disabled, the stack must be destroyed. From the top down, under the coordination of the PnP manager  108 , each driver detaches its device object from the stack and deletes it.  
           [0011]    More detail is provided in FIG. 5, which is a sequence diagram according to the unified modeling language (UML) principles. The sequence  500  in FIG. 5 depicts the various interactions between the device  102 , the bus  104 , the bus driver  112 , the PnP manager  108 , the device lower filter driver  114 , the device function driver  116 , the device upper filter driver  118  and the application  106 . The device  102  connects to the bus  104  at message  518 . The bus  104  then notifies the bus driver  112  of a change in connected devices at message  520 . The bus driver  112  notifies the PnP manager  108  of a change in connected devices at message  522 . The PnP manager  108  queries the bus  104  to obtain a set of connected devices via message  524 , e.g., an IRP, to the bus driver  112 . If not already known by the bus driver  112 , then the bus driver  112  queries the bus  104  to discover the connected devices via the query message call  526 . The bus driver  112  creates PDOs for newly discovered devices and returns pointers to (addresses of) all PDOs representing devices connected to the bus to the PnP manager  528 .  
           [0012]    Upon receiving the set of PDOs, the PnP manager enters a loop  530  by which it handles any PDO in the set of which the PnP manager was not previously aware. At message  532 , the PnP manager passes one of the PDOs to any device lower filter drivers  114  that might be present. In response, each device lower filter driver attaches a new FiDO to the corresponding stack  128  (see legend  534  in FIG. 5). Then the PnP manager  108  passes the PDO to the device function driver  116 , at message  536 .  
           [0013]    In response, the device function driver  116  attaches a new, named FDO to the device stack  128  and correspondingly registers device-class interfaces (see legend  538 ) by which consumers can access the device stack. Next, the PnP manager  108  passes the PDO to any device upper filter drivers  118 , at message  540 . In response, each device upper filter driver  118  attaches a new FiDO  126  to the device stack  128  (see legend  542 ). Lastly, the PnP, manager  108  notifies applications  106  of the availability of the new device  102 , at message  544 . In response, the applications  106  may utilize (consume the services of) the device  102  (see legend  546 ).  
           [0014]    Returning to FIG. 1, a stack  134  for the bus  104  is depicted. The stack  134  includes a PDO for the bus  130  (generated by the bus DO enumerator  110 ) and a bus FDO  132  (generated by the bus function driver  112 ).  
           [0015]    A stack  128  for the device  102  has also been created. The stack  128  includes a PDO  120  (generated by the bus function driver  112 ), and (possibly) a FiDO  122  (generated by the optional device lower filter driver  114 , if present), an FDO  124  (generated by the device function driver  116 ) and (possibly) a FiDO  126  (generated by the device upper filter driver  118 , if present). In other words, if the device lower filter driver  114  and/or the device upper filter driver  118  are not present, then the FiDO  122  and/or the FiDO  126  will not be present, respectively.  
           [0016]    In a storage area network (SAN), a device (not depicted) can be sub-divided into smaller units representing different functions, known as logical units (LUNs). Device  102  may be such a LUN. A device or LUN can represent a type of massive non-volatile storage, configuration functionality, monitoring functionality and/or mechanical functionality (such as tape changing), etc. The host  105  can have an application  106  that stores data to, reads data from and/or otherwise utilizes the functionality of device  102 , i.e., consumes the services of the device  102 . In some SANs, there can be multiple non-volatile memory devices or other devices  102 , some of which the host  105  might not have permission to access.  
           [0017]    Control over access to certain ones of the devices  102  (also known as LUN masking) has been implemented within the bus driver  112  according to the Background Art. Given the many different types of buses  104  and corresponding drivers  112 , the resulting variety of control techniques embedded within the various drivers  112  is unwieldy unless the various bus vendors  104  agree to and abide by a standardized mechanism within the bus driver  112 . Such cooperation has not been forthcoming.  
         SUMMARY OF THE INVENTION  
         [0018]    A filter driver code arrangement (on a computer-readable medium for use in a system having a bus, a host connected to the bus and one or more devices connected to the bus), which prevents access by the host to any of the devices for which the host does not have respective access permission. Such a filter driver includes: an intercept code portion to intercept a set of data identifying one or more devices connected to the bus, respectively; a determination code portion to determine, based upon the data set and a permission set representing permission relationships between the host and the one or more devices, whether the host has permission to access each of the one or more devices; and a change code portion to change the data set to block access by the host to any of the one or more devices for which the host does not have access permission.  
           [0019]    Additional features and advantages of the invention will be more fully apparent from the following detailed description of example embodiments, the appended claims and the accompanying drawings. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0020]    [0020]FIG. 1 is a software block diagram according to the Background Art.  
         [0021]    [0021]FIG. 2 is a hardware block diagram according to the an embodiment of the invention.  
         [0022]    [0022]FIG. 3 is a hardware block diagram according to an embodiment of the invention.  
         [0023]    [0023]FIG. 4 is a software block diagram according to an embodiment of the invention.  
         [0024]    [0024]FIG. 5 is a sequence diagram according to the Background Art.  
         [0025]    [0025]FIG. 6 is a sequence diagram according to an embodiment of the invention.  
         [0026]    [0026]FIG. 7 is a sequence diagram according to an embodiment of the invention.  
         [0027]    [0027]FIG. 8 is a combined software block diagram and flowchart according to another embodiment of the invention.  
         [0028]    The accompanying drawings are: intended to depict example embodiments of the invention and should not be interpreted to limit the scope thereof; and not to be considered as drawn to scale unless explicitly noted.  
         [0029]    FIGS.  5 - 7  are UML sequence drawings. Messages are depicted with arrows of different styles. A→indicates a message that expects a response message. A←indicates a response message. A→indicates a message for which the response is implied. And a          indicates a message for which no response is expected. 
     
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS  
       [0030]    Embodiments of the invention provide low level, (e.g., kernel-mode driver) software that prevents users, applications and/or higher-level drivers (including the input/output (IO) systems of the operating system) from accessing particular devices. Such software can be part of a greater system that coordinates access privileges of several hosts to network devices. Such software is loaded on the host that is also running applications that might access the devices if given permission to do so.  
         [0031]    [0031]FIG. 2 depicts a hardware block diagram of a system  200  according to an embodiment of the invention that incorporates software according to an embodiment of the invention. The system  200  includes a bus (e.g., SCSI, Ethernet (iSCSI/IP/Gbit Ethernet), fibre channel, etc.)  202  to which are connected a consumer of device services (hereafter a device consumer)  204 , a device  210  and a device  218 .  
         [0032]    The device consumer  204  includes host bus adapters (HBAs)  206  and  208  that permit the device consumer  204  to connect to and interact with the bus  202 . The device  210  has port  1  ( 212 ), port  2  ( 214 ), . . . port N ( 216 ). Device  218  has port  1  ( 220 ), port  2  ( 222 ), . . . port N ( 224 ). For simplicity of disclosure, only two devices  210  and  218  and two HBA&#39;s  206  and  208  have been depicted, but fewer or more devices could be attached to the bus and fewer (1) or more HBAs could be present in the consumer depending upon the particular circumstances of a situation.  
         [0033]    [0033]FIG. 3 depicts a hardware block diagram corresponding to a particular type of system  200 , namely a storage area system or storage area network (SAN)  300 . The SAN  300  includes a bus  302 , a device consumer  304  and a non-volatile storage device  310 .  
         [0034]    The device consumer  304  can include HBAs  306  and  308 . Fewer or greater numbers of HBAs  306 / 308  can be provided depending upon the circumstances of a situation.  
         [0035]    The device consumer  304  can take the form of a computer  326  including at least a CPU, input device(s), output device(s) and memory. For example, the computer  326  has been depicted as including a CPU, an IO device, volatile memory such as RAM and non-volatile memory such as ROM, flash memory, disc drives and/or tape drives.  
         [0036]    The storage device  310  includes port  1  ( 312 ), port  2  ( 314 ), . . . port N ( 316 ) and logical units (LUNs)  1 ,  2 , . . . N. Also included in the storage device  310  are non-volatile memories  318  such as disc drives, tape drives and/or flash memory. To remind the reader of the logical nature of a LUN, a simplistic mapping between the LUNs  320 ,  322  and  324  and to physical memory devices  318  has been illustrated in FIG. 3. For the purposes of this discussion, a LUN will be considered interchangeable with a device  210  or  218 .  
         [0037]    In the environment of a storage area network  300 , a storage area manager program operates to prevent consumer applications running on device consumers  304  from accessing LUNs to which the host (or device consumer)  304  has not been granted access by the storage manager. In a WDM architecture, a consumer application on a host device  304  cannot see a device  320 ,  322  and/or  324  if there is no FDO in the stack of the device visible to an application running on the host. So if the generation of such an FDO can be suppressed, then the application cannot access the device. Also, there can be circumstances in which no FDO is present but the device can still be accessed, hence the ability to hide the PDO can be desirable.  
         [0038]    How can the generation of FDOs and FiDOs by the function drivers and the filter drivers be suppressed? One way is to prevent the PnP manager from passing the device PDO to the function and filter drivers (notifying the drivers).  
         [0039]    So how is the notifying of such drivers by the PnP manager suppressed? Recalling that the filter and function drivers are notified by the PnP manager in response to the PnP manager receiving PDOs corresponding to those drivers, one way to prevent the notification of such drivers is to prevent the PnP manager from receiving PDOs for the devices to which access by the host device has restricted. This similarly suppresses notification of other consumers that might access the device via its PDO despite the lack of an FDO in the stack.  
         [0040]    According to an embodiment of the invention, the PnP manager  108  is prevented from seeing those PDOs, to which the PnP manager&#39;s host is not granted access, by loading a filter driver that selectively edits the set of PDO pointers returned by the bus driver to the PnP manager.  
         [0041]    [0041]FIG. 4 depicts a software block diagram according to an embodiment of the invention. FIG. 4 has some similarities to Background Art FIG. 1. As such, some of the blocks in FIG. 4 are given the same number as in FIG. 1 with little to no further description.  
         [0042]    The system  400  in FIG. 4 includes a device  102 , a device  410 , and a host  401  each of which is connected to a bus  104 . The host (or device consumer)  401  includes an application program  106 , a plug-n-play (PnP) manager  108 , a bus DO enumerator  110 , a bus function driver  112 , a mask filter driver  402 , a database  403  (having a set of identifiers of devices for which the host  401  does/does-not have access permission), an optional device lower filter driver  114 , a device function driver  116  and an optional device upper filter driver  118 .  
         [0043]    Communications between the bus driver  112  and the PnP manager  108  pass through the mask filter driver  402 . The filter driver  402  is given the adjective mask because it selectively controls which PDOs, i.e., devices, the PnP manager  108  can see.  
         [0044]    A stack  134  is created for the bus  104 . Subsequently a stack  406  is created for the device  102  and a stack  412  is created for the device  410 .  
         [0045]    In FIG. 4, it is assumed for the sake of discussion that permission has been granted for the host  401  to access the device  102  but does not have permission to access the device  410 . During assembly of the stack  134 , the mask filter driver will create a bus upper filter device object (bus upper FiDO)  404  in the stack  134 . Similarly, the mask filter driver  402  will generate a FiDO  408  during assembly of the stack  406  and an FiDO  416  during assembly of the stack  412 .  
         [0046]    [0046]FIG. 6 is a sequence diagram according to an embodiment of the invention. The sequences  600  correspond to what takes place during the generation of the stack  406  in FIG. 4. At message  622 , the device  102  connects to the bus  104 . At message  624 , the bus  104  notifies the bus function driver  112  of a change in the devices connected to it. At message  626 , the bus driver  112  notifies the PnP manager  108  of a change in the connected devices via, e.g., a kernel function named lo Invalidate Device Relations ( ).  
         [0047]    At message  628 , the PnP manager responds by querying the bus driver  112  to learn of the devices connected to the bus  104  via an IRP. At message  630 , the bus driver  112  queries the bus  104  to discover connected devices. At response  632 , the bus driver  112  returns a set of pointers to PDOs representing the attached devices. Though the bus driver  112  intends for the set to be received by the PnP manager  108 , it is intercepted by the mask filter driver  402 . The mask filter driver  402  then enters a loop  634  to determine if new PDOs arc present.  
         [0048]    At subroutine call  636 , the mask filter driver  402  examines the current PDO from the set and determines whether it existed previously. The mask filter driver  402  can do this by checking whether a corresponding FiDO  408 / 416  exists in the stack  406 / 412 . If no FiDO  408 / 416  yet exists, the mask filter driver  402  creates the device lower FiDO  408 / 416  and attaches it to the stack  406 / 412 , at procedure  638 . Next the mask filter driver  402  sends query message  640  to the device to retrieve its unique identifier. At procedure  642 , the mask filter driver  402  stores the identifier of the device  102 , in a private field of the FiDO  408 . A private field is part of a device extension structure associated with the device object. The field is private in the sense that only the driver that creates the DO can interpret the data stored in the device extension structure.  
         [0049]    At message  644 , the mask filter driver  402  checks whether the device identifier in the device extension of FiDO  408 / 416  corresponds to a device for which the host  401  should have access. The mask filter driver  402  can do this by comparing the device identifier against members of the set of identifiers within the database  403 . The set within database  403  can include identifiers of devices which the host  401  has permission to access or can include identifiers of devices for which the host  401  does not have permission to access.  
         [0050]    [0050]FIG. 6 assumes the circumstance in which the set within database  403  includes identifiers of devices for which the host  401  has permission. So if the device identifier indicated by one of the private fields in the device extension of FiDO  408  is not present in the set within database  403 , that would mean that the host  401  does not have access permission. Where the host  401  does not have access permission, the mask filter driver  402  would edit the set of pointers to remove the pointer pointing to the PDO corresponding to the device for which the host  401  does not have access permission, at procedure  646 .  
         [0051]    It is to be remembered that FIGS. 6 and 4 assume that the host  401  does have permission to access the device  102 . Hence, message  646  does not cause the PDO corresponding to the device  102  to be removed from the set of pointers because it does not occur in the loop iteration for device  102 .  
         [0052]    At legend  648  within the loop  634 , the filter driver  402  repeats the loop  634  for each of the remaining new PDOs in the set. After exiting the loop  634 , at message  650 , the mask filter driver  402  propagates an edited set of PDO pointers to the PnP manager  108 . Then, the PnP manager  108  enters the loop  530  discussed in Background Art FIG. 5.  
         [0053]    [0053]FIG. 7 is a sequence diagram depicting the sequences related to the creation of the stack  412  (corresponding to device  410 ) in FIG. 4. FIGS. 4 and 7 assume that the host  401  does not have permission to access the device  410 . FIG. 7 is similar to FIG. 6. Hence, similar messages will be labeled with the same reference number and will not be discussed in detail.  
         [0054]    At message  702 , the device  410  connects to the bus  104 . Then messages  624 ,  626 ,  628 ,  630  and  632  are exchanged similarly to FIG. 6. After message  632 , the mask filter driver  402  enters the loop  634 . For the sake of brevity, it will be assumed that the first new PDO examined by the mask filter driver  402  corresponds to the device  410 . That is, it is PDO  414  in FIG. 4. Initially, message  636 ,  638 ,  640  and  642  are exchanged similarly to FIG. 6. At message  704 , the mask filter driver  402  checks whether the device  410  is assigned to the host  401 , i.e., whether the host  401  has permission to access the device  410 .  
         [0055]    At message  706 , the database containing a set of identifiers responds that the host  401  does not have permission to access the device  410 . At procedure  708 , the mask filter driver  402  removes the pointer for the PDO  414 , corresponding to device  410 , from the set of pointers. After repeating the loop  634  for the remaining (if any) PDOs, at message  650 , the mask filter driver  402  provides the edited set of pointers to the PnP manager  108 . At legend  710  in FIG. 7, as a consequence of the PnP manager  108  not being able to see a reference to the PDO  414 , the PnP manager  108  does not do procedures for PDO  414 . That is, the PnP manager  108  does enter loop  530 , but does not encounter PDO  414  in this loop.  
         [0056]    [0056]FIG. 8 is a combined software block diagram and flowchart according to another embodiment of the invention. As a practical matter, FIG. 8 is a combination of FIGS. 4 and 6- 7 , hence no further discussion of FIG. 8 is provided.  
         [0057]    Referring back to FIG. 4, it should be understood that the mask filter driver  402  has prevented the host  401  from accessing the device  410  by suppressing the generation and attachment of the following to stack  412 : of an FDO (corresponding to the FDO  124  of stack  406 ); and (possibly if a lower and/or upper filter driver are present) FiDOs (corresponding to the FiDOs  122  and  126  of stack  406 ). It has also prevented the PnP Manager from becoming aware of the PDO and creating an active devnode for the stack, preventing it from notifying consumers that might access the device via the PDO despite the lack of an FDO of the existence of the new device.  
         [0058]    To restate, an embodiment of the invention is a filter driver for bus, e.g., SCSI port, devices. The filter driver attaches an FiDO above the FDO for SCSI-like SAN host bus adapters (HBAs). When the PnP manager queries the HBA device stack to discover connected devices, the query request and the response thereto must pass through the mask filter driver. For each pointer to a connected device PDO that is returned, the mask filter driver determines the device&#39;s unique identifier (ID), and then checks this ID against product configuration information to determine if the device is one to which the host machine is granted access.  
         [0059]    If access has not been granted, the mask filter driver removes the pointer to that PDO from the set of pointers being returned by the HBA driver, so that the PnP manager will not see it. Because it is not included in the set, the PDO is not designated as a true PDO, and the corresponding device stack is not completed and activated. Accordingly, no class function driver will be invoked to create an FDO for the device. Typical consumers cannot find the device object  414 . Even a specialized consumer that can find the device object  414  cannot invoke device class-specific features provided by the corresponding function driver because that driver is unaware of the device and does not have an FDO in the stack  412  based on DO  414 .  
         [0060]    According to another embodiment of the invention, if the host is granted access to a logical unit (again treated as a device connected to the bus) while the host is online, this change is communicated to the mask filter driver. The mask filter driver can notify the PnP manager of a change on the bus (HBA). In response, the PnP manager can issue a new discovery request to the HBA. This time, the mask filter driver would not remove the pointer to the corresponding DO from the returned set. Consequently, the DO becomes a true PDO and thus a basis for a complete device stack and an active devnode. The corresponding function driver and filter drivers are notified of the new device so that they can create an FDO and FiDOs for the device to which access has just recently been granted. This make the device accessible to typical consumers.  
         [0061]    Also, access by a host to a logical unit can be revoked while the host is online via the mask filter driver according to an embodiment of the invention. The storage manager program (an application running on the same host or another host not depicted) can direct a configuration manager (not depicted) in the affected host to destroy the device stack, which includes removing the FDO from the stack and destroying the FDO. Subsequently, if the PnP manager is notified to query the bus for connected devices, the mask filter driver will once again hide the DO from the PnP manager.  
         [0062]    As an alternative, the existence of device objects can be managed so as to manipulate the availability of devices to consumers by supplying a replacement for the function driver responsible for creating corresponding FDOs. But this requires more code and is more intrusive. In contrast, the mask filter driver according to embodiments of the invention requires less code and is less intrusive because it works in conjunction with the PnP manager and the typical function drivers provided in a WDM-compliant architecture. Not replacing the function drivers decreases the possibility that the device object management will introduce compatibility or stability problems.  
         [0063]    The invention may be embodied in other forms without departing from its spirit and essential characteristics. The described embodiments are to be considered only non-limiting examples of the invention. The scope of the invention is to be measured by the appended claims. All changes which come within the meaning and equivalency of the claims are to be embraced within their scope.

Technology Category: h