• State Accepted Answer
  • Locked Locked
  • Replies 2 replies
  • Subscribers 351 subscribers
  • Views 6474 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Correct usage of the NSTable bit in aarch64/armv7a LPAE

Vincent Siles

I'm porting our armv7a-short descriptor OS to LPAE and aarch64. In the short descriptor MMU, the "NS" bit can only be found in the first level of the MMU (I'll call it the SECTION level), meaning that only a single page cannot be tagged as NS, a whole SECTION of pages must be.

With the introduction of LPAE (and now in aarch64), the NS bit is located at the last level of the MMU, and thus a single page can be tagged S or NS. However I'd like (for compatibility reason) to keep the same behavior as before, meaning I want to tag a whole SECTION of pages as S or NS.

From what I understand from the NSTable bit, it could be used to do that but I'm not 100% sure. Here is what I understand: setting the NSTable bit to 1 would have two effects:

  1. The next table located at the address in the descriptor will be treated as Non-secure, meaning that all of its entries' NS bits will be ignored and treated as Non-Secure. That's what I'm looking for
  2. The next table itself will be considered to be located in Non-Secure memory, which is not the case (all of my tables are in secure memory), so I'm facing MMU issues like writing data using S bindings and reusing them using NS bindings.

Is my understanding correct (in which case I can't use the NSTable bit for my compatibility purpose), or did I make some mistake and I could use it ?

Best regards,

V.

  • +1 Arm Employee Badge

    Hi Vincent,

    Your understanding is correct. We're especially pleased that you understood the second effect!

    The use case is sharing lower level page tables from the Non-Secure world with the Secure world. This protects the Secure world from translating a Non-Secure address to a Secure address by malicious (or mistaken) update of the Non-Secure tables by way of the NS bit, while conferring the advantage of being able to not have to recreate complex MMU mappings and share them in the Secure state.

    Obviously since the Non-Secure world can only write tables in Non-Secure memory, this is perfectly fine behavior. It does get a little complicated if you only have Secure memory available, though. The NSTable=1 will override not the end translation but the attributes sent to the cache and bus for table walks, and if your memory controller rejects a Non-Secure access either for table walks or for updates to the descriptors, that's not going to end well..

    Ta,

    Matt

  • 0 in reply to Matt Sealey

    Thank you for confirming the situation. I found another workaround (using a IGNORED bit of the Table descriptors) which seems to work fine... until the next MMU update :) Anyway it should be a temporary setting for our kernel so it does the job.

    Best Regards,

    V.