Abstract: A storage device failure verification method may include receiving a message from an operating system indicative of an operational failure associated with a storage device. The method may further include determining, responsive to receiving the message from the operating system, whether one or more corrupted sectors are reported by the storage device based upon device diagnostic data received from the storage device. The method may further include determining, responsive to determining that no corrupted sectors are reported by the storage device, a timing value between storage device errors associated with the storage device during a predetermined time window. The method may further include sending a notification indicative of a failure of the storage device based on the timing value being less than a predetermined threshold value.

Abstract: A storage device failure verification method may include receiving a message from an operating system indicative of an operational failure associated with a storage device. The method may further include determining, responsive to receiving the message from the operating system, whether one or more corrupted sectors are reported by the storage device based upon device diagnostic data received from the storage device. The method may further include determining, responsive to determining that no corrupted sectors are reported by the storage device, a timing value between storage device errors associated with the storage device during a predetermined time window. The method may further include sending a notification indicative of a failure of the storage device based on the timing value being less than a predetermined threshold value.

Abstract: A set of root keys is loaded as a first part of a secure boot process of a secure system. a first trusted key from a set of trusted keys is verified using a first root key from the set of root keys as a second part of the secure boot process. The set of trusted keys is loaded when an affirmative verification for a subset of trusted keys is received. The subset of trusted keys includes the first trusted key. As a third part of the secure boot process, an immutable portion of a file is validated using the first trusted key. As a fourth part of the secure boot process, the file is loaded when each portion of the file is successfully validated. The first, second, third, and fourth parts of the secure boot process occur before an integrity management configuration takes over the secure boot process.

Abstract: A computer-implemented method for protecting a kernel for secure boot of an operating system includes preparing a kernel component with a signature for a secure boot. A processing unit modifies a machine owner key (MOK) file to include a trusted certificate. The MOK is separate from the kernel file. The processing unit validates the kernel component using a modified Grub file, a modified Shim file, and the MOK, and executes a secure boot using the validated kernel component. The kernel is unchanged by the secure boot process. The kernel component that is protected may be either a program executable (PE) file or a non-PE file.

Abstract: A computer-implemented method for protecting a kernel for secure boot of an operating system includes preparing a kernel component with a signature for a secure boot. A processing unit modifies a machine owner key (MOK) file to include a trusted certificate. The MOK is separate from the kernel file. The processing unit validates the kernel component using a modified Grub file, a modified Shim file, and the MOK, and executes a secure boot using the validated kernel component. The kernel is unchanged by the secure boot process. The kernel component that is protected may be either a program executable (PE) file or a non-PE file.

Abstract: A set of root keys is loaded as a first part of a secure boot process of a secure system. a first trusted key from a set of trusted keys is verified using a first root key from the set of root keys as a second part of the secure boot process. The set of trusted keys is loaded when an affirmative verification for a subset of trusted keys is received. The subset of trusted keys includes the first trusted key. As a third part of the secure boot process, an immutable portion of a file is validated using the first trusted key. As a fourth part of the secure boot process, the file is loaded when each portion of the file is successfully validated. The first, second, third, and fourth parts of the secure boot process occur before an integrity management configuration takes over the secure boot process.

Abstract: A computer-implemented method for protecting a kernel for secure boot of an operating system includes preparing a kernel component with a signature for a secure boot. A processing unit modifies a machine owner key (MOK) file to include a trusted certificate. The MOK is separate from the kernel file. The processing unit validates the kernel component using a modified Grub file, a modified Shim file, and the MOK, and executes a secure boot using the validated kernel component. The kernel is unchanged by the secure boot process. The kernel component that is protected may be either a program executable (PE) file or a non-PE file.

Abstract: A computer-implemented method for protecting a kernel for secure boot of an operating system includes preparing a kernel component with a signature for a secure boot. A processing unit modifies a machine owner key (MOK) file to include a trusted certificate. The MOK is separate from the kernel file. The processing unit validates the kernel component using a modified Grub file, a modified Shim file, and the MOK, and executes a secure boot using the validated kernel component. The kernel is unchanged by the secure boot process. The kernel component that is protected may be either a program executable (PE) file or a non-PE file.

Abstract: A plurality of processors are connected to the interprocessor communications facility in the multiprocessing system of the invention. The interprocessor communications facility has arbitration circuitry, mailbox circuitry, and processor interrupt circuitry. The interprocessor communications facility of the invention is centralized and does not require the use of main storage. This enables processors to communicate with each other in a fast and efficient manner. The arbitration circuitry prevents simultaneous access of the interprocessor communications facility by more than one processor, and decodes the commands sent from the processors and routes them to the processor interrupt circuitry or to the mailbox circuitry, depending on the command. The mailbox circuitry of the invention receives messages from sending processors and provides them to the intended receiving processors in a safe and secure manner.