Work up linker-based system call prototype for MPU enabling

[nashif]

Reported by Andy Ross:

The use of an MPU-isolated process model requires that calls into the kernel be "system call" traps, for obvious reasons. Yet the existing kernel API is a bunch of C function calls, for good reason, and it would be really good to keep it that way for future maintainability.

While obviously some API styles (those that pass/return pointers to buffers to be used by the application, or those that pass callbacks which need to be executed in user context) won't work without modification, the bulk of the kernel API doesn't really need to change: pointers to e.g. semaphores and fifo's and the like are used as opaque handles by the standard APIs that expose them, so the app doesn't need to know what the protection status is of the memory that contains them.

So how about this: work up a "flag" that can be applied to functions at the preprocessor level that tags functions as being part of the system call API. For each of those, generate both the true function (for use from within the kernel or other priviledged contex) and a pair of stubs that do the parameter marshalling and trap/return needed to call the same function from unprivileged code.

Then we can apply some link-time magic (just renaming management, really) to select which of these to call based on current context. We might default to treating all application code as "unprivileged", for example. Or we could provide a mechanism to flag individual C functions or whole translation units, etc...

Needs prototyping.

(Imported from Jira ZEP-1938)

[nashif]

by Andrew Boie:

• syscall-rig.tar.gz (size: 10240)

[nashif]

by Andrew Boie:

Logging with JIRA:

As promised in the call this morning, this is a cleaned up version of the simple syscall stub mapping proof of concept. It's not zephyr-specific code, just build it on your desktop.

Basically it sets things up so that a "mycall" system call turns into a call to one of two different functions depending on the presence of a KERNEL_MODE prepropcessor symbol. So application code can be written identically across modes, no need for a special API.

See the README for more details.

(And I was wrong, by the way. The original more complicated version used GCC's "weakref" attribute, but I thought it would work to simplify it to a simpler linker "alias" instead. But that doesn't work because GCC only allows you to alias within a single translation unit. So weakref will have to do. I checked, clang handles this compatibly.)

Andy

[nashif]

by Mark Linkmeyer:

Andy Ross , what's the status of this story? I moved it to "In Progress" a long time ago (in March) probably in a triage meeting and Andrew moved to be targeted for 1.9. Is it being worked on and is it on track for 1.9? Thx.

[nashif]

by Andrew Boie:

I'm starting to look into this, building on the POC Andy Ross made. At this time we're planning on having system calls for 1.10, pushing this out.