Non-Volatile Driver Store Update Coordination

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing security systems face challenges in updating device drivers without causing system reboots, leading to downtime and reduced protection against cybersecurity threats during the update process, especially when multiple components need to be updated simultaneously.

Innovation Solution

The implementation of a method that allows for the installation and updating of PnP drivers without triggering OS interactions like reboot notifications, enabling interfacing between PnP and non-PnP drivers with versioning to minimize interruptions, and coordinating updates to apply all changes in a single reboot, while maintaining protection between updates and reboots.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If device drivers are updated in the operating system, then security protection against cybersecurity threats is improved, but system downtime increases due to required reboots

Engineering Contradiction:
Improvesecurity protectionVSAvoidsystem downtime
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent stages driver updates in advance within the driver store before they take effect. Drivers are prepared and validated beforehand, allowing the system to apply multiple updates simultaneously during a single reboot window, thus reducing total downtime while maintaining security.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent combines multiple driver updates into a single reboot operation. Instead of requiring separate reboots for each driver update, the system coordinates and applies all staged updates together, merging what would be multiple downtime periods into one consolidated update window.

Inventive Principle:
Principle #5Merging (Combining)

2Productivity

If multiple device components are updated simultaneously, then productivity is improved by reducing update frequency, but system complexity increases due to coordination requirements

Engineering Contradiction:
Improveupdate efficiencyVSAvoidupdate coordination
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent implements dynamic update coordination where the system adaptively manages multiple driver updates based on their interdependencies. The update coordinator dynamically determines the optimal sequence and timing for applying updates, adjusting to system state and update requirements rather than following a fixed process.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The patent introduces an update coordinator as an intermediary component that manages the complex coordination of multiple driver updates. This mediator component orchestrates the staging, validation, and application of updates across multiple drivers, simplifying the complexity by centralizing coordination logic.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Productivity

If device drivers are updated without reboots, then system availability is improved, but driver installation reliability deteriorates due to OS interaction requirements

Engineering Contradiction:
Improvesystem availabilityVSAvoiddriver installation
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The patent segments the driver update process into distinct phases: staging (before reboot), validation (after reboot), and application (during/after reboot). This segmentation allows the system to prepare updates while maintaining availability, then ensure reliable installation during the controlled reboot window, separating availability-critical operations from installation-critical operations.

Inventive Principle:
Principle #1Segmentation

Data Source

PatentEP3514717B1Device driver non-volatile backing-store installation
Publication Date: 2021.03.31 CROWDSTRIKE
  • EP3514717B1 patent drawingFigure 1
  • EP3514717B1 patent drawingFigure 2
  • EP3514717B1 patent drawingFigure 3

AI summary

In some examples, a processing unit can install a second driver to an installed-driver backing store on a non-volatile (nonV) memory, and replace a first driver in a driver store of the nonV memory with the second driver without replacing the first driver in the volatile memory with the second driver. The processing unit can, subsequently, determine that the second driver has been loaded into the volatile memory, and write, by the second driver loaded into the volatile memory, a driver-configuration entry in a configuration datastore. An example computing system can include the first driver in volatile memory, and the nonV memory. The nonV memory can include a driver-configuration file, a driver store holding a first copy of the second driver, and an installed-driver backing store holding a second copy of the second driver. Some examples can roll back failed installation operations.