• State Accepted Answer
  • +2 person also asked this people also asked this
  • Locked Locked
  • Replies 5 replies
  • Subscribers 352 subscribers
  • Views 2414 views
  • Users 0 members are here
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

How MMU work In ARMv8 to prevent Access to EL1 virtual address from EL0

Flame

Hello,

I got a little problem in ARMv8's MMU.

Obviously, when we access the kernel virtual address in application such as :

    unsigned long *p = 0xffffffff28008000;
    unsigned long x = *p;
    *p = 1;

The application will be killed by kernel and then reports "segment fault".

But What the actual action does by MMU in ARMv8? When does it find the permission fault?

In the first time it gets the VA? OR when MMU obtains the value from the TTBR1_EL1? OR at the time when MMU translates the table and gets some descriptor which determines the permission?

Parents
  • +1

    Different OSs might take slightly different approaches. But...The architecture gives a kernel developer a few different ways to handle this. 

    One approach would be to disable access to the entirety of kernel space from user space.  There is a pair of top-level controls, called TCR_ELx.E0PDx, which can disable EL0 access to either half of the virtual address space.

    Arm A-profile Architecture Registers

    For example, setting TCR_EL1.E0PD1 causes any unprivileged access to trigger a translation fault. The MMU doesn't need to a TLB look-up/table walk to do this.  If the control is set, all the MMU has to do is look which half of the address space is being accessed and where the access came from.

    Another more software approach is to unmap most of kernel space before entering EL0 (and potentially setting TCR_ELn.EPDn).  Again, any attempt to access (most) kernel mappings will then fault.  If EPDn is set, then again the MMU doesn't require a table walk to make this determination.  BUT when you next re-enter the kernel, the kernel will need to restore its mappings.

    Or, you could do it per-page using permissions.  Each valid page has a set of permissions associated with it (e.g. read-able, executable).  For the EL0/1 (and EL0/2) translation regimes you can specify different user (EL0) and privileged (EL1) permissions.  To perform a permission check the MMU first has to have the translation.  When you access the page it will check the TLB for a cached permission, if there's none there the MMU performs a table walk.  Once it has the translation it compares the configured permission to the attempted access, faulting if necessary.

Reply
  • +1

    Different OSs might take slightly different approaches. But...The architecture gives a kernel developer a few different ways to handle this. 

    One approach would be to disable access to the entirety of kernel space from user space.  There is a pair of top-level controls, called TCR_ELx.E0PDx, which can disable EL0 access to either half of the virtual address space.

    Arm A-profile Architecture Registers

    For example, setting TCR_EL1.E0PD1 causes any unprivileged access to trigger a translation fault. The MMU doesn't need to a TLB look-up/table walk to do this.  If the control is set, all the MMU has to do is look which half of the address space is being accessed and where the access came from.

    Another more software approach is to unmap most of kernel space before entering EL0 (and potentially setting TCR_ELn.EPDn).  Again, any attempt to access (most) kernel mappings will then fault.  If EPDn is set, then again the MMU doesn't require a table walk to make this determination.  BUT when you next re-enter the kernel, the kernel will need to restore its mappings.

    Or, you could do it per-page using permissions.  Each valid page has a set of permissions associated with it (e.g. read-able, executable).  For the EL0/1 (and EL0/2) translation regimes you can specify different user (EL0) and privileged (EL1) permissions.  To perform a permission check the MMU first has to have the translation.  When you access the page it will check the TLB for a cached permission, if there's none there the MMU performs a table walk.  Once it has the translation it compares the configured permission to the attempted access, faulting if necessary.

Children