patina-v22.0.0

What's Changed

⚠️ Breaking Changes

• [major] Simplify patina\_performance config, Add SMBIOS types to Patina, R-EFI 6.0 Migration @vineelko (#1548)
  
  Change Details

    ## Description

  1465: patina_performance: Simplify configuration

  patina_performance has a confusing configuration story. Prior to this change, configuration was done via patina Config, A platform could optionally register a secondary component that would read a HOB (if provided) and overwrite any Config with the HOB configuration.

  This commit works to simplify the configuration story by making a couple of changes:

  1. Removal of the Config object. As stated in documentation throughout patina, Config is meant for configuration that is expected to be shared between multiple components. This particular configuration does not need to be shared, so it is moved to be private configuration of the component.
  2. Removal of the optional HOB reader driver. Now, a private configuration of the component will allow you to specify if the HOB is able to override local configuration or not.

  This new story reduces patina_performance setup from three different definitions (Config, performance component, and hob component) to only one, the performance component.

  How This Was Tested

  Reading final configuration of the performance component on Q35 with various configuration settings both in the component and via the HOB

  Previous

  use patina_dxe_core::*;
  
  struct Q35;
  
  impl ComponentInfo for Q35 {
    fn configs(mut add: Add<Config>) {
      add.config(patina_performance::config::PerfConfig {
        enable_component: true,
        enabled_measurements: patina::performance::Measurement::LoadImage | patina::performance::Measurement::StartImage
      }
    }
    
    fn components(mut add: Add<Component>) {
      add.component(patina_performance::component::performance_config_provider::PerformanceConfigurationProvider);
      add.component(patina_performance::component::performance::Performance);
    }
  }

  After

  use patina_dxe_core::*;
  use patina_performance::component::*;
  
  struct Q35;
  
  impl ComponentInfo for Q35 {
    fn components(mut add: Add<Component>) {
      // Records LoadImage and StartImage measurements unless configuration is overwritten by a HOB
      add.component(Performance::new().with_measurements(Measurement::LoadImage | Measurement::StartImage));
      
      // Disabled. Enablement fully controlled by a HOB
      add.component(Performance::new());
  }

  ---

  1501: patina_smbios: Add SMBIOS types

  Define types for SMBIOS records according the SMBIOS specs 3.0+ and update records to use types. These structs/enums/bitfields force typing when creating SMBIOS records.

  How This Was Tested

  cargo make all, plus patina-dxe-core-qemu integration: ported the Q35 and
  SBSA SMBIOS platform components onto the new typed records, booted Q35 in
  QEMU, and confirmed q35_smbios_ffi_test passes against the published SMBIOS
  table.

  Integration Instructions

  Downstream consumers of patina_smbios Type 0 / 1 / 2 / 3 / 4 / 7 / 16 / 17 /
  19 records must construct fields with the new types instead of raw integers
  (e.g. BiosCharacteristics::from_bits(0x08), WakeUpType::PowerSwitch,
  BootUpState::Safe). For Type 4, set processor_family: u8 = 0xFE and put
  the typed value in processor_family2.

  Co-Authored-By: Ansley Thompson ansley.thompson@dell.com

  ---

  1480: Patina: R-EFI 6.0 migration

  R-EFI 6.0 Migration

  Upstream r-efi 6.0 marks all extern "efiapi" function pointers in EFI Boot
  Services, Runtime Services, and other protocols as unsafe, since their safety
  cannot be enforced by the Rust type system at compile time.

  This PR audits almost all usage of UEFI service function pointers across the Patina
  codebase for correctness and safety.

  • There are three primary areas where unsafe usage has been audited:

    1. The FFI boundary - all extern "efiapi" functions
    2. The Patina wrappers - all functions within the BootServices trait that
       eventually call into the FFI
    3. Core Patina routines that implement the FFI functions

  • Not all functions in the above categories need to be marked unsafe. For
    example, extern "efiapi" close_event is not marked unsafe because it can
    safely be called with an arbitrary event parameter without causing undefined
    behavior in the Patina implementation. The event parameter is treated as an
    opaque pointer and is never dereferenced.

    That said, any indirect caller that dereferences this Boot Services function
    pointer must still use an unsafe block, since the function pointer itself is
    defined as unsafe in r-efi 6.0. In addition, inherently unsafe Rust
    functions (such as core_free_pool()) are now explicitly marked unsafe.

  • Each inspected function or call site is documented with appropriate safety
    comments where necessary, and with explanations where unsafe is not
    required.

  • There are no functional changes.

  • Clippy flags public functions that accept raw pointer parameters and pass them
    across an FFI boundary without being marked unsafe, with the following
    warning:
    "this public function might dereference a raw pointer but is not marked unsafe"

    unsafe extern "C" {
        fn some_ffi_call(ptr: *mut i32);
    }
    
    // Triggers clippy::not_unsafe_ptr_arg_deref:
    // - public function
    // - not marked `unsafe`
    // - raw pointer parameter `ptr` is passed into an `unsafe` block
    pub fn example(ptr: *mut i32) {
        unsafe { some_ffi_call(ptr) };
    }
    

    In Patina, this pattern is common for functions that take efi::Event or
    efi::Handle parameters and call Boot Services function pointers. We
    explicitly suppress this lint for such functions because these types are
    treated as opaque pointers and are never dereferenced:
    #[allow(clippy::not_unsafe_ptr_arg_deref)]

  Geiger Unsafe Stats

  |             | x86_64-unknown-uefi(before) | x86_64-unknown-uefi(after) | aarch64-unknown-uefi(before) | aarch64-unknown-uefi(after) |
  |-------------|-----------------------------|----------------------------|------------------------------|-----------------------------|
  | overall     | 11.90% (yellow)             | 16.30% (red)               | 12.20% (yellow)              | 16.30% (red)                |
  | functions   | 2.60%  (green)              | 11.40% (yellow)            | 2.80%  (green)               | 11.40% (yellow)             |
  | exprs       | 12.40% (yellow)             | 17.00% (red)               | 12.60% (yellow)              | 17.00% (red)                |
  | item_impls  | 12.50% (yellow)             | 13.80% (yellow)            | 13.80% (yellow)              | 13.80% (yellow)             |
  | item_traits | 12.10% (yellow)             | 13.00% (yellow)            | 13.00% (yellow)              | 13.00% (yellow)             |
  | methods     | 5.60%  (green)              | 6.60%  (green)             | 5.60%  (green)               | 6.60%  (green)              |
  

  • Impacts functionality?
  • Impacts security?
  • Breaking change?
  • Includes tests?
  • Includes documentation?

  How this was tested

  Verified booting to UEFI shell from Q35, SBSA

  Integration Instructions

  All consumers of Patina will need to pick the newer Patina version when published and also should update their R-EFI version to 6.0.0.
  

  
  

  ---

  
  

Full Changelog: patina-v21.2.0...v22.0.0