Re: [RFC] MPU support for debugging


Boie, Andrew P
 

On Sat, 2017-03-11 at 17:21 -0500, Benjamin Walsh wrote:
Some random thoughts on this, do with them as you wish. :)

To get more detailed feedback, I think you need to document how
exactly
you intend on using the MPU.

- Introduce the notion of User/Supervisor threads. User threads
would
only have write access to their own stack, plus some additional
memory
                            ^^^^^^^^^^^^^^^
And whatever other stacks are in the same protection region: stack
overflow will only corrupt the current region, but they can still
happen
and wreck havoc within the protection area. Or are you thinking of
rewriting the memory protection area boundaries on every context
switch
to with bounds around the current thread's stack ? I don't mean only
changing the permissions, but the boundaries themselves ?
Yes, that's the intention. Every context switch _Swap() would involve
reprogramming the MPU (or MMU page tables) to appropriate values for
the incoming thread.

THIS IS NOT A SECURITY FEATURE
This bothers me a bit. If you ever want to turn this into a more
fleshed-out user-space model, would you introduce a third API/model
or
modify them again ?

My gut feeling would be to design for the full "user-space" model,
and
then have the reduced-capability MPU-model be a special case of it.

Then again, depends on the timeframe and how future-proof you want to
design this.
My expectation was that we can implement this proposal without changing
our existing kernel APIs. Kernel APIs would be supplemented with a few
extra calls to drop a thread down to User mode and set up its memory
regions. I don't see much else changing.

To go to a full userspace model, my thought process was that we have to
re-do all the kernel APIs to work with descriptors instead of pointers,
introduce an allocator on the kernel side, etc. My thinking was that it
will fundamentally change the class of devices that we are targeting
with this OS, and I was loath to introduce such a sweeping change to
all the kernel APIs.

However, I think you may have convinced me, read on..


I think this needs more of a "split" between kernel and "user-space"
APIs than a redesign. But then, kernel applications could not be
rebuilt
as user-space applications. Applications using the user-space API
could
probably be rebuilt as kernel applications, if we provided the
user-space API as a very thin layer around the current kernel APIs in
the kernel. Nothing would prevent removing the user-space layer and
run
kernel-only.
I like this idea. Supplement all the k_* APIs with z_* APIs (or
whatever naming convention people agree on) which are intended to be
run from userspace context. They will handle allocation and descriptor
management and call into the kernel APIs. Let people working on
severely RAM-constrained devices like Quark D2000 keep using kernel
APIs like they are now. Everybody wins.

The real trick of course is in the scenario where the protection is
only being used during the debug phase of development, how to make the
userspace layer thin enough with memory protection disabled that it
would be roughly comparable in footprint and performance to an app that
just used kernel APIs directly.

- No need for system calls for privilege elevation. Through macro
magic, if memory protection is turned on we can wrap kernel/driver
What do you mean by "macro magic" ? There has to be a mechanism to
trigger the privilege elevation. On ARM, you have to use the SVC
instruction, handle the exception, write the CONTROL register, and
come
back to the next instruction after SVC. That's basically one system
call, which purpose is to elevate the privilege of the current
thread.
I am waving my arms here, but I was thinking this would be a relatively
small amount of code to do a generic privilege escalation to run
whatever kernel code is desired by the caller, rather than a carefully
controlled table of valid system call entry points.

But this is moot, I like the idea of supplementing the kernel APIs with
a set of parallel userspace APIs much better.

Thanks for your feedback, I'm going to spend some more time thinking
about this, but now I'm leaning towards a full userspace solution (with
MPU as a special case with physical=virtual addresses) with a
supplemental API for userspace applications that handles descriptor
management and kernel object allocation. I'll send another proposal
with this taken into account.

Andrew

Join devel@lists.zephyrproject.org to automatically receive all group messages.