US20070220343A1 - Kernel module compatibility validation - Google Patents

Kernel module compatibility validation Download PDF

Info

Publication number
US20070220343A1
US20070220343A1 US11/365,278 US36527806A US2007220343A1 US 20070220343 A1 US20070220343 A1 US 20070220343A1 US 36527806 A US36527806 A US 36527806A US 2007220343 A1 US2007220343 A1 US 2007220343A1
Authority
US
United States
Prior art keywords
kernel
kernel module
data structure
module
incompatibility
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
US11/365,278
Other versions
US7581141B2 (en
Inventor
John Harres
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Oracle America Inc
Original Assignee
Sun Microsystems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sun Microsystems Inc filed Critical Sun Microsystems Inc
Priority to US11/365,278 priority Critical patent/US7581141B2/en
Assigned to SUN MICROSYTEMS, INC. reassignment SUN MICROSYTEMS, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: HARRES, JOHN M.
Publication of US20070220343A1 publication Critical patent/US20070220343A1/en
Application granted granted Critical
Publication of US7581141B2 publication Critical patent/US7581141B2/en
Assigned to Oracle America, Inc. reassignment Oracle America, Inc. MERGER AND CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: Oracle America, Inc., ORACLE USA, INC., SUN MICROSYSTEMS, INC.
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751Error or fault detection not based on redundancy
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment

Definitions

  • An embodiment of the invention relates to computer systems, and more specifically, to kernel module compatibility validation.
  • the kernel is a piece of software responsible for providing secure access to the computer system's hardware and to various computer processes. Accessing the hardware directly can be very complex, as there are different hardware designs for the same type of component. Kernels usually implement some hardware abstraction to hide the underlying complexity from the operating system and provide a clean and uniform interface to the hardware.
  • Kernels typically may employ one or more modules to assist in the functionality of the kernel. Kernel modules are pieces of code that can be loaded and unloaded into the kernel upon demand. They extend the functionality of the kernel without the need to reboot the system.
  • One example of a kernel module is a device driver, which allows the kernel to access hardware connected to the system of the kernel. Without modules, new functionality would have to be added directly into the kernel, creating the disadvantage of requiring the kernel to be rebuilt and rebooted every time the functionality needed to be added.
  • kernels are not statically linked and loaded, but instead dynamically linked in kernel modules and drivers at run time to provide functionality and/or support as needed.
  • the kernel modules can be validated against one another as they are loaded.
  • most of the information that would have been present at a static loading build time is not present at a run time of the dynamic loading.
  • the present invention includes novel methods and apparatus for kernel module compatibility validation.
  • a method includes maintaining a data structure in a kernel module that identifies information related to a system including the kernel module, the information to be manipulated by the kernel module, comparing, by a kernel in the system that loads the kernel module, the data structure of the kernel module with one or more other data structures of kernel modules the kernel loads, and performing, by the kernel, an error routine if an incompatibility is found between the data structure and the one or more other data structures.
  • an apparatus includes a processor and a memory unit coupled to the processor including instructions to execute a kernel.
  • the kernel is further to initialize a kernel module to maintain a data structure that identifies information related to a system, the information to be manipulated by the kernel module, compare the data structure of the kernel module with one or more other data structures of kernel modules the kernel loads, and perform an error routine if an incompatibility is found between the data structure and the one or more other data structures.
  • FIG. 1 is a block diagram of one embodiment of various functional units involved in interfacing application programs to system devices;
  • FIG. 2A is a block diagram illustrating one embodiment of a module data structure
  • FIG. 2B is a block diagram illustrating one embodiment of an updated module data structure
  • FIG. 3 is a flow diagram illustrating a method according to one embodiment of the invention.
  • FIG. 4 is an illustration of an embodiment of a computer system.
  • the method includes maintaining a data structure in a kernel module that identifies information related to a system including the kernel module, the information to be manipulated by the kernel module, comparing, by a kernel in the system that loads the kernel module, the data structure of the kernel module with one or more other data structures of kernel modules the kernel loads, and performing, by the kernel, an error routine if an incompatibility is found between the data structure and the one or more other data structures.
  • select embodiments of the present invention include various operations, which are described herein.
  • the operations of the embodiments of the present invention may be performed by hardware components or may be embodied in machine-executable instructions, which may be in turn utilized to cause a general-purpose or special-purpose processor, or logic circuits programmed with the instructions, to perform the operations.
  • the operations may be performed by a combination of hardware and software.
  • embodiments of the present invention may be provided as computer program products, which may include machine-readable medium having stored thereon instructions used to program a computer (or other electronic devices) to perform a process according to embodiments of the present invention.
  • the machine-readable medium may include, but is not limited to, floppy diskettes, hard disk, optical disks, CD-ROMs, and magneto-optical disks, read-only memories (ROMs), random-access memories (RAMs), erasable programmable ROMs (EPROMs), electrically EPROMs (EEPROMs), magnetic or optical cards, flash memory, or other types of media or machine-readable medium suitable for storing electronic instructions and/or data.
  • data discussed herein may be stored in a single database, multiple databases, or otherwise in select forms (such as in a table).
  • embodiments of the present invention may be downloaded as a computer program product, wherein the program may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., a modem or network connection).
  • a carrier wave shall be regarded as comprising a machine-readable medium.
  • Embodiments of the invention introduce a novel method to implement kernel module compatibility validation.
  • the kernel module compatibility validation prevents conflicting kernel modules from being loaded together. At the least, the compatibility validation identifies conflicts as early as possible so that they can be remedied. This reduces, or possibly eliminates, conflicts that exist in running kernels, thereby increasing reliability and improving uptime of systems.
  • FIG. 1 is a block diagram illustrating various functional units involved in interfacing application programs to various system devices.
  • Reference numeral 100 generally indicates a functional unit involved in interfacing application packages or programs to devices in a computer system.
  • the unit 100 includes various applications 120 , a shell 140 , a kernel 160 , kernel modules 180 , and various hardware devices or peripherals 190 .
  • the applications 120 typically include a word processor, a spreadsheet program, a web browser, or any other application that may be run on a computer system.
  • the various applications 120 use common hardware on the computer system and, accordingly, an interface should be provided between the various different applications and each hardware or peripheral device 190 .
  • This interface is provided by the kernel 160 that interacts with the applications 120 via the shell 140 and with the devices 190 .
  • some devices 190 may also be interacted with via the kernel modules 180 .
  • the kernel 160 defines the heart of an operating system, such as a UNIX-based operating system. Under control of the kernel 160 , the shell 140 interprets user commands of the application programs 120 whereupon the kernel 160 exports various application program interfaces (APIs) to the relevant devices 190 for execution.
  • APIs application program interfaces
  • a device 190 may be viewed as a file system and the kernel modules 180 accordingly communicate data in a binary format to the file system interface via specific APIs. Accordingly, each kernel module 180 is typically configured for the specific hardware that it drives and, since the kernel module 180 obtains its commands from the kernel 160 , the kernel module 180 and the kernel 160 should be configured to function with each other.
  • FIG. 2A is a block diagram illustrating a data structure that may be included in a kernel module according to embodiments of the invention.
  • the kernel module including the data structure may be the same as kernel module 180 described with respect to FIG. 1 .
  • data structure 200 corresponds to information about various components, such as a storage disk, that contain data which the kernel module may manipulate.
  • data structure 200 includes information such as field name 210 , type 220 , size 230 , and offset 240 .
  • Data structure 200 may include various fields 210 , such as vendor 250 , size 260 , bytes read 270 , and bytes written 280 .
  • the type 220 information identifies the actual data type of the field (e.g., array, integer, floating point, etc.).
  • the offset 240 identifies the storage location in the physical memory for the specific field 210 .
  • the vendor 250 field 210 of the data structure 200 includes a type 220 of an array of 80 characters, a size 230 of 80 B, and an offset 240 of 0.
  • the other fields 210 of the data structure 200 contain corresponding information for the specific fields. This information may be used by the kernel module for debugging purposes, and, as described below, for compatibility validation with other modules.
  • changes may be made to the disk so that the information contained in the data structures 200 of various kernel modules is no longer correct. For instance, the size 230 of a field 210 may be increased or decreased. In some cases, additional information may be added or deleted from the disk. These changes may lead to incorrect information being stored in data structures 200 of kernel modules. For example, a change in the size 230 information for a field 210 may affect the offset 240 information for other fields 210 following the affected field 210 on the disk. FIG. 2B provides an example of such a situation.
  • FIG. 2B is a block diagram illustrating an updated data structure 205 of a kernel module after a change has been made to a component of the kernel module.
  • Data structure 205 is the updated version of data structure 200 .
  • This new field 210 is geometry information 290 (i.e., number of platters).
  • the geometry field 290 includes a type 220 of integer, a size 230 of 4 B, and an offset of 84 .
  • the size 230 of the bytes read information 270 has been increased from 4 B to 8 B.
  • the kernel module should include an updated data structure similar to data structure 205 .
  • FIG. 2B the same information as that included in data structure 200 of FIG. 2A is present, with the addition of the geometry information 290 .
  • the size 230 of the bytes read information 270 was increased to 8 B.
  • the addition of the geometry information 290 affects the offsets 240 of both the bytes read 270 and bytes written 280 information.
  • the size 230 of the bytes read information 270 affects the offset 240 of the bytes written information 280 .
  • a kernel module If a kernel module is unaware of these component modifications, it would be loaded with old data structure 200 of FIG. 2A . Operating with this incorrect data structure 200 may cause potentially devastating effects to the operation of the kernel, as well as to the system that the kernel is operating with. In one embodiment, it may cause data that the kernel module believed to be part of the bytes read 270 field of memory to be manipulated, which would actually affect the geometry field 290 of the updated module. Depending on the data being actually manipulated, this could lead to system crashes and other negative effects.
  • FIG. 3 is a flow diagram illustrating a method according to one embodiment of the invention.
  • Process 300 addresses the potential for incompatible data structures in kernel modules.
  • Process 300 begins at processing block 310 , where a kernel module maintains a data structure that identifies information related to a system that the kernel module operates on. The information contained in the data structure may potentially be manipulated by the kernel module. In one embodiment, this data structure is the same as data structure 200 or 205 illustrated with respect to FIGS. 2A and 2B .
  • the kernel initializes the kernel module on the system.
  • the kernel compares the kernel module's data structure with all other data structures of kernel modules running on the system for incompatibilities. In some embodiments, this comparison includes matching the field names, types, sizes, and offsets of the information included in the data structures. For example, if an offset of a particular field in the data structure of kernel module being tested does not match an offset of the same field in another kernel module, then an incompatibility has occurred.
  • a signature or checksum may be utilized for the compatibility validation.
  • a subset of the various components of a data structure may be compared, instead of comparing the complete set of components, in order to save time in the compatibility validation.
  • this error routine may include generating an error message identifying the incompatibility.
  • the error routine may include correcting the incompatibility in the kernel module being initialized in order to make the data structure compatible with the updated component structure.
  • the error routine may include refusing to load the kernel module. The error routine may also be some combination of all of these embodiments. If no incompatibilities are found, then at processing block 360 the kernel module is loaded in a normal fashion.
  • the compatibility validation may occur at the time of system boot-up. It may also occur any time a kernel module is initialized. It is further envisioned that the compatibility validation may occur after the system is fully-booted, so that a cross-check of all the module information may take place while the system is still live. This may be done on-demand or at a scheduled time.
  • the compatibility validation may occur after a system crash occurs.
  • a tool may be run to analyze the kernel and kernel module memory and determine whether there are any kernel module incompatibilities.
  • One skilled in the art will appreciate the variety of implementations possible for the compatibility validation.
  • FIG. 4 illustrates an exemplary computer system 400 in which certain embodiments of the present invention may be implemented.
  • the components of FIG. 1 may be implemented as system 400 or as components of system 400 .
  • System 400 comprises a central processor 402 , a main memory 404 , an input/output (I/O) controller 406 , a keyboard 408 , a pointing device 410 (e.g., mouse, track ball, pen device, or the like), a display device 412 , a mass storage 414 (e.g., a nonvolatile storage such as a hard disk, an optical drive, and the like), and a network interface 418 . Additional input/output devices, such as a printing device 416 , may be included in the system 400 as desired. As illustrated, the various components of the system 400 communicate through a system bus 420 or similar architecture.
  • system 400 may be a distributed computing system.
  • one or more of the various components of the system 400 may be located in a physically separate location than the other components of the system 400 .
  • Such components may be accessed and connected via a network to the other components
  • the computer system 400 includes a Sun Microsystems computer utilizing a SPARC microprocessor available from several vendors (including Sun Microsystems, Inc., of Santa Clara, Calif.).
  • Sun Microsystems, Inc. of Santa Clara, Calif.
  • any type of computer system may be utilized to embody the present invention, including those made by Hewlett Packard of Palo Alto, Calif., and IBM-compatible personal computers utilizing Intel microprocessor, which are available from several vendors (including IBM of Armonk, N.Y.).
  • processor 402 may be a complex instruction set computer (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, a processor implementing a combination of instruction sets, and the like.
  • CISC complex instruction set computer
  • RISC reduced instruction set computing
  • VLIW very long instruction word
  • the network interface 418 provides communication capability with other computer systems on a same local network, on a different network connected via modems and the like to the present network, or to other computers across the Internet.
  • the network interface 418 can be implemented utilizing technologies including, but not limited to, Ethernet, Fast Ethernet, Gigabit Ethernet (such as that covered by the Institute of Electrical and Electronics Engineers (IEEE) 801.1 standard), wide-area network (WAN), leased line (such as T1, T3, optical carrier 3 (OC3), and the like), analog modem, digital subscriber line (DSL and its varieties such as high bit-rate DSL (HDSL), integrated services digital network DSL (IDSL), and the like), cellular, wireless networks (such as those implemented by utilizing the wireless application protocol (WAP)), time division multiplexing (TDM), universal serial bus (USB and its varieties such as USB II), asynchronous transfer mode (ATM), satellite, cable modem, and/or FireWire.
  • WAP wireless application protocol
  • TDM time division multiplexing
  • USB universal serial
  • the computer system 400 may utilize operating systems such as Solaris, Windows (and its varieties such as CE, NT, 2000, XP, ME, and the like), HP-UX, IBM-AIX, PALM, UNIX, Berkeley software distribution (BSD) UNIX, Linux, Apple UNIX (AUX), Macintosh operating system (Mac OS) (including Mac OS X), and the like.
  • operating systems such as Solaris, Windows (and its varieties such as CE, NT, 2000, XP, ME, and the like), HP-UX, IBM-AIX, PALM, UNIX, Berkeley software distribution (BSD) UNIX, Linux, Apple UNIX (AUX), Macintosh operating system (Mac OS) (including Mac OS X), and the like.
  • BSD Berkeley software distribution
  • Mac OS Macintosh operating system
  • the computer system 400 is a general purpose computer capable of running any number of applications such as those available from companies including Oracle, Siebel, Unisys, Microsoft, and the like.

Abstract

In one embodiment, a method and apparatus for high-efficiency time-series archiving for computer server telemetry signals are disclosed. The method includes maintaining a data structure in a kernel module that identifies information related to a system including the kernel module, the information to be manipulated by the kernel module, comparing, by a kernel in the system that loads the kernel module, the data structure of the kernel module with one or more other data structures of kernel modules the kernel loads, and performing, by the kernel, an error routine if an incompatibility is found between the data structure and the one or more other data structures. Other embodiments are also disclosed.

Description

    FIELD OF INVENTION
  • An embodiment of the invention relates to computer systems, and more specifically, to kernel module compatibility validation.
  • BACKGROUND OF INVENTION
  • One central component of a computer system is its operating system kernel. The kernel is a piece of software responsible for providing secure access to the computer system's hardware and to various computer processes. Accessing the hardware directly can be very complex, as there are different hardware designs for the same type of component. Kernels usually implement some hardware abstraction to hide the underlying complexity from the operating system and provide a clean and uniform interface to the hardware.
  • Kernels typically may employ one or more modules to assist in the functionality of the kernel. Kernel modules are pieces of code that can be loaded and unloaded into the kernel upon demand. They extend the functionality of the kernel without the need to reboot the system. One example of a kernel module is a device driver, which allows the kernel to access hardware connected to the system of the kernel. Without modules, new functionality would have to be added directly into the kernel, creating the disadvantage of requiring the kernel to be rebuilt and rebooted every time the functionality needed to be added.
  • Currently, most kernels are not statically linked and loaded, but instead dynamically linked in kernel modules and drivers at run time to provide functionality and/or support as needed. When a program is compiled statically, the kernel modules can be validated against one another as they are loaded. However, with current dynamic loading, most of the information that would have been present at a static loading build time is not present at a run time of the dynamic loading.
  • Therefore, dynamically-loaded kernels are vulnerable to problems where shared objects or understanding of object contents can differ between modules. Currently, no automated checking is done between these shared objects to ensure compatibility. As a system has modules patched or loaded from third-party companies, the potential for incompatible modules increases as there is no ability to cross-check the modules because the vendors are not privy to one another's module construction. When an incompatibility does occur, it can cause data corruption, system crashes, and other negative consequences. An attempt could be made to find the problems. Yet, this requires expert analysis of all involved modules and some luck in finding the problem. Time has shown that problems like this occur with frequency and are nearly impossible to diagnose.
  • SUMMARY OF INVENTION
  • The present invention includes novel methods and apparatus for kernel module compatibility validation.
  • According to one embodiment of the invention, a method is disclosed. The method includes maintaining a data structure in a kernel module that identifies information related to a system including the kernel module, the information to be manipulated by the kernel module, comparing, by a kernel in the system that loads the kernel module, the data structure of the kernel module with one or more other data structures of kernel modules the kernel loads, and performing, by the kernel, an error routine if an incompatibility is found between the data structure and the one or more other data structures.
  • According to another embodiment of the invention, an apparatus is disclosed. The apparatus includes a processor and a memory unit coupled to the processor including instructions to execute a kernel. The kernel is further to initialize a kernel module to maintain a data structure that identifies information related to a system, the information to be manipulated by the kernel module, compare the data structure of the kernel module with one or more other data structures of kernel modules the kernel loads, and perform an error routine if an incompatibility is found between the data structure and the one or more other data structures.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The invention may be best understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the invention. In the drawings:
  • FIG. 1 is a block diagram of one embodiment of various functional units involved in interfacing application programs to system devices;
  • FIG. 2A is a block diagram illustrating one embodiment of a module data structure;
  • FIG. 2B is a block diagram illustrating one embodiment of an updated module data structure;
  • FIG. 3 is a flow diagram illustrating a method according to one embodiment of the invention; and
  • FIG. 4 is an illustration of an embodiment of a computer system.
  • DETAILED DESCRIPTION
  • A method and apparatus are described for kernel module compatibility validation. According to one embodiment, the method includes maintaining a data structure in a kernel module that identifies information related to a system including the kernel module, the information to be manipulated by the kernel module, comparing, by a kernel in the system that loads the kernel module, the data structure of the kernel module with one or more other data structures of kernel modules the kernel loads, and performing, by the kernel, an error routine if an incompatibility is found between the data structure and the one or more other data structures.
  • In the following description, numerous details are set forth. It will be apparent, however, to one skilled in the art that embodiments of the present invention may be practiced without these specific details. In other instances, well-known structures, devices, and techniques have not been shown in detail, in order to avoid obscuring the understanding of the description. The description is thus to be regarded as illustrative instead of limiting.
  • Reference in the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least an embodiment of the invention. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment.
  • Also, select embodiments of the present invention include various operations, which are described herein. The operations of the embodiments of the present invention may be performed by hardware components or may be embodied in machine-executable instructions, which may be in turn utilized to cause a general-purpose or special-purpose processor, or logic circuits programmed with the instructions, to perform the operations. Alternatively, the operations may be performed by a combination of hardware and software.
  • Moreover, embodiments of the present invention may be provided as computer program products, which may include machine-readable medium having stored thereon instructions used to program a computer (or other electronic devices) to perform a process according to embodiments of the present invention. The machine-readable medium may include, but is not limited to, floppy diskettes, hard disk, optical disks, CD-ROMs, and magneto-optical disks, read-only memories (ROMs), random-access memories (RAMs), erasable programmable ROMs (EPROMs), electrically EPROMs (EEPROMs), magnetic or optical cards, flash memory, or other types of media or machine-readable medium suitable for storing electronic instructions and/or data. Moreover, data discussed herein may be stored in a single database, multiple databases, or otherwise in select forms (such as in a table).
  • Additionally, embodiments of the present invention may be downloaded as a computer program product, wherein the program may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., a modem or network connection). Accordingly, herein, a carrier wave shall be regarded as comprising a machine-readable medium.
  • Embodiments of the invention introduce a novel method to implement kernel module compatibility validation. The kernel module compatibility validation prevents conflicting kernel modules from being loaded together. At the least, the compatibility validation identifies conflicts as early as possible so that they can be remedied. This reduces, or possibly eliminates, conflicts that exist in running kernels, thereby increasing reliability and improving uptime of systems.
  • FIG. 1 is a block diagram illustrating various functional units involved in interfacing application programs to various system devices. Reference numeral 100 generally indicates a functional unit involved in interfacing application packages or programs to devices in a computer system. The unit 100 includes various applications 120, a shell 140, a kernel 160, kernel modules 180, and various hardware devices or peripherals 190.
  • The applications 120 typically include a word processor, a spreadsheet program, a web browser, or any other application that may be run on a computer system. The various applications 120 use common hardware on the computer system and, accordingly, an interface should be provided between the various different applications and each hardware or peripheral device 190. This interface is provided by the kernel 160 that interacts with the applications 120 via the shell 140 and with the devices 190. In addition, some devices 190 may also be interacted with via the kernel modules 180.
  • The kernel 160 defines the heart of an operating system, such as a UNIX-based operating system. Under control of the kernel 160, the shell 140 interprets user commands of the application programs 120 whereupon the kernel 160 exports various application program interfaces (APIs) to the relevant devices 190 for execution.
  • In some cases, a device 190 may be viewed as a file system and the kernel modules 180 accordingly communicate data in a binary format to the file system interface via specific APIs. Accordingly, each kernel module 180 is typically configured for the specific hardware that it drives and, since the kernel module 180 obtains its commands from the kernel 160, the kernel module 180 and the kernel 160 should be configured to function with each other.
  • FIG. 2A is a block diagram illustrating a data structure that may be included in a kernel module according to embodiments of the invention. In one embodiment, the kernel module including the data structure may be the same as kernel module 180 described with respect to FIG. 1. In some embodiments, data structure 200 corresponds to information about various components, such as a storage disk, that contain data which the kernel module may manipulate.
  • In one embodiment, data structure 200 includes information such as field name 210, type 220, size 230, and offset 240. Data structure 200 may include various fields 210, such as vendor 250, size 260, bytes read 270, and bytes written 280. The type 220 information identifies the actual data type of the field (e.g., array, integer, floating point, etc.). The offset 240 identifies the storage location in the physical memory for the specific field 210.
  • For example, the vendor 250 field 210 of the data structure 200 includes a type 220 of an array of 80 characters, a size 230 of 80B, and an offset 240 of 0. The other fields 210 of the data structure 200 contain corresponding information for the specific fields. This information may be used by the kernel module for debugging purposes, and, as described below, for compatibility validation with other modules.
  • In some cases, changes may be made to the disk so that the information contained in the data structures 200 of various kernel modules is no longer correct. For instance, the size 230 of a field 210 may be increased or decreased. In some cases, additional information may be added or deleted from the disk. These changes may lead to incorrect information being stored in data structures 200 of kernel modules. For example, a change in the size 230 information for a field 210 may affect the offset 240 information for other fields 210 following the affected field 210 on the disk. FIG. 2B provides an example of such a situation.
  • FIG. 2B is a block diagram illustrating an updated data structure 205 of a kernel module after a change has been made to a component of the kernel module. Data structure 205 is the updated version of data structure 200. In one embodiment, it may be assumed that a component being manipulated by the kernel module has been altered so that an additional field 210 has been added. This new field 210 is geometry information 290 (i.e., number of platters). The geometry field 290 includes a type 220 of integer, a size 230 of 4 B, and an offset of 84. Furthermore, the size 230 of the bytes read information 270 has been increased from 4B to 8B.
  • In order for the kernel module to operate and interact correctly, the kernel module should include an updated data structure similar to data structure 205. In FIG. 2B, the same information as that included in data structure 200 of FIG. 2A is present, with the addition of the geometry information 290. Furthermore, the size 230 of the bytes read information 270 was increased to 8B. As can be seen, the addition of the geometry information 290 affects the offsets 240 of both the bytes read 270 and bytes written 280 information. Also, the size 230 of the bytes read information 270 affects the offset 240 of the bytes written information 280.
  • If a kernel module is unaware of these component modifications, it would be loaded with old data structure 200 of FIG. 2A. Operating with this incorrect data structure 200 may cause potentially devastating effects to the operation of the kernel, as well as to the system that the kernel is operating with. In one embodiment, it may cause data that the kernel module believed to be part of the bytes read 270 field of memory to be manipulated, which would actually affect the geometry field 290 of the updated module. Depending on the data being actually manipulated, this could lead to system crashes and other negative effects.
  • FIG. 3 is a flow diagram illustrating a method according to one embodiment of the invention. Process 300 addresses the potential for incompatible data structures in kernel modules. Process 300 begins at processing block 310, where a kernel module maintains a data structure that identifies information related to a system that the kernel module operates on. The information contained in the data structure may potentially be manipulated by the kernel module. In one embodiment, this data structure is the same as data structure 200 or 205 illustrated with respect to FIGS. 2A and 2B.
  • Then, at processing block 320, the kernel initializes the kernel module on the system. At processing block 330, the kernel compares the kernel module's data structure with all other data structures of kernel modules running on the system for incompatibilities. In some embodiments, this comparison includes matching the field names, types, sizes, and offsets of the information included in the data structures. For example, if an offset of a particular field in the data structure of kernel module being tested does not match an offset of the same field in another kernel module, then an incompatibility has occurred.
  • In some embodiments, it is envisioned that a signature or checksum may be utilized for the compatibility validation. Furthermore, a subset of the various components of a data structure may be compared, instead of comparing the complete set of components, in order to save time in the compatibility validation.
  • At decision block 340 it is determined whether there are any incompatibilities present between kernel modules. If so, then at processing block 350, the kernel runs an error routine to address the incompatibility.
  • In one embodiment, this error routine may include generating an error message identifying the incompatibility. In another embodiment, the error routine may include correcting the incompatibility in the kernel module being initialized in order to make the data structure compatible with the updated component structure. In other embodiments, the error routine may include refusing to load the kernel module. The error routine may also be some combination of all of these embodiments. If no incompatibilities are found, then at processing block 360 the kernel module is loaded in a normal fashion.
  • In some embodiments, the compatibility validation may occur at the time of system boot-up. It may also occur any time a kernel module is initialized. It is further envisioned that the compatibility validation may occur after the system is fully-booted, so that a cross-check of all the module information may take place while the system is still live. This may be done on-demand or at a scheduled time.
  • In some embodiments, the compatibility validation may occur after a system crash occurs. For example, a tool may be run to analyze the kernel and kernel module memory and determine whether there are any kernel module incompatibilities. One skilled in the art will appreciate the variety of implementations possible for the compatibility validation.
  • FIG. 4 illustrates an exemplary computer system 400 in which certain embodiments of the present invention may be implemented. In one embodiment, the components of FIG. 1 may be implemented as system 400 or as components of system 400.
  • System 400 comprises a central processor 402, a main memory 404, an input/output (I/O) controller 406, a keyboard 408, a pointing device 410 (e.g., mouse, track ball, pen device, or the like), a display device 412, a mass storage 414 (e.g., a nonvolatile storage such as a hard disk, an optical drive, and the like), and a network interface 418. Additional input/output devices, such as a printing device 416, may be included in the system 400 as desired. As illustrated, the various components of the system 400 communicate through a system bus 420 or similar architecture.
  • In a further embodiment, system 400 may be a distributed computing system. In other words, one or more of the various components of the system 400 may be located in a physically separate location than the other components of the system 400. Such components may be accessed and connected via a network to the other components
  • In accordance with an embodiment of the present invention, the computer system 400 includes a Sun Microsystems computer utilizing a SPARC microprocessor available from several vendors (including Sun Microsystems, Inc., of Santa Clara, Calif.). Those with ordinary skill in the art understand, however, that any type of computer system may be utilized to embody the present invention, including those made by Hewlett Packard of Palo Alto, Calif., and IBM-compatible personal computers utilizing Intel microprocessor, which are available from several vendors (including IBM of Armonk, N.Y.).
  • Also, instead of a single processor, two or more processors (whether on a single chip or on separate chips) can be utilized to provide speedup in operations. It is further envisioned that the processor 402 may be a complex instruction set computer (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, a processor implementing a combination of instruction sets, and the like.
  • The network interface 418 provides communication capability with other computer systems on a same local network, on a different network connected via modems and the like to the present network, or to other computers across the Internet. In various embodiments of the present invention, the network interface 418 can be implemented utilizing technologies including, but not limited to, Ethernet, Fast Ethernet, Gigabit Ethernet (such as that covered by the Institute of Electrical and Electronics Engineers (IEEE) 801.1 standard), wide-area network (WAN), leased line (such as T1, T3, optical carrier 3 (OC3), and the like), analog modem, digital subscriber line (DSL and its varieties such as high bit-rate DSL (HDSL), integrated services digital network DSL (IDSL), and the like), cellular, wireless networks (such as those implemented by utilizing the wireless application protocol (WAP)), time division multiplexing (TDM), universal serial bus (USB and its varieties such as USB II), asynchronous transfer mode (ATM), satellite, cable modem, and/or FireWire.
  • Moreover, the computer system 400 may utilize operating systems such as Solaris, Windows (and its varieties such as CE, NT, 2000, XP, ME, and the like), HP-UX, IBM-AIX, PALM, UNIX, Berkeley software distribution (BSD) UNIX, Linux, Apple UNIX (AUX), Macintosh operating system (Mac OS) (including Mac OS X), and the like. Also, it is envisioned that in certain embodiments of the present invention, the computer system 400 is a general purpose computer capable of running any number of applications such as those available from companies including Oracle, Siebel, Unisys, Microsoft, and the like.
  • It should be appreciated that in the foregoing description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure aiding in the understanding of one or more of the various inventive aspects. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the detailed description are hereby expressly incorporated into this detailed description, with each claim standing on its own as a separate embodiment of this invention.
  • The foregoing description has been directed to specific embodiments. It will be apparent to those with ordinary skill in the art that modifications may be made to the described embodiments, with the attainment of all or some of the advantages. Therefore, it is the object of the appended claims to cover all such variations and modifications as come within the spirit and scope of the invention.

Claims (20)

1. A method comprising:
maintaining a data structure in a kernel module that identifies information related to a system including the kernel module, the information to be manipulated by the kernel module;
comparing, by a kernel in the system that loads the kernel module, the data structure of the kernel module with one or more other data structures of kernel modules the kernel loads; and
performing, by the kernel, an error routine if an incompatibility is found between the data structure and the one or more other data structures.
2. The method of claim 1, wherein the comparing is performed when the kernel module is initialized by the kernel.
3. The method of claim 1, wherein the comparing is performed upon the boot-up of the system.
4. The method of claim 1, wherein the comparing is performed upon a failure of the system.
5. The method of claim 1, wherein the comparing is performed while the system is fully booted upon at least one of an on-demand request or a scheduled time.
6. The method of claim 1, wherein the error routine includes at least one of refusing to initialize the kernel module, indicating by the kernel the incompatibility to the system, and correcting the incompatibility in the kernel module.
7. The method of claim 1, wherein the data structure stores at least one of a field name, type, size, and offset of the information to be manipulated by the kernel module.
8. The method of claim 7, wherein the incompatibility is found when there is a mismatch between at least one of the field names, types, sizes, or offsets of the same information between the data structure and the one or more other data structures.
9. The method of claim 1, wherein at least one of a signature and a checksum is utilized for the comparing the data structure with the one or more other data structures.
10. An article of manufacture, comprising a machine-accessible medium including data that, when accessed by a machine, cause the machine to perform operations comprising:
maintaining a data structure in a kernel module of a system, the data structure identifying at least one of a field name, type, size, and offset of information to be manipulated by the kernel module;
comparing, by a kernel in the system that loads the kernel module, the data structure of the kernel module with one or more other data structures of kernel modules the kernel loads; and
performing, by the kernel, an error routine if an incompatibility is found between the data structure and the one or more other data structures.
11. The article of manufacture of claim 10, wherein the comparing is performed when the kernel module is initialized by the kernel.
12. The article of manufacture of claim 10, wherein the comparing is performed upon the boot-up of the system.
13. The article of manufacture of claim 10, wherein the comparing is performed upon a failure of the system.
14. The article of manufacture of claim 10, wherein the comparing is performed while the system is fully booted upon at least one of an on-demand request or a scheduled time.
15. The article of manufacture of claim 10, wherein the error routine includes at least one of indicating the incompatibility to the system, refusing to initialize the kernel module, and correcting the incompatibility in the kernel module.
16. The article of manufacture of claim 10, wherein the incompatibility is found when there is a mismatch between at least one of the field names, types, sizes, or offsets of the same information between the data structure and the one or more other data structures.
17. An apparatus, comprising:
a processor; and
a memory unit coupled to the processor including instructions to execute a kernel, the kernel to:
initialize a kernel module to maintain a data structure that identifies information related to a system, the information to be manipulated by the kernel module;
compare the data structure of the kernel module with one or more other data structures of kernel modules the kernel loads; and
perform an error routine if an incompatibility is found between the data structure and the one or more other data structures.
18. The apparatus of claim 17, wherein the comparing is performed at least at one of when the kernel module is initialized by the kernel, upon the boot-up of the system, upon a failure of the system, and while the system is fully booted upon at least one of an on-demand request or a scheduled time.
19. The apparatus of claim 17, wherein the error routine includes at least one of refusing to initialize the kernel module, indicating the incompatibility to the system, and correcting the incompatibility in the kernel module.
20. The apparatus of claim 17, wherein the data structure stores at least one of a field name, type, size, and offset of the information to be manipulated by the kernel module.
US11/365,278 2006-03-01 2006-03-01 Kernel module compatibility validation Active 2027-06-05 US7581141B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/365,278 US7581141B2 (en) 2006-03-01 2006-03-01 Kernel module compatibility validation

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US11/365,278 US7581141B2 (en) 2006-03-01 2006-03-01 Kernel module compatibility validation

Publications (2)

Publication Number Publication Date
US20070220343A1 true US20070220343A1 (en) 2007-09-20
US7581141B2 US7581141B2 (en) 2009-08-25

Family

ID=38519388

Family Applications (1)

Application Number Title Priority Date Filing Date
US11/365,278 Active 2027-06-05 US7581141B2 (en) 2006-03-01 2006-03-01 Kernel module compatibility validation

Country Status (1)

Country Link
US (1) US7581141B2 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070239740A1 (en) * 2006-04-11 2007-10-11 Sajjit Thampy Method and apparatus for detecting a change-point in a time-series of computer telemetry signals
US20120221890A1 (en) * 2011-02-24 2012-08-30 Kushal Das Mechanism for managing kernel application binary interface/application programming interface-based discrepancies relating to kernel packages
KR20190039279A (en) * 2017-02-22 2019-04-10 바이두 온라인 네트웍 테크놀러지 (베이징) 캄파니 리미티드 Kernel module loading methods and devices
US20220147636A1 (en) * 2020-11-12 2022-05-12 Crowdstrike, Inc. Zero-touch security sensor updates
US11461465B1 (en) * 2019-05-24 2022-10-04 Trend Micro Inc. Protection of kernel extension in a computer

Citations (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5734822A (en) * 1995-12-29 1998-03-31 Powertv, Inc. Apparatus and method for preprocessing computer programs prior to transmission across a network
US5815707A (en) * 1995-10-19 1998-09-29 Hewlett-Packard Company Dynamic function replacement for streams framework
US6047323A (en) * 1995-10-19 2000-04-04 Hewlett-Packard Company Creation and migration of distributed streams in clusters of networked computers
US20020023211A1 (en) * 2000-06-09 2002-02-21 Steven Roth Dynamic kernel tunables
US20020188730A1 (en) * 2001-06-12 2002-12-12 Wenting Tang Method and system for a modular transmission control protocol (TCP) frequent-handoff design in a streams based transmission control protocol internet protocol (TCP/IP) implementation
US6526523B1 (en) * 1998-10-27 2003-02-25 Microsoft Corporation Kernel streaming test method and system
US20030072318A1 (en) * 2001-09-14 2003-04-17 Nokia Inc. System and method for packet forwarding
US20030074551A1 (en) * 2001-10-12 2003-04-17 Aswin Chandramouleeswaran Methods for changing kernel tuning parameters
US20030074604A1 (en) * 2001-10-12 2003-04-17 Mathias Daniel R. Method and apparatus for kernel module testing
US20030097581A1 (en) * 2001-09-28 2003-05-22 Zimmer Vincent J. Technique to support co-location and certification of executable content from a pre-boot space into an operating system runtime environment
US20030120935A1 (en) * 2001-12-20 2003-06-26 Coretrace Corporation Kernel-based network security infrastructure
US20030145235A1 (en) * 2001-01-31 2003-07-31 Choo Tse Huong Network adapter management
US20040054946A1 (en) * 2002-09-18 2004-03-18 Dario Atallah System and method for assessing compatibility risk
US20040093359A1 (en) * 2002-11-12 2004-05-13 Sharpe Edward J. Methods and apparatus for updating file systems
US6745346B2 (en) * 2000-12-08 2004-06-01 Intel Corporation Method for efficiently identifying errant processes in a computer system by the operating system (OS) for error containment and error recovery
US20040199817A1 (en) * 2003-03-20 2004-10-07 Sun Microsystems, Inc. Fault tolerance using digests
US20040221275A1 (en) * 2002-04-17 2004-11-04 Thomas Handal Apparatus and method for modifying a kernel module to run on multiple kernel versions
US20050071856A1 (en) * 2003-09-26 2005-03-31 Kumar C.P. Vijay Dynamically loadable stub modules
US20050081220A1 (en) * 2003-09-26 2005-04-14 Victor Yodaiken Systems and methods for dynamically linking application software into a running operating system kernel
US6889167B2 (en) * 2003-02-27 2005-05-03 Hewlett-Packard Development Company, L.P. Diagnostic exerciser and methods therefor
US6950964B1 (en) * 2002-03-22 2005-09-27 Microsoft Corporation Driver protection
US20060075299A1 (en) * 2004-09-21 2006-04-06 Aswin Chandramouleeswaran Moving kernel configurations
US7028229B2 (en) * 2002-09-30 2006-04-11 Sun Microsystems, Inc. Kernel event subscription and publication system and method
US20060101263A1 (en) * 2004-11-08 2006-05-11 Microsoft Corporation System and method of allowing user mode applications with access to file data
US20060112241A1 (en) * 2004-11-24 2006-05-25 Yoav Weiss System, method and apparatus of securing an operating system
US7058968B2 (en) * 2001-01-10 2006-06-06 Cisco Technology, Inc. Computer security and management system
US20060174229A1 (en) * 2005-02-03 2006-08-03 Muser Carol P Methods and tools for executing and tracing user-specified kernel instructions
US7146611B1 (en) * 2003-02-24 2006-12-05 Hewlett-Packard Development Company, L.P. Method and system for managing memory for software modules
US20070006045A1 (en) * 2005-06-30 2007-01-04 International Business Machines Corporation Method and apparatus for object-oriented load testing of computing systems
US20070022287A1 (en) * 2005-07-15 2007-01-25 Microsoft Corporation Detecting user-mode rootkits
US20070079178A1 (en) * 2005-10-05 2007-04-05 Computer Associates Think, Inc. Discovery of kernel rootkits by detecting hidden information
US7216369B2 (en) * 2002-06-28 2007-05-08 Intel Corporation Trusted platform apparatus, system, and method
US7401359B2 (en) * 2001-12-21 2008-07-15 Mcafee, Inc. Generating malware definition data for mobile computing devices

Patent Citations (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5815707A (en) * 1995-10-19 1998-09-29 Hewlett-Packard Company Dynamic function replacement for streams framework
US6047323A (en) * 1995-10-19 2000-04-04 Hewlett-Packard Company Creation and migration of distributed streams in clusters of networked computers
US5734822A (en) * 1995-12-29 1998-03-31 Powertv, Inc. Apparatus and method for preprocessing computer programs prior to transmission across a network
US6526523B1 (en) * 1998-10-27 2003-02-25 Microsoft Corporation Kernel streaming test method and system
US20020023211A1 (en) * 2000-06-09 2002-02-21 Steven Roth Dynamic kernel tunables
US6745346B2 (en) * 2000-12-08 2004-06-01 Intel Corporation Method for efficiently identifying errant processes in a computer system by the operating system (OS) for error containment and error recovery
US7058968B2 (en) * 2001-01-10 2006-06-06 Cisco Technology, Inc. Computer security and management system
US20030145235A1 (en) * 2001-01-31 2003-07-31 Choo Tse Huong Network adapter management
US20020188730A1 (en) * 2001-06-12 2002-12-12 Wenting Tang Method and system for a modular transmission control protocol (TCP) frequent-handoff design in a streams based transmission control protocol internet protocol (TCP/IP) implementation
US20030072318A1 (en) * 2001-09-14 2003-04-17 Nokia Inc. System and method for packet forwarding
US20030097581A1 (en) * 2001-09-28 2003-05-22 Zimmer Vincent J. Technique to support co-location and certification of executable content from a pre-boot space into an operating system runtime environment
US6978018B2 (en) * 2001-09-28 2005-12-20 Intel Corporation Technique to support co-location and certification of executable content from a pre-boot space into an operating system runtime environment
US20030074551A1 (en) * 2001-10-12 2003-04-17 Aswin Chandramouleeswaran Methods for changing kernel tuning parameters
US20030074604A1 (en) * 2001-10-12 2003-04-17 Mathias Daniel R. Method and apparatus for kernel module testing
US6950962B2 (en) * 2001-10-12 2005-09-27 Hewlett-Packard Development Company, L.P. Method and apparatus for kernel module testing
US7143281B2 (en) * 2001-10-12 2006-11-28 Hewlett-Packard Development Company, L.P. Method and apparatus for automatically changing kernel tuning parameters
US20030120935A1 (en) * 2001-12-20 2003-06-26 Coretrace Corporation Kernel-based network security infrastructure
US7401359B2 (en) * 2001-12-21 2008-07-15 Mcafee, Inc. Generating malware definition data for mobile computing devices
US7284157B1 (en) * 2002-03-22 2007-10-16 Microsoft Corporation Faulty driver protection comparing list of driver faults
US6950964B1 (en) * 2002-03-22 2005-09-27 Microsoft Corporation Driver protection
US20040221275A1 (en) * 2002-04-17 2004-11-04 Thomas Handal Apparatus and method for modifying a kernel module to run on multiple kernel versions
US7076770B2 (en) * 2002-04-17 2006-07-11 Computer Associates Think, Inc. Apparatus and method for modifying a kernel module to run on multiple kernel versions
US7216369B2 (en) * 2002-06-28 2007-05-08 Intel Corporation Trusted platform apparatus, system, and method
US7069474B2 (en) * 2002-09-18 2006-06-27 Sun Microsystems, Inc. System and method for assessing compatibility risk
US20040054946A1 (en) * 2002-09-18 2004-03-18 Dario Atallah System and method for assessing compatibility risk
US7028229B2 (en) * 2002-09-30 2006-04-11 Sun Microsystems, Inc. Kernel event subscription and publication system and method
US20040093359A1 (en) * 2002-11-12 2004-05-13 Sharpe Edward J. Methods and apparatus for updating file systems
US7146611B1 (en) * 2003-02-24 2006-12-05 Hewlett-Packard Development Company, L.P. Method and system for managing memory for software modules
US6889167B2 (en) * 2003-02-27 2005-05-03 Hewlett-Packard Development Company, L.P. Diagnostic exerciser and methods therefor
US20040199817A1 (en) * 2003-03-20 2004-10-07 Sun Microsystems, Inc. Fault tolerance using digests
US20050081220A1 (en) * 2003-09-26 2005-04-14 Victor Yodaiken Systems and methods for dynamically linking application software into a running operating system kernel
US20050071856A1 (en) * 2003-09-26 2005-03-31 Kumar C.P. Vijay Dynamically loadable stub modules
US20060075299A1 (en) * 2004-09-21 2006-04-06 Aswin Chandramouleeswaran Moving kernel configurations
US20060101263A1 (en) * 2004-11-08 2006-05-11 Microsoft Corporation System and method of allowing user mode applications with access to file data
US20060112241A1 (en) * 2004-11-24 2006-05-25 Yoav Weiss System, method and apparatus of securing an operating system
US20060174229A1 (en) * 2005-02-03 2006-08-03 Muser Carol P Methods and tools for executing and tracing user-specified kernel instructions
US20070006045A1 (en) * 2005-06-30 2007-01-04 International Business Machines Corporation Method and apparatus for object-oriented load testing of computing systems
US20070022287A1 (en) * 2005-07-15 2007-01-25 Microsoft Corporation Detecting user-mode rootkits
US20070079178A1 (en) * 2005-10-05 2007-04-05 Computer Associates Think, Inc. Discovery of kernel rootkits by detecting hidden information

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070239740A1 (en) * 2006-04-11 2007-10-11 Sajjit Thampy Method and apparatus for detecting a change-point in a time-series of computer telemetry signals
US7542995B2 (en) * 2006-04-11 2009-06-02 Sun Microsystems, Inc. Method and apparatus for detecting a change-point in a time-series of computer telemetry signals
US20120221890A1 (en) * 2011-02-24 2012-08-30 Kushal Das Mechanism for managing kernel application binary interface/application programming interface-based discrepancies relating to kernel packages
US10394551B2 (en) * 2011-02-24 2019-08-27 Red Hat, Inc. Managing kernel application binary interface/application programming interface-based discrepancies relating to kernel packages
KR20190039279A (en) * 2017-02-22 2019-04-10 바이두 온라인 네트웍 테크놀러지 (베이징) 캄파니 리미티드 Kernel module loading methods and devices
KR102244281B1 (en) 2017-02-22 2021-04-23 바이두 온라인 네트웍 테크놀러지 (베이징) 캄파니 리미티드 Kernel module loading method and device
US11237844B2 (en) * 2017-02-22 2022-02-01 Baidu Online Network Technology (Beijing) Co., Ltd. Method and apparatus for loading kernel module
US11461465B1 (en) * 2019-05-24 2022-10-04 Trend Micro Inc. Protection of kernel extension in a computer
US20220147636A1 (en) * 2020-11-12 2022-05-12 Crowdstrike, Inc. Zero-touch security sensor updates

Also Published As

Publication number Publication date
US7581141B2 (en) 2009-08-25

Similar Documents

Publication Publication Date Title
US7103641B2 (en) Method and apparatus for distributing computer platform firmware across a network
US6725178B2 (en) Use of hidden partitions in a storage device for storing BIOS extension files
US7934209B2 (en) Method for firmware variable storage with eager compression, fail-safe extraction and restart time compression scan
US8086833B2 (en) Method and system for linking firmware modules in a pre-memory execution environment
US7243347B2 (en) Method and system for maintaining firmware versions in a data processing system
US7577832B2 (en) Apparatus and method for booting a system
US7111202B2 (en) Autonomous boot failure detection and recovery
US7640426B2 (en) Methods and apparatus to manage hardware resources for a partitioned platform
US7660913B2 (en) Out-of-band platform recovery
US6591417B1 (en) Method of and system for testing compatibility with an external API upgrade
US7392371B2 (en) Method and apparatus for using a volume top file to boot firmware modules
US7487345B2 (en) Method of comparing build capability flags of replacement BIOS with boot capability flags of current BIOS to determine compatibility between BIOS revisions and installed hardware during flash update
US20080209193A1 (en) Manageability Extension Mechanism for System Firmware
US11334427B2 (en) System and method to reduce address range scrub execution time in non-volatile dual inline memory modules
US8539214B1 (en) Execution of a program module within both a PEI phase and a DXE phase of an EFI firmware
US7581141B2 (en) Kernel module compatibility validation
US11429298B2 (en) System and method for tying non-volatile dual inline memory modules to a particular information handling system
US6961848B2 (en) System and method for supporting legacy operating system booting in a legacy-free system
US20030188146A1 (en) Method of ordered execution of firmware modules in a pre-memory execution environment
US20200364040A1 (en) System and Method for Restoring a Previously Functional Firmware Image on a Non-Volatile Dual Inline Memory Module
US8078637B1 (en) Memory efficient peim-to-peim interface database
US7266678B2 (en) Dynamic configuration of computer when booting
US11907071B2 (en) Storage failover protocol for secure and seamless extended firmware load
US20230267045A1 (en) System on a chip-agnostic dynamic firmware volumes for basic input/output extension

Legal Events

Date Code Title Description
AS Assignment

Owner name: SUN MICROSYTEMS, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HARRES, JOHN M.;REEL/FRAME:017642/0770

Effective date: 20060228

FEPP Fee payment procedure

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

STCF Information on status: patent grant

Free format text: PATENTED CASE

FPAY Fee payment

Year of fee payment: 4

AS Assignment

Owner name: ORACLE AMERICA, INC., CALIFORNIA

Free format text: MERGER AND CHANGE OF NAME;ASSIGNORS:ORACLE USA, INC.;SUN MICROSYSTEMS, INC.;ORACLE AMERICA, INC.;REEL/FRAME:039888/0635

Effective date: 20100212

FPAY Fee payment

Year of fee payment: 8

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 12TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1553); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 12