Abstract: Drivers in different functional paths can use different types of identifiers for the same hardware device, such that the drivers may not be able to natively coordinate their actions related to the hardware device due to incompatible identifier types. However, a driver at a file system layer of one functional path can obtain a volume Physical Device Object (PDO) identifier at a volume layer and find a disk PDO identifier at a disk layer that is associated with the same device number. The driver can also find a parent device instance identifier from the disk PDO identifier, and use the parent device instance identifier as a plug-and-play (PnP) identifier for the hardware device during communications with a second driver in a PnP functional path.

Abstract: A computing device can install and execute a kernel-level security agent that interacts with a remote security system as part of a detection loop aimed at defeating malware attacks. The kernel-level security agent can be installed with a firewall policy that can be remotely enabled by the remote security system in order to “contain” the computing device. Accordingly, when the computing device is being used, and a malware attack is detected on the computing device, the remote security system can send an instruction to contain the computing device, which causes the implementation, by an operating system (e.g., a Mac™ operating system) of the computing device, of the firewall policy accessible to the kernel-level security agent. Upon implementation and enforcement of the firewall policy, outgoing data packets from, and incoming data packets to, the computing device that would have been allowed prior to the implementation of the firewall policy are denied.

Abstract: 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.

Abstract: Drivers in different functional paths can use different types of identifiers for the same hardware device, such that the drivers may not be able to natively coordinate their actions related to the hardware device due to incompatible identifier types. However, a driver at a file system layer of one functional path can obtain a volume Physical Device Object (PDO) identifier at a volume layer and find a disk PDO identifier at a disk layer that is associated with the same device number. The driver can also find a parent device instance identifier from the disk PDO identifier, and use the parent device instance identifier as a plug-and-play (PnP) identifier for the hardware device during communications with a second driver in a PnP functional path.

Abstract: Drivers in different functional paths can use different types of identifiers for the same hardware device, such that the drivers may not be able to natively coordinate their actions related to the hardware device due to incompatible identifier types. However, a driver at a file system layer of one functional path can obtain a volume Physical Device Object (PDO) identifier at a volume layer and find a disk PDO identifier at a disk layer that is associated with the same device number. The driver can also find a parent device instance identifier from the disk PDO identifier, and use the parent device instance identifier as a plug-and-play (PnP) identifier for the hardware device during communications with a second driver in a PnP functional path.

Abstract: A computing device can install and execute a kernel-level security agent that interacts with a remote security system as part of a detection loop aimed at defeating malware attacks. The kernel-level security agent can be installed with a firewall policy that can be remotely enabled by the remote security system in order to “contain” the computing device. Accordingly, when the computing device is being used, and a malware attack is detected on the computing device, the remote security system can send an instruction to contain the computing device, which causes the implementation, by an operating system (e.g., a Mac™ operating system) of the computing device, of the firewall policy accessible to the kernel-level security agent. Upon implementation and enforcement of the firewall policy, outgoing data packets from, and incoming data packets to, the computing device that would have been allowed prior to the implementation of the firewall policy are denied.

Abstract: A computing device can install and execute a kernel-level security agent that interacts with a remote security system as part of a detection loop aimed at defeating malware attacks. The kernel-level security agent can be installed with a firewall policy that can be remotely enabled by the remote security system in order to “contain” the computing device. Accordingly, when the computing device is being used, and a malware attack is detected on the computing device, the remote security system can send an instruction to contain the computing device, which causes the implementation, by an operating system (e.g., a Mac™ operating system) of the computing device, of the firewall policy accessible to the kernel-level security agent. Upon implementation and enforcement of the firewall policy, outgoing data packets from, and incoming data packets to, the computing device that would have been allowed prior to the implementation of the firewall policy are denied.

Abstract: Drivers in different functional paths can use different types of identifiers for the same hardware device, such that the drivers may not be able to natively coordinate their actions related to the hardware device due to incompatible identifier types. However, a driver at a file system layer of one functional path can obtain a volume Physical Device Object (PDO) identifier at a volume layer and find a disk PDO identifier at a disk layer that is associated with the same device number. The driver can also find a parent device instance identifier from the disk PDO identifier, and use the parent device instance identifier as a plug-and-play (PnP) identifier for the hardware device during communications with a second driver in a PnP functional path.

Abstract: 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.

Abstract: A computing device can install and execute a kernel-level security agent that interacts with a remote security system as part of a detection loop aimed at defeating malware attacks. The kernel-level security agent can be installed with a firewall policy that can be remotely enabled by the remote security system in order to “contain” the computing device. Accordingly, when the computing device is being used, and a malware attack is detected on the computing device, the remote security system can send an instruction to contain the computing device, which causes the implementation, by an operating system (e.g., a Mac™ operating system) of the computing device, of the firewall policy accessible to the kernel-level security agent. Upon implementation and enforcement of the firewall policy, outgoing data packets from, and incoming data packets to, the computing device that would have been allowed prior to the implementation of the firewall policy are denied.