dpotop
Posts: 52
Joined: Mon Nov 24, 2014 2:14 pm

MMU and multitasking

Sun Jan 11, 2015 1:10 am

Hello again,

My RPi mini-kernel is now up and running, with
time-sharing multithreading (very simple), with
programs loaded from the SD card,
and I now have the MMU and caches working.
And of course the nice UART console. :)
I want to thank you all for the information you
posted here and elsewhere, which helped me a lot.

I also have a question:
I want to set up access control between memory
areas allocated to tasks and I try to understand the
"domain" concept from the ARM documentation.
As I understand it:
- each page is associated to a domain (16 max unless
entering the armv6 MMU mode, in which case there
are 16 more "secure" modes).
- there is a coprocessor register (CP15 c3)which can be
only changed in a privileged mode, and
which determines whether access to a domain is
allowed.

But, I don't see yet how can I forbid a task all access to
pages that are not its own. Assume the very simple case
where I have 1Mbyte pages of which I only use 16:
- one is used by the kernel (code, data, stack, heap)
- the remaining ones are each used by one
of the 15 tasks.
How do I manage the permissions so that a task can only
access its own page? I don't want to let it even read from
the kernel page.

Yours,
Dumitru
dpotop

dpotop
Posts: 52
Joined: Mon Nov 24, 2014 2:14 pm

Re: MMU and multitasking

Sun Jan 11, 2015 7:44 pm

Ok, I think I have found a solution, but I really don't like
it because I have to let tasks have read-only access to
one page of non-task code. I will start my implementation,
but let me know if you already have some other solution.

Cheers,
Dumitru
dpotop

hldswrth
Posts: 107
Joined: Mon Sep 10, 2012 4:14 pm

Re: MMU and multitasking

Mon Jan 12, 2015 10:15 am

In my hobby OS, each task has memory allocated with only user access. Access to kernel memory only happens through software interrupts (SWI) which switch into kernel mode, then back to user mode when they finish. Each user task has its own virtual address space starting at 0, so one task cannot access another task's memory. I don't use domains at all.

dpotop
Posts: 52
Joined: Mon Nov 24, 2014 2:14 pm

Re: MMU and multitasking

Mon Jan 12, 2015 8:12 pm

hldswrth wrote:n my hobby OS, each task has memory allocated with only user access. Access to kernel memory only happens through software interrupts (SWI) which switch into kernel mode, then back to user mode when they finish. Each user task has its own virtual address space starting at 0, so one task cannot access another task's memory. I don't use domains at all.
Thanks for sharing your solution (you're the first).

It's similar to what I want to do. I have two issues with this solution:
1. It has the problem I mentioned: at least part of the kernel code and data (the page containing the code that changes to user mode and then branches to task code) must be in a memory page that is readable in user mode.

2. Not using domains means that you have to change the page table when switching between tasks. It seemed to me that it is easier (more cost-effective in both RAM used and lines of code) to just change the domain access word.

Yours,
Dumitru
dpotop

rst
Posts: 267
Joined: Sat Apr 20, 2013 6:42 pm
Location: Germany

Re: MMU and multitasking

Tue Jan 13, 2015 7:52 pm

dpotop wrote:1. It has the problem I mentioned: at least part of the kernel code and data (the page containing the code that changes to user mode and then branches to task code) must be in a memory page that is readable in user mode.
There are ARM instructions which do both things (mode switch and branch) at once. I used

Code: Select all

ldmfd sp!, {r0-r12, pc}^
as the last instruction of the interrupt handler in my hobby kernel. It does a task switch if a timer interrupt was handled. The instruction restores r0-r12 and pc from stack, moves spsr to cpsr (mode switch) and updates the stack pointer. This code is completely hidden from the user task.
2. Not using domains means that you have to change the page table when switching between tasks. It seemed to me that it is easier (more cost-effective in both RAM used and lines of code) to just change the domain access word.
I think changing the value in TTBR0 is a common thing on a task switch.

dpotop
Posts: 52
Joined: Mon Nov 24, 2014 2:14 pm

Re: MMU and multitasking

Wed Jan 14, 2015 7:59 pm

Thanks rst !
Now it makes sense.
Dumitru
dpotop

Return to “Bare metal”

Who is online

Users browsing this forum: No registered users and 6 guests