Integration of disparate system architectures using configurable isolated memory regions and trust domain conversion bridge
Techniques are described for providing consistent memory operations and security across electronic circuitry components having disparate memory and/or security architectures when integrating such disparately architected components within a single system, such as a system on chip. A programmable logical hierarchy of isolated memory region (IMR) enforcement circuits is provided to protect such IMRs, allowing or preventing memory access requests from one of multiple distinct circuitry components based on configuration registers for the IMR enforcement circuits. Integration of multiple trust domain architectures associated with the multiple distinct circuitry components is facilitated via trust domain conversion bridge circuitry that includes translation logic for generating information in accordance with a first trust domain architecture based on information provided in accordance with a distinct second trust domain architecture.
1. A trust domain conversion bridge including:
inputs;
outputs;
trust domain bridge circuitry coupled, by way of at least one of the inputs to one or more first circuitry components that, in operation, utilize a first trust domain architecture corresponding to first security information, and further coupled, by way of at least one of the outputs, to one or more second circuitry components that, in operation, utilize a second trust domain architecture corresponding to second security information different from the first security information, and wherein the trust domain bridge circuitry is to:
receive first trust domain information from at least one of the one or more first circuitry components through the at least one of the inputs, wherein the first trust domain information includes an address and a cycle type, the first trust domain information being compliant with the first trust domain architecture and corresponding to a transaction between said at least one of the one or more first circuitry components and at least one of the one or more second circuitry components;
generate, based on the first trust information, second trust domain information that is in accordance with the second trust domain architecture and corresponds to the transaction between the at least one of the one or more first circuitry components and the at least one of the one or more second circuitry components; and
provide the second trust domain information to the at least one of the one or more second circuitry components through the at least one of the outputs.
2. The trust domain bridge of claim 1 , wherein the trust domain bridge circuitry is to generate the second trust domain information by using one or more of a finite state machine, a fixed lookup table, or a programmable lookup table.
3. The trust domain bridge of claim 1 , wherein the trust domain bridge circuitry is to use configurable parameters to compensate for one or more machine states not specific to any one trust domain, the one or more machine states including at least one of a debug state, a pre-boot state, a boot state or an operating system (OS) specified state.
4. The trust domain bridge of claim 1 , wherein the first trust domain information includes at least one of NS bits or an identification (ID).
5. The trust domain bridge of claim 4 , wherein the ID includes one or more of fabric IDs.
6. The trust domain bridge of claim 1 , wherein the second trust domain information includes at least one of a Cycle Type, an address, an identification (ID), or a Security Attributes Initiator.
7. The trust domain bridge of claim 6 , wherein the second trust domain information further includes a programmable state to distinguish between a pre-boot, boot and post-boot machine state.
8. The trust domain bridge of claim 1 , wherein the first trust domain architecture is based on an a flexible memory map with target-based protections for at least one of memory or memory-mapped input/output.
9. The trust domain bridge of claim 1 , wherein the second trust domain architecture is based on a fixed memory map security model for memory-based protection.
10. A system for integrating multiple circuitry components that are based on multiple trust domain architectures, the system comprising:
one or more first circuitry components that in operation utilize a first trust domain architecture corresponding to first security information;
one or more second circuitry components that in operation utilize a second trust domain architecture corresponding to second security information different from the first security information;
trust domain bridge circuitry coupled to each of at least one of the one or more first circuitry components and to each of at least one of the one or more second circuitry components, wherein the trust domain bridge circuitry is to:
receive first trust domain information from at least one of the one or more first circuitry components, wherein the first trust domain information includes an address and a cycle type, the first trust domain information being compliant with the first trust domain architecture and corresponding to a transaction between said at least one of the one or more first circuitry components and at least one of the one or more second circuitry components;
generate, based on the first trust domain information, second trust domain information that is in accordance with the second trust domain architecture and corresponds to the transaction between the at least one of the one or more first circuitry components and the at least one of the one or more second circuitry components; and
provide the generated second trust domain information to the at least one of the one or more second circuitry components.
11. The system of claim 10 , wherein generating second trust domain information includes using one or more of a finite state machine, a fixed lookup table, or a programmable lookup table.
12. The system of claim 10 , further including using configurable parameters of the trust domain bridge circuitry to compensate for one or more machine states not specific to any one trust domain, the one or more machine states including at least one of a debug state, a pre-boot state, a boot state or an operating system (OS) specified state.
13. The system of claim 10 , wherein the first trust domain information includes at least one of an address, a cycle type, NS bits, an identification (ID).
14. A method to be performed at a trust domain bridge circuitry (TDBC) that is connected to each of one or more first circuitry components that in operation utilize a first trust domain architecture corresponding to first security information, and that is connected to each of one or more second circuitry components that in operation utilize a second trust domain architecture corresponding to a second security information different from the first security information, the method including:
receiving first trust domain information from at least one of the one or more first circuitry components, wherein the first trust domain information includes an address and a cycle type, the first trust domain information being compliant with the first trust domain architecture and corresponding to a transaction between said at least one of the one or more first circuitry components and at least one of the one or more second circuitry components;
generate, based on the first trust domain information, second trust domain information that is in accordance with the second trust domain architecture and corresponds to the transaction between the at least one of the one or more first circuitry components and the at least one of the one or more second circuitry components; and
provide the generated second trust domain information to the at least one of the one or more second circuitry components.
15. The method of claim 14 , wherein generating second trust domain information includes using one or more of a finite state machine, a fixed lookup table, or a programmable lookup table.
16. The method of claim 14 , further including using configurable parameters of the trust domain bridge circuitry to compensate for one or more machine states not specific to any one trust domain, the one or more machine states including at least one of a debug state, a pre-boot state, a boot state or an operating system (OS) specified state.
17. The method of claim 14 , wherein the first trust domain information includes at least one of an address, a cycle type, NS bits, an identification (ID).
18. The method of claim 17 , wherein the ID includes one or more of fabric IDs.
19. The method of claim 14 , wherein the second trust domain information includes at least one of a Cycle Type, an address, an identification (ID), or a Security Attributes Initiator.
20. The method of claim 19 , wherein the second trust domain information further includes a programmable state to distinguish between a pre-boot, boot and post-boot machine state.
21. A non-transitory machine readable storage medium to store instructions that, when executed, cause a trust domain bridge circuitry (TDBC) that is connected to each of one or more first circuitry components that in operation utilize a first trust domain architecture corresponding to first security information, and that is connected to each of one or more second circuitry components that in operation utilize a second trust domain architecture corresponding to second security information different from the security information, to perform operations including:
receive first trust domain information from at least one of the one or more first circuitry components, wherein the first trust domain information includes an address and a cycle type, the first trust domain information being compliant with the first trust domain architecture and corresponding to a transaction between said at least one of the one or more first circuitry components and at least one of the one or more second circuitry components;
generate, based on the first distinct second trust domain information that is in accordance with the second trust domain architecture and corresponds to the transaction between the at least one of the one or more first circuitry components and the at least one of the one or more second circuitry components; and
provide the generated distinct second trust domain information to the at least one of the one or more second circuitry components.
22. The storage medium of claim 21 , wherein generating second trust domain information includes using one or more of a finite state machine, a fixed lookup table, or a programmable lookup table.
23. The storage medium of claim 21 , further including using configurable parameters of the trust domain bridge circuitry to compensate for one or more machine states not specific to any one trust domain, the one or more machine states including at least one of a debug state, a pre-boot state, a boot state or an operating system (OS) specified state.
24. The storage medium of claim 21 , wherein the first trust domain information includes at least one of NS bits or an identification (ID).
25. The method of claim 24 , wherein the ID includes one or more of fabric IDs.