Memory Sharing Between Realm EL1/0 and Non-Secure PAS in ARM RME

Realm EL1/0 Stage 2 Translation and Non-Secure PAS Access

The core issue revolves around the sharing of memory pages between the Realm EL1/0 and the Non-Secure Physical Address Space (PAS) in ARM’s Realm Management Extension (RME). The problem arises from the interpretation of the ARM RME specification, particularly section 5.1.2.3, which discusses Realm EL1&0 stage 2 translation. The specification states that if the stage 2 translation for a Realm stage 1 translation table walk resolves to an address not in the Realm PAS, it causes a stage 2 Permission fault. This implies that memory pages in the Non-Secure PAS cannot be directly accessed by the Realm EL1/0 without proper configuration.

However, the specification also mentions that if a Block or Page descriptor fetched for Realm EL1&0 stage 2 translation has the NS (Non-Secure) bit set to 1, the output address is in the Non-Secure PAS. This creates a contradiction because, on one hand, the specification suggests that Non-Secure PAS access is possible, but on the other hand, it indicates that such access could lead to permission faults. This ambiguity is further complicated by the observation that some memory pages with the NS bit set do not cause data aborts, while others do.

The confusion stems from the distinction between the Realm stage 1 translation tables and the data pages. The restriction specified in the ARM RME documentation applies specifically to the Realm stage 1 translation tables, which must reside in the Realm PAS. However, data pages can be shared between the Realm and Non-Secure worlds, provided that the NS bit is correctly set in the stage 2 translation tables. This distinction is crucial for understanding how memory sharing can be implemented without causing permission faults.

Misconfiguration of NS Bit and Translation Table Placement

The primary cause of the issue lies in the misconfiguration of the NS bit in the stage 2 translation tables and the incorrect placement of the Realm stage 1 translation tables. The NS bit in the stage 2 translation tables determines whether the output address is in the Non-Secure PAS or the Realm PAS. If the NS bit is set to 1, the output address is in the Non-Secure PAS, allowing the Realm to access Non-Secure memory. However, if the NS bit is not set correctly, or if the Realm stage 1 translation tables are placed in Non-Secure memory, it can lead to permission faults.

Another potential cause is the timing of the NS bit setting and the subsequent access to the memory pages. If the NS bit is set after the Realm has already started accessing the memory pages, it could result in inconsistent behavior, where some pages are accessible while others are not. This inconsistency can be exacerbated by the caching mechanisms in the ARM architecture, where stale translation table entries might be used, leading to unexpected permission faults.

Additionally, the issue could be related to the granularity of the memory sharing. The ARM RME specification allows for memory sharing at the page level, but if the memory pages are not aligned correctly or if the page size is not consistent between the Realm and Non-Secure worlds, it could lead to access violations. This is particularly relevant when dealing with large memory regions that span multiple pages, where the NS bit must be set consistently across all pages to ensure proper access.

Correct Configuration of NS Bit and Translation Tables

To resolve the issue, it is essential to ensure that the NS bit is correctly configured in the stage 2 translation tables and that the Realm stage 1 translation tables are placed in the Realm PAS. The following steps outline the process for achieving this:

1. Ensure Realm Stage 1 Translation Tables are in Realm PAS: The first step is to verify that the Realm stage 1 translation tables are placed in the Realm PAS. This can be done by checking the memory map of the system and ensuring that the translation tables are allocated in a region marked as Realm PAS. This is crucial because the ARM RME specification explicitly states that Realm stage 1 translation tables cannot be fetched from Non-Secure memory.

2. Set NS Bit in Stage 2 Translation Tables: The next step is to set the NS bit in the stage 2 translation tables for the memory pages that need to be shared between the Realm and Non-Secure worlds. This can be done by modifying the page table entries in the stage 2 translation tables to include the NS bit. It is important to ensure that the NS bit is set consistently across all pages that need to be shared.

3. Invalidate Translation Table Entries: After modifying the stage 2 translation tables, it is necessary to invalidate the translation table entries to ensure that the changes take effect immediately. This can be done using the TLBI (Translation Lookaside Buffer Invalidate) instruction, which flushes the TLB entries associated with the modified translation tables. This step is crucial to prevent the use of stale translation table entries, which could lead to permission faults.

4. Verify Memory Access: Once the NS bit is set and the translation table entries are invalidated, it is important to verify that the memory pages are accessible from both the Realm and Non-Secure worlds. This can be done by performing read and write operations on the shared memory pages and checking for any data aborts or permission faults. If any issues are encountered, it may be necessary to revisit the configuration of the NS bit and the placement of the translation tables.

5. Handle Caching Mechanisms: The ARM architecture includes various caching mechanisms that can affect the behavior of memory access. It is important to ensure that the caching mechanisms are configured correctly to prevent inconsistencies in memory access. This includes configuring the cacheability and shareability attributes of the memory pages and ensuring that the cache is flushed after modifying the translation tables.

6. Monitor for Inconsistent Behavior: Finally, it is important to monitor the system for any inconsistent behavior, such as memory pages that are accessible in some cases but not in others. This could indicate issues with the timing of the NS bit setting or the granularity of the memory sharing. If such issues are detected, it may be necessary to adjust the configuration of the NS bit or the placement of the translation tables to ensure consistent behavior.

By following these steps, it is possible to correctly configure the NS bit and the translation tables to enable memory sharing between the Realm EL1/0 and the Non-Secure PAS in ARM RME. This will ensure that the memory pages are accessible without causing permission faults, allowing for seamless data access between the Realm and Non-Secure worlds.

Detailed Explanation of ARM RME Memory Sharing Mechanisms

To further understand the issue and its resolution, it is important to delve into the details of the ARM RME memory sharing mechanisms. The ARM RME introduces a new security state called the Realm world, which is distinct from the Secure and Non-Secure worlds. The Realm world has its own physical address space (Realm PAS) and translation tables, which are used to manage memory access within the Realm.

The stage 2 translation tables in ARM RME are used to translate virtual addresses to physical addresses in the Realm PAS. The NS bit in the stage 2 translation tables determines whether the output address is in the Non-Secure PAS or the Realm PAS. When the NS bit is set to 1, the output address is in the Non-Secure PAS, allowing the Realm to access Non-Secure memory. When the NS bit is set to 0, the output address is in the Realm PAS, restricting access to Realm memory.

The key point to note is that the NS bit only affects the output address of the stage 2 translation, not the input address. This means that the Realm stage 1 translation tables must always reside in the Realm PAS, regardless of the NS bit setting. This is because the stage 1 translation tables are used to translate virtual addresses to intermediate physical addresses, which are then translated to physical addresses by the stage 2 translation tables.

The restriction on the placement of the Realm stage 1 translation tables is necessary to ensure the security of the Realm world. If the stage 1 translation tables were allowed to reside in Non-Secure memory, it would be possible for the Non-Secure world to modify the translation tables and gain unauthorized access to Realm memory. By requiring the stage 1 translation tables to reside in the Realm PAS, the ARM RME ensures that the translation tables are protected from tampering by the Non-Secure world.

However, this restriction does not prevent the Realm from accessing Non-Secure memory. As long as the NS bit is set correctly in the stage 2 translation tables, the Realm can access Non-Secure memory without causing permission faults. This allows for the sharing of memory pages between the Realm and Non-Secure worlds, which is essential for certain use cases, such as data exchange between the Realm and Non-Secure applications.

In summary, the ARM RME provides a mechanism for sharing memory pages between the Realm and Non-Secure worlds through the use of the NS bit in the stage 2 translation tables. However, this mechanism requires careful configuration to ensure that the Realm stage 1 translation tables are placed in the Realm PAS and that the NS bit is set correctly in the stage 2 translation tables. By following the steps outlined in the previous section, it is possible to achieve this configuration and enable seamless memory sharing between the Realm and Non-Secure worlds.

Practical Considerations for Implementing Memory Sharing

Implementing memory sharing between the Realm and Non-Secure worlds in ARM RME requires careful consideration of several practical factors. These factors include the alignment of memory pages, the granularity of memory sharing, and the impact of caching mechanisms on memory access.

1. Alignment of Memory Pages: When sharing memory pages between the Realm and Non-Secure worlds, it is important to ensure that the memory pages are aligned correctly. This is particularly relevant when dealing with large memory regions that span multiple pages. If the memory pages are not aligned correctly, it could lead to access violations, as the NS bit must be set consistently across all pages to ensure proper access. To avoid this issue, it is recommended to align the memory pages on page boundaries and ensure that the NS bit is set consistently across all pages.

2. Granularity of Memory Sharing: The granularity of memory sharing refers to the size of the memory regions that are shared between the Realm and Non-Secure worlds. The ARM RME allows for memory sharing at the page level, but the page size can vary depending on the system configuration. It is important to ensure that the page size is consistent between the Realm and Non-Secure worlds to avoid access violations. If the page size is not consistent, it may be necessary to adjust the configuration of the NS bit or the placement of the translation tables to ensure proper access.

3. Impact of Caching Mechanisms: The ARM architecture includes various caching mechanisms that can affect the behavior of memory access. When sharing memory pages between the Realm and Non-Secure worlds, it is important to consider the impact of these caching mechanisms on memory access. This includes configuring the cacheability and shareability attributes of the memory pages and ensuring that the cache is flushed after modifying the translation tables. Failure to do so could result in inconsistent behavior, where some memory pages are accessible while others are not.

4. Handling Translation Table Updates: When updating the stage 2 translation tables to set the NS bit, it is important to ensure that the updates are performed atomically to prevent race conditions. This can be done by using appropriate synchronization mechanisms, such as memory barriers or atomic operations, to ensure that the updates are performed in a consistent manner. Failure to do so could result in inconsistent behavior, where some memory pages are accessible while others are not.

5. Monitoring for Permission Faults: After configuring the NS bit and the translation tables, it is important to monitor the system for any permission faults that may occur. This can be done by enabling the appropriate exception handlers and logging any permission faults that are encountered. If permission faults are detected, it may be necessary to revisit the configuration of the NS bit and the placement of the translation tables to ensure proper access.

By considering these practical factors, it is possible to implement memory sharing between the Realm and Non-Secure worlds in ARM RME in a robust and reliable manner. This will ensure that the memory pages are accessible without causing permission faults, allowing for seamless data access between the Realm and Non-Secure worlds.

Conclusion

In conclusion, the issue of sharing memory pages between the Realm EL1/0 and the Non-Secure PAS in ARM RME can be resolved by correctly configuring the NS bit in the stage 2 translation tables and ensuring that the Realm stage 1 translation tables are placed in the Realm PAS. This requires careful consideration of the alignment of memory pages, the granularity of memory sharing, and the impact of caching mechanisms on memory access. By following the steps outlined in this guide, it is possible to achieve seamless memory sharing between the Realm and Non-Secure worlds, enabling efficient data exchange and collaboration between the two security states.