UEFI Boot File Validation via Dual RAID Arrays

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current deduplication backup systems, such as the DellEMC Data Domain system, face significant challenges with OS boot file corruptions during upgrades, reboots, or power failures, leading to unbootable systems due to the lack of validation and recovery mechanisms, especially when combined with strict UEFI secure boot checks.

Innovation Solution

Implementing an OS boot file validation and recovery mechanism that works in conjunction with UEFI secure boot, utilizing an OBF monitor and SOBF copy to regularly validate and automatically recover OS boot files, providing timely alerts and data protection during runtime, installation, and upgrades.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Object-affected harmful factors

If UEFI secure boot strict checks are implemented for OS boot files, then system security is improved, but system reliability deteriorates due to increased sensitivity to boot file corruptions

Engineering Contradiction:
Improvesystem securityVSAvoidsystem reliability
Core Design Contradiction:
Object-affected harmful factorsVSReliability

Solution Approach 1:

The patent implements preliminary validation of OS boot files using checksum verification before the UEFI secure boot process. A validation mechanism checks boot files during system operation and before critical boot operations, identifying corruptions early. This preliminary action prevents valid but corrupted files from failing UEFI security checks, thereby maintaining system reliability while preserving security enforcement.

Inventive Principle:
Principle #10Preliminary action

2Quantity of substance

If deduplication backup systems are deployed to reduce storage overhead, then storage efficiency is improved, but processing overhead increases due to deduplication processes

Engineering Contradiction:
Improvestorage overheadVSAvoidprocessing overhead
Core Design Contradiction:
Quantity of substanceVSProductivity

Solution Approach 1:

The patent extracts the boot file validation function from the general deduplication backup process. By separating boot file protection from the main deduplication operations, the system validates critical boot files independently without requiring full deduplication processing. This extraction reduces processing overhead for boot operations while maintaining storage efficiency benefits for other data.

Inventive Principle:
Principle #2Taking out (Extraction)

3Reliability

If OS boot files are validated and recovered during runtime, then system reliability is improved, but device complexity increases due to additional validation mechanisms

Engineering Contradiction:
Improvesystem reliabilityVSAvoiddevice complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent implements a self-service validation mechanism where the system automatically monitors and validates its own boot files during runtime. The validation process uses the system's existing resources and processes to check boot file integrity without requiring external intervention or complex additional hardware. This self-service approach improves reliability while minimizing added complexity.

Inventive Principle:
Principle #25Self-service

Data Source

PatentUS12141288B2Raid array for validating and recovering operating system boot files for UEFI secure boot systems
Publication Date: 2024.11.12 DELL PROD LP
  • US12141288B2 patent drawing
  • US12141288B2 patent drawing
  • US12141288B2 patent drawing

AI summary

A secure boot monitoring and validation process for operating system (OS) initial installation or upgrade operations. A validated copy of OS boot files is made during OS installation. The boot files are stored in a first RAID array. A checksum comparator or OS boot file filesystem check (FSCK) component validates the boot files upon initial installation of the OS by comparison with a secure copy of the boot files, which are stored in a second RAID array. Any validation failure indicates corruption or unwanted modification of the boot file data, and an autorecovery operation using different boot partitions is attempted.