Skip to content

patina-v22.2.3

Choose a tag to compare

@github-actions github-actions released this 29 Jul 15:11
517de6e

What's Changed

  • [Rebase \& FF] Memory Protection Policy: Default System Memory to WB @os-d (#1654)
    Change Details
      ## Description Currently, the add/allocate/free memory protection policies preserve the cache attributes of the memory. However, the entity consuming this memory may have changed the cache attributes. And added memory may have 0, which is invalid.

    In order to maintain a consistent state for system memory, Patina is taking the stance that system memory should be writeback by default. It will be allocated and returned as free as such. This allows a new allocation to have WB and allows free system memory blocks to coalesce correctly.

    Other memory types Patina preserves the cache attribute for because Patina doesn't know what the right attribute should be.

    This also contains a commit to clean up the includes in the GCD to be less verbose.

    Closes #1418

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

    How This Was Tested

    Booting Q35/ArmVirt to Windows, booting a physical Intel system to Windows.

    Integration Instructions

    N/A.




  • smbios: use upstream table GUID @kat-perez (#1653)
    Change Details
      ## Description

    Use r_efi::system::SMBIOS3_TABLE_GUID when publishing the SMBIOS 3 configuration table, removing Patina's duplicate private definition. This keeps the component aligned with the canonical UEFI constant provided by r-efi.

    Tracking: #1457

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

    How This Was Tested

    • cargo make fmt
    • cargo make test -p patina_smbios

    Integration Instructions

    N/A




  • Remove stale cargo dependencies @vineelko (#1651)
    Change Details
      ## Description

    Remove stale dependencies

    Found by running cargo machete --fix and filtered some false positives.

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

    How This Was Tested

    cargo make all

    Integration Instructions

    NA




📖 Documentation Updates

  • Add Patina SDK UEFI String Types [Rebase \& FF] @makubacki (#1657)
    Change Details
      ## Description

    Resolves #1656

    The UEFI Specification defines two string types: CHAR8 and CHAR16.

    • CHAR8: 1-byte character. Unless otherwise specified, all 1-byte or ASCII characters and strings are stored in 8-bit ASCII encoding format, using the ISO-Latin-1 character set.
    • CHAR16: 2-byte Character. Unless otherwise specified all characters and strings are stored in the UCS-2 encoding format as defined by Unicode 2.1 and ISO/IEC 10646 standards.

    strings.md (added to the mdbook) and doc comments explain the types in more detail, but at a high-level:

    Role CHAR8 CHAR16
    Borrowed, unsized Char8Str Char16Str
    Owned, heap-backed (requires alloc) Char8String Char16String
    Owned, fixed capacity (usable in const) Char8Array<N> Char16Array<N>

    Some code usage is updated to use the new types that might not be exhaustive (future changes can adopt the types as needed). However, more substantial changes to use the new types throughout the codebase would require changing public APIs and that was avoided in this change so the types can be introduced to the main branch without the PR being a breaking change. This makes existing code updates not as clean as they'd be otherwise. For example, if a public API takes a string today as Vec<u16>, this will update the caller to convert the string to a &Char16Str to check correctness, but it will ultimately need to be converted to Vec<u16> when passed as an argument (instead of directly as &Char16Str).

    After this PR is complete, it will be added to the major branch and the "breaking changes" to more completely use these types will be made there.


    Commits

    docs: set mdbook doctest edition to 2021

    mdbook doctests default to Rust edition 2015, since patina is on the
    2021 edition, this updates the mdbook to it as well.

    In particular, this is done now to allow path-based macro imports such
    as (use patina::{char16, char8};) and invocations like
    patina::char16!(...) to resolve.


    sdk: Add UEFI string types

    Adds two string families to the sdk modeled, to an extent, on
    CStr and CString.

    Char8Str/Char8String covers 8-bit Latin-1/ASCII strings which
    follows the exact format defined as CHAR8 in the UEFI
    Specification. Char16Str/Char16String covers the fixed 2-byte
    UCS-2 encoding format (following Unicode 2.1) defined as CHAR16
    in the UEFI Specification.

    These provide idiomatic and safe types to use for these strings
    in Patina.


    docs: Add UEFI string docs

    Adds a "UEFI Strings" page to explain how to use the string types
    recently added to the SDK.


    components: Use Patina SDK UEFI string types

    Updates a couple of components that have interfaces with raw string
    pointers to use the Char8Str types for processing.


    sdk: Use Patina SDK UEFI string types

    Updates string handling to use the new Patina SDK string types. This
    commit intentionally avoids larger refactors that impact public APIs.

    Note: Device path buffers with surrogate code units now return a parse
    error rather than being mapped to U+FFFD.


    patina_dxe_core: Use Patina SDK UEFI string types

    Updates string handling to use the new Patina SDK string types. This
    commit intentionally avoids larger refactors that impact public APIs.


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

    How This Was Tested

    • cargo make all
    • Boot to EFI shell on ArmVirt and Q35

    Integration Instructions

    • Use these new string types when appropriate per the instructions in strings.md.


Full Changelog: patina-v22.2.2...v22.2.3