diff --git a/docs/src/SUMMARY.md b/docs/src/SUMMARY.md index e2f158c..0607b52 100644 --- a/docs/src/SUMMARY.md +++ b/docs/src/SUMMARY.md @@ -10,6 +10,7 @@ # Specification * [Introduction](./specification/README.md) +* [Use Cases](./specification/use_cases/README.md) * [Threat Model](./specification/threat_model.md) * [Firmware Resiliency](./specification/firmware_resiliency.md) * [Middleware](./specification/middleware/README.md) diff --git a/docs/src/architecture.md b/docs/src/architecture.md index 218dae6..f719a68 100644 --- a/docs/src/architecture.md +++ b/docs/src/architecture.md @@ -22,10 +22,6 @@ openprot/ ## Components -### Main Application (`openprot/`) - -The main application provides... - ### Build System (`xtask/`) The xtask system provides automated build tasks including: diff --git a/docs/src/contributing.md b/docs/src/contributing.md index 4412a48..ef7d8bd 100644 --- a/docs/src/contributing.md +++ b/docs/src/contributing.md @@ -1,4 +1,13 @@ -# Contributing +# Contributing to OpenPRoT + +## Contributor License Agreement + +- Use of OpenPRoT requires no CLA. +- Contributions to OpenPRoT must have signed the [CHIPS CLA](https://github.com/chipsalliance/Caliptra/blob/main/CONTRIBUTING.md#contributor-license-agreement). + +## Code of Conduct + +The code of conduct can be found [here](https://github.com/OpenPRoT/.github/blob/main/CODE_OF_CONDUCT.md). ## Development Setup diff --git a/docs/src/design/README.md b/docs/src/design/README.md index f936956..53831af 100644 --- a/docs/src/design/README.md +++ b/docs/src/design/README.md @@ -1 +1,17 @@ -# Design \ No newline at end of file +# Design + +This section contains design documents that provide a detailed overview of the +design and implementation of the OpenProt project. These documents are intended +to provide guidance to developers and anyone interested in the internal workings +of the project. + +## Documents + +- [**Generic Digest Server Design Document**](./driver-hubris-hash.md): This + document describes the design and architecture of a generic digest server + for Hubris OS that supports both SPDM and PLDM protocol implementations. + +- [**Converting Rust HAL Traits to Idol Interfaces**](./rust-trait-to-idl-conversion.md): + A practical guide that explains how to transform Rust Hardware Abstraction + Layer (HAL) traits into Idol interface definitions for use in Hubris-based + systems. diff --git a/docs/src/introduction.md b/docs/src/introduction.md index c58be70..12dfbf0 100644 --- a/docs/src/introduction.md +++ b/docs/src/introduction.md @@ -1,20 +1,91 @@ # Introduction -Welcome to the OpenProt documentation! +Welcome to the OpenPRoT documentation! -This documentation provides comprehensive information about the OpenProt project, including user guides, developer documentation, and API references. +This documentation provides comprehensive information about the OpenPRoT +project, including user guides, developer documentation, and API references. -## What is OpenProt? +## What is OpenPRoT? -OpenProt is a Rust-based project that provides... +OpenPRoT is an open-source, Rust-based project designed to provide a secure and +reliable foundation for platform security. It offers a flexible and extensible +framework for developing firmware and security-related applications for a +variety of platforms. + +At its core, OpenPRoT provides a Hardware Abstraction Layer (HAL) that enables +platform-agnostic application development. On top of this HAL, it offers a suite +of services and protocols for platform security, including device attestation, +secure firmware updates, and more. The project is designed with a strong +emphasis on modern security protocols and standards, such as: + +- **SPDM (Security Protocol and Data Model):** For secure communication and + attestation. +- **MCTP (Management Component Transport Protocol):** As a transport for + management and security protocols. +- **PLDM (Platform Level Data Model):** For modeling platform components and + their interactions. + +## Project Goals + +The primary goals of the OpenPRoT project are to: + +- **Promote Security:** Provide a robust and secure foundation for platform + firmware, leveraging modern, industry-standard security protocols. +- **Ensure Reliability:** Offer a high-quality, well-tested, and reliable + codebase for critical platform services. +- **Enable Extensibility:** Design a modular and extensible architecture that + can be easily adapted to different hardware platforms and use cases. +- **Foster Collaboration:** Build an open and collaborative community around + platform security. + +## Documentation Overview + +This documentation is structured to help you understand and use OpenPRoT +effectively. Here’s a guide to the different sections: + +- **[Getting Started](./getting-started.md):** A hands-on guide to setting up + your development environment and building your first OpenPRoT application. +- **[Specification](./specification/):** The OpenPRoT specification. +- **[Repo Structure](./architecture.md):** A high-level overview of the + OpenPRoT repository structure, including its major components and their + interactions. +- **[Usage](./usage.md):** Detailed instructions on how to use the OpenPRoT + framework and its various services. +- **[Design](./design/):** In-depth design documents and + specifications for the various components of OpenPRoT. +- **[Contributing](./contributing.md):** Guidelines for contributing to the + OpenPRoT project. + +## Repositories + +- https://github.com/OpenPRoT/openprot: Main OpenPRoT repository. +- https://github.com/OpenPRoT/mctp-rs: MCTP protocol support for Linux and + embedded platforms. ## Quick Start -To get started with OpenProt: +To get started with OpenPRoT, you can build and test the project using the +following commands: ```bash cargo xtask build cargo xtask test ``` -For more detailed instructions, see the [Getting Started](./getting-started.md) guide. +For more detailed instructions, please refer to the +[Getting Started](./getting-started.md) guide. + +## Governance + +The OpenPRoT Technical Charter can be found at +[here](https://github.com/OpenPRoT/.github/blob/main/GOVERNANCE.md). + +## Security Policy + +Please refer to the [Security Policy](https://github.com/OpenPRoT/openprot/security/policy) +for more information. + +## License + +Unless otherwise noted, everything in this repository is covered by the [Apache +License, Version 2.0](https://github.com/OpenPRoT/openprot/blob/main/LICENSE). diff --git a/docs/src/specification/middleware/mctp.md b/docs/src/specification/middleware/mctp.md index f5fa124..2347b6c 100644 --- a/docs/src/specification/middleware/mctp.md +++ b/docs/src/specification/middleware/mctp.md @@ -1,7 +1,5 @@ # MCTP -Status: Draft. - MCTP OpenPRoT devices shall support MCTP as the transport for all DMTF protocols. @@ -13,7 +11,9 @@ The *minimum required* MCTP version is 1.3.1 (DSP0236.) Support for MCTP 2.0.0 ## Required Bindings Currently only one binding is *mandatory* in the OpenPRoT specification, though -this will change in future versions. 1. . MCTP over SMBus (DSP0237, 1.2.0) +this will change in future versions. + +1. MCTP over SMBus (DSP0237, 1.2.0) ## Recommended Bindings diff --git a/docs/src/specification/middleware/pldm.md b/docs/src/specification/middleware/pldm.md index c960e00..98ffbbc 100644 --- a/docs/src/specification/middleware/pldm.md +++ b/docs/src/specification/middleware/pldm.md @@ -1,69 +1,72 @@ -## PLDM +# PLDM -PLDM OpenPRoT devices will support Platform Level Data Model as a responder for -FW updates and platform monitoring. This means that OpenPRoT will respond to -Type 0, Type 2 and Type 5 as listed in Table 1\. +OpenPRoT devices support the Platform Level Data Model (PLDM) as a responder for +firmware updates and platform monitoring. This entails responding to messages of +Type 0 (Base), Type 2 (Platform Monitoring and Control), and Type 5 (Firmware +Update). -## PLDM Base Specifications for Supported Types {#pldm-base-specifications-for-supported-types} +## PLDM Base Specifications ### Type 0 - Base Specification -* Purpose: Base Specification and Initialization -* Version: 1.2.0 -* [Platform Level Data Model (PLDM) Base Specification](https://www.dmtf.org/sites/default/files/standards/documents/DSP0240_1.2.0.pdf) +- **Purpose**: Base Specification and Initialization +- **Version**: 1.2.0 +- **Specification**: + [PLDM Base Specification](https://www.dmtf.org/sites/default/files/standards/documents/DSP0240_1.2.0.pdf) -All responders shall implement the four (4) *spec mandatory* PLDM commands: +All responders must implement the following mandatory PLDM commands: -* `GetTID` -* `GetPLDMVersion` -* `GetPLDMTypes` -* `GetPLDMCommands` +- `GetTID` +- `GetPLDMVersion` +- `GetPLDMTypes` +- `GetPLDMCommands` -All responders shall implement the following *optional* commands +All responders must also implement the following optional command: -* `SetTID` +- `SetTID` ### Type 2 - Platform Monitoring and Control -* Purpose: Platform Monitoring and Control -* Version: 1.3.0 -* [Platform Level Data Model (PLDM) for Platform Monitoring and Control - Specification](https://www.dmtf.org/sites/default/files/standards/documents/DSP0248_1.3.0.pdf) +- **Purpose**: Platform Monitoring and Control +- **Version**: 1.3.0 +- **Specification**: + [PLDM for Platform Monitoring and Control](https://www.dmtf.org/sites/default/files/standards/documents/DSP0248_1.3.0.pdf) -OpenPRoT will support PLDM Monitoring and Control by providing a PDR, Platform -Descriptor Record, repository to a prospective PDLM Manageability Access Point -Discovery Agent’s primary PDR. These PDRs will be defined via Json files and -included into OpenPRoT at build time. OpenPRoT will not support any dynamic -adjustments to the PDR repository. These PDRs should be limited to security -features and as such, will only support PLDM sensors and not effectors. PLDM -Monitoring PDRs +OpenPRoT supports PLDM Monitoring and Control by providing a Platform Descriptor +Record (PDR) repository to a prospective PLDM manageability access point +discovery agent. These PDRs are defined in JSON files and included in OpenPRoT +at build time, with no support for dynamic adjustments. The PDRs are limited to +security features and will only support PLDM sensors, not effectors. -* Terminus Locator PDR -* Numeric Sensor PDR +#### PLDM Monitoring PDRs + +- Terminus Locator PDR +- Numeric Sensor PDR ### Type 5 - Firmware Update -* Purpose: Firmware Update -* Version: 1.3.0 -* [Platform Level Data Model (PLDM) for Firmware Update Specification](https://www.dmtf.org/sites/default/files/standards/documents/DSP0267_1.3.0.pdf) +- **Purpose**: Firmware Update +- **Version**: 1.3.0 +- **Specification**: + [PLDM for Firmware Update](https://www.dmtf.org/sites/default/files/standards/documents/DSP0267_1.3.0.pdf) -Required Inventory Commands: +#### Required Inventory Commands -* `QueryDeviceIdentifiers` -* `GetFirmwareParameters` +- `QueryDeviceIdentifiers` +- `GetFirmwareParameters` -Required Update Commands: +#### Required Update Commands -* `RequestFirmwareUpdate` -* `PassComponentTable` -* `UpdateComponent` -* `TransferComplete` -* `VerifyComplete` -* `ApplyComplete` -* `ActivateFirmware` -* `GetStatus` +- `RequestFirmwareUpdate` +- `PassComponentTable` +- `UpdateComponent` +- `TransferComplete` +- `VerifyComplete` +- `ApplyComplete` +- `ActivateFirmware` +- `GetStatus` -All responders shall implement the following optional commands +All responders must also implement the following optional commands: -* `GetPackageData` -* `GetPackageMetaData` +- `GetPackageData` +- `GetPackageMetaData` diff --git a/docs/src/specification/middleware/spdm.md b/docs/src/specification/middleware/spdm.md index e849fb4..034ab83 100644 --- a/docs/src/specification/middleware/spdm.md +++ b/docs/src/specification/middleware/spdm.md @@ -1,113 +1,118 @@ # SPDM -Status: Draft - SPDM OpenPRoT devices shall use SPDM to conduct all attestation operations both with downstream devices (as a requester) and upstream devices (as a responder.) Devices may choose to act as a requester, a responder, or both. All SPDM version -references assume alignment with the most recently released versions of the spec -(i.e. 1.2.1, 1.3.2.) - -1. [OCP Attestation Spec 1.1](https://github.com/google/spdm-accelerator-requirement/blob/main/OCP-Attestation-v1.1.docx.pdf) - Alignment OpenPRoT implementations of SPDM must align with the OCP - Attestation Spec 1.1, linked above. All following sections have taken this - spec into account. Please refer to that specification for details on - specific requirements. -2. Baseline Version OpenPRoT sets a baseline version of SPDM 1.2. -3. Requesters OpenPRoT devices implementing an SPDM requester will implement - support for SPDM 1.2 minimum and may implement SPDM 1.3 and up. The minimum - and maximum supported SPDM versions can be changed if support for other - versions is not necessary. -4. Responders OpenPRoT devices implementing an SPDM responder must implement - support for SPDM 1.2 or higher. Responders may only report (via - `GET_VERSION`) a single supported version of SPDM. -5. Required Commands All requesters and responders shall implement the four (4) - *spec mandatory* SPDM commands: - - * `GET_VERSION` - - * `GET_CAPABILITIES` - - * `NEGOTIATE_ALGORITHMS` - - * `RESPOND_IF_READY` - - All requesters and responders shall implement the following *spec optional* - commands: - - * `GET_DIGESTS` - * `GET_CERTIFICATE` - * `CHALLENGE` - * `GET_MEASUREMENTS` - * `GET_CSR` - * `SET_CERTIFICATE` - * `CHUNK_SEND` - * `CHUNK_GET` - - Requesters and responders may implement the following recommended *spec - optional* commands: - - * Events - * `GET_SUPPORTED_EVENT_TYPES` - * `SUBSCRIBE_EVENT_TYPES` - * `SEND_EVENT` - * Encapsulated requests - * `GET_ENCAPSULATED_REQUEST` - * `DELIVER_ENCAPSULATED_RESPONSE` - * `GET_KEY_PAIR_INFO` - * `SET_KEY_PAIR_INFO` - * `KEY_UPDATE` - * `KEY_EXCHANGE` - * `FINISH` - * `PSK_EXCHANGE` - * `PSK_FINISH` - - All other *spec optional* commands may be implemented as the integrator sees - fit for their use case. - -6. Required Capabilities - - * `CERT_CAP` (required for `GET_CERTIFICATE`) - * `CHAL_CAP` (required for `CHALLENGE`) - * `MEAS_CAP` (required for `GET_MEASUREMENT`) - * `MEAS_FRESH_CAP` - -7. Algorithms The following cryptographic algorithms are accepted for use - within OpenPRoT, but may be further constrained by hardware capabilities. At - a minimum OpenPRoT hardware must support: +references assume alignment with the most recently released versions of the spec. + +## OCP Attestation Spec 1.1 Alignment + +OpenPRoT implementations of SPDM must align with the +[OCP Attestation Spec 1.1](https://github.com/google/spdm-accelerator-requirement/blob/main/OCP-Attestation-v1.1.docx.pdf). +All following sections have taken this spec into account. Please refer to that +specification for details on specific requirements. + +## Baseline Version + +OpenPRoT sets a baseline version of SPDM 1.2. + +## Requesters + +OpenPRoT devices implementing an SPDM requester will implement support for SPDM +1.2 minimum and may implement SPDM 1.3 and up. The minimum and maximum supported +SPDM versions can be changed if support for other versions is not necessary. + +## Responders + +OpenPRoT devices implementing an SPDM responder must implement support for SPDM +1.2 or higher. Responders may only report (via `GET_VERSION`) a single supported +version of SPDM. + +## Required Commands + +All requesters and responders shall implement the four (4) *spec mandatory* SPDM +commands: + +* `GET_VERSION` +* `GET_CAPABILITIES` +* `NEGOTIATE_ALGORITHMS` +* `RESPOND_IF_READY` + +All requesters and responders shall implement the following *spec optional* +commands: +* `GET_DIGESTS` +* `GET_CERTIFICATE` +* `CHALLENGE` +* `GET_MEASUREMENTS` +* `GET_CSR` +* `SET_CERTIFICATE` +* `CHUNK_SEND` +* `CHUNK_GET` + +Requesters and responders may implement the following recommended *spec +optional* commands: + +* Events + * `GET_SUPPORTED_EVENT_TYPES` + * `SUBSCRIBE_EVENT_TYPES` + * `SEND_EVENT` +* Encapsulated requests + * `GET_ENCAPSULATED_REQUEST` + * `DELIVER_ENCAPSULATED_RESPONSE` +* `GET_KEY_PAIR_INFO` +* `SET_KEY_PAIR_INFO` +* `KEY_UPDATE` +* `KEY_EXCHANGE` +* `FINISH` +* `PSK_EXCHANGE` +* `PSK_FINISH` + +All other *spec optional* commands may be implemented as the integrator sees fit +for their use case. + +## Required Capabilities + +* `CERT_CAP` (required for `GET_CERTIFICATE`) +* `CHAL_CAP` (required for `CHALLENGE`) +* `MEAS_CAP` (required for `GET_MEASUREMENT`) +* `MEAS_FRESH_CAP` + +## Algorithms + +The following cryptographic algorithms are accepted for use within OpenPRoT, but +may be further constrained by hardware capabilities. At a minimum OpenPRoT +hardware must support: + +* `TPM_ALG_ECDSA_ECC_NIST_P384` +* `TPM_ALG_SHA3_384` + +All others are optional and may be used if supported. + +* Asymmetric + * `TPM_ALG_ECDSA_ECC_NIST_P256` * `TPM_ALG_ECDSA_ECC_NIST_P384` + * `EdDSA ed25519` + * `EdDSA ed448` + * `TPM_ALG_SHA_384` +* Hash + * `TPM_ALG_SHA_256` + * `TPM_ALG_SHA_384` + * `TPM_ALG_SHA_512` + * `TPM_ALG_SHA3_256` * `TPM_ALG_SHA3_384` + * `TPM_ALG_SHA3_512` +* AEAD Cipher + * `AES-128-GCM` + * `AES-256-GCM` + * `CHACHA20_POLY1305` + +## Attestation Report Format + +Devices will support either RATS EAT (as CWT) or an SPDM evidence manifest TOC +per the *TCG DICE Concise Evidence for SPDM* specification. + +## Measurement block 0xF0 - All others are optional and may be used if supported. - - * Asymmetric - * `TPM_ALG_RSASSA_2048` - * `TPM_ALG_RSAPSS_2048` - * `TPM_ALG_RSASSA_3072` - * `TPM_ALG_RSAPSS_3072` - * `TPM_ALG_ECDSA_ECC_NIST_P256` - * `TPM_ALG_RSASSA_4096` - * `TPM_ALG_RSAPSS_4096` - * `TPM_ALG_ECDSA_ECC_NIST_P384` - * `EdDSA ed25519` - * `EdDSA ed448` - * `TPM_ALG_SHA_384` - * Hash - * `TPM_ALG_SHA_256` - * `TPM_ALG_SHA_384` - * `TPM_ALG_SHA_512` - * `TPM_ALG_SHA3_256` - * `TPM_ALG_SHA3_384` - * `TPM_ALG_SHA3_512` - * AEAD Cipher - * `AES-128-GCM` - * `AES-256-GCM` - * `CHACHA20_POLY1305` - -8. Attestation Report Format Devices will support either RATS EAT (as CWT) or - an SPDM evidence manifest TOC per the *TCG DICE Concise Evidence for SPDM* - specification. - -9. Measurement block 0xF0 Devices that do not provide a Measurement Manifest - shall locate RATS EAT at SPDM measurement block 0xF0 +Devices that do not provide a Measurement Manifest shall locate RATS EAT at SPDM +measurement block 0xF0 diff --git a/docs/src/specification/services/README.md b/docs/src/specification/services/README.md index 4d111fa..6bd6838 100644 --- a/docs/src/specification/services/README.md +++ b/docs/src/specification/services/README.md @@ -1,5 +1,13 @@ # Services +The OpenPRoT services layer provides a standardized set of security and +management functions that are essential for a Platform Root of Trust (PRoT). +Built on top of the middleware and Hardware Abstraction Layer (HAL), this layer +offers high-level capabilities that applications can leverage to ensure system +integrity, security, and reliability. + +The following services are defined in the OpenPRoT specification: + * [Firmware Update](./fwupdate.md) * [Attestation](./attestation.md) * Firmware Recovery (TBD) diff --git a/docs/src/specification/services/attestation.md b/docs/src/specification/services/attestation.md index 49f6906..980cdd2 100644 --- a/docs/src/specification/services/attestation.md +++ b/docs/src/specification/services/attestation.md @@ -1,6 +1,4 @@ -**Version:** 0.1 (Draft) -**Date:** [Current Date] -**Status:** Work in Progress +# Attestation ## 1. Introduction diff --git a/docs/src/specification/use_cases/README.md b/docs/src/specification/use_cases/README.md new file mode 100644 index 0000000..6ec5037 --- /dev/null +++ b/docs/src/specification/use_cases/README.md @@ -0,0 +1,76 @@ +## Use Cases + +Use cases are divided into two general groups: + +* **Legacy Admissible Architectures**: Where the upstream device, that is, the + device attached to the Root of Trust (RoT), boots from SPI NOR Flash EEPROM. +* **Modern Admissible Architectures**: Where the upstream device supports + flash-less boot (i.e., stream boot). Support for modern architectures will + be added in a future version of this specification. + +### Legacy Admissible Architectures + +There are three legacy admissible architectures supported by the OpenPRoT +implementation: + +| Architecture | Common Usages | SPI NOR Flash EEPROM | +| :-------------------------- | :---------------------------------- | :-------------------------------------------------- | +| **Dual-Flash Side-by-side** | (Preferred) Most integrations | Two parts, one partition per part (i.e., A + B). | +| **Direct-Connect** | Add-in devices; board-constrained | One part, double-sized to support A/B updates. | +| **TPM** | TPM Daughtercard, Onboard TPM | None | + + +### Direct-Connect + +In the **Direct-Connect** architecture, OpenPRoT acts as an SPI interposer +between the upstream device and the SPI NOR Flash EEPROM. OpenPRoT examines the +opcode of each transaction and decides whether the operation should pass through +to the backing SPI Flash or be intercepted and handled by its hardware filtering +logic. This policy is controlled by both hardware and firmware. Typically: + +* **Control operations** are handled by the RoT hardware directly. +* **Read operations** are passed through to the backing SPI Flash. +* **Write operations** are intercepted by OpenPRoT firmware and may be + replayed to the backing SPI flash based on security policy. + +OpenPRoT supports atomic A/B updates by diverting read operations to either the +lower or upper half of the SPI Flash while hiding the opposing half. This +requires the SPI Flash to be double the size needed by the upstream device +(e.g., a 512Mbit Flash for a 256Mbit requirement). + +legacy_direct + +**Note**: Direct-Connect has a hardware limitation on the maximum supported SPI +frequency due to board capacitance, layout, and the PRoT silicon. The +integration designer must verify that the expected SPI frequency range is +compatible with the upstream device. If this architecture is infeasible, +consider the **Dual-Flash Side-by-Side** architecture instead. + +### Dual-Flash Side-by-Side + +In the **Dual-Flash Side-by-Side** architecture, the upstream device has direct +access to one of two physical SPI NOR Flash EEPROM chips, selected by an +OpenPRoT-controlled mux. This arrangement supports atomic A/B updates. OpenPRoT +can also directly access each flash chip. The layout should use the smallest +possible nets to avoid signal integrity issues from stubs. + +Both SPI Flash chips **must be the same part**. The OpenPRoT firmware +coordinates the mux control and its two SPI host interfaces to ensure the nets +are not double-driven. + +legacy_direct + +**Note**: If using quad-SPI, the flash requires a password protection feature, +as the Write Protect (WP) pin is not available. + +### TPM + +The **TPM Admissible Architecture** is designed for a direct connection to a +standard TPM-SPI interface. In this configuration, OpenPRoT can be soldered onto +the main board or placed on a separate daughtercard. + +TPM integrations do not require a backing SPI NOR Flash EEPROM and generally +only support single-mode SPI. Where possible, these integrations should adhere +to a standard TPM connector design. + +legacy_direct diff --git a/docs/src/specification/use_cases/legacy_direct.svg b/docs/src/specification/use_cases/legacy_direct.svg new file mode 100644 index 0000000..8ed60e2 --- /dev/null +++ b/docs/src/specification/use_cases/legacy_direct.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/src/specification/use_cases/legacy_side_by_side.svg b/docs/src/specification/use_cases/legacy_side_by_side.svg new file mode 100644 index 0000000..c95be0c --- /dev/null +++ b/docs/src/specification/use_cases/legacy_side_by_side.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/src/specification/use_cases/legacy_tpm.svg b/docs/src/specification/use_cases/legacy_tpm.svg new file mode 100644 index 0000000..c48cfb1 --- /dev/null +++ b/docs/src/specification/use_cases/legacy_tpm.svg @@ -0,0 +1 @@ + \ No newline at end of file