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

[Utkarsh Rai]

On Fri, Jun 5, 2020 at 6:19 PM 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.
>
>
I agree, sorry, after looking around a bit more I realized some of the
above limitations.


> 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.


No this will not be an issue, we can set the bits[1:0]  of the table-entry
to account for the levels of page tables. I was thinking about ways to
simplify the implementation of stack allocation, but doing this is
definitely not feasible.


>
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.
> > Is the above-suggested implementation feasible?
> >
> > Regards,
> > Utkarsh
>
>
>
> --
> Hesham
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200605/ffae3b6a/attachment-0001.html>