Setting up the TTBR0 and TTBR1 register for thread stack protection in ARMv7-A MMU

[Gedare Bloom]

On Fri, Jun 5, 2020 at 6:49 AM Hesham Almatary <heshamelmatary at gmail.com> wrote:
>
> Hello Utkarsh,
>
> TTBR1 is there primarily for UNIX-like kernels to be re-mapped at very
> high addresses and user space can use TTBR0. In the case of RTEMS, we
> don't have that user vs kernel separation. Furthermore, using TTBR1
> won't allow us to do 1:1 fixed mappings.
>
> Could you give more details why having different page sizes would be
> an issue? You would normally have multi-level page tables for more
> fine-grained page sizes.
+1

>
> On Thu, 4 Jun 2020 at 11:44, Utkarsh Rai <utkarsh.rai60 at gmail.com> wrote:
> >
> > Hello,
> >
> > Section B3.3.3 of the ARMv7-A Reference manual says that we can have TTBR0 and 1 split up the address space into two parts, where each register has the address of the translation table base
> > of the divided address space.
> > One of the ways to simplify the implementation of thread-stack protection in ARMv7-A MMU can be, to have the global statically allocated sections being pointed by the TTBR1 register and the work-space area being pointed out by the TTBR0 register. This way during context switch we would only have to change the TTBR0 register, this would also simplify the implementation as we won't have to worry about addresses of different page sizes being pointed by the same translation-table base.
> > In the current implementation, TTB is put in TTBR0, and TTBR1 is not used.

To clear a possible confusion, you can't have multiple workspaces.
That is the dynamic memory region (e.g., program heap) used by RTEMS
to manage object allocations.

> > Is the above-suggested implementation feasible?
> >
> > Regards,
> > Utkarsh
>
>
>
> --
> Hesham
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel