Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #29843

Re: Memory Protections

Show all headers | View raw

On 7/14/2020 2:40 AM, Theo wrote:
> Don Y <blockedofcourse@foo.invalid> wrote:
>> On 7/13/2020 1:30 PM, Don Y wrote:
>>> The ONE question I am posing here is "are there any?"
>>
>> A colleague has come up with a few "non-contrived" examples
>> so the answer is "yes", apparently!  OK, so, that will make
>> things quite a bit easier...
> 
> Do you feel like sharing them?

One (or more) threads WITHIN a task (sharing the SAME logical
address space as the thread that may, eventually, try to EXECUTE
"marked" code) can be building/modifying that code image asynchronously
wrt the thread that wants to execute it.  Think of the no execute
provision as a form of implicit lock -- instead of having to
(prematurely and possibly unnecessarily!) EXPLICITLY block the thread(s)
that might want to fetch opcodes from that region.

The same sorts of things apply inside the (multithreaded) kernel.

I.e., don't restrict your thinking to kernel vs. user activities
in a given memory region.

[Note that this can include activities beyond JIT'ing -- but I don't care to
expound on those]

As all threads (in a task/kernel) share the same address mappings/protections,
there's no way to ensure that thread X can diddle with the page while thread
Y can't (yet) execute its contents (unless you modify the protections on a
per THREAD basis AND have a uniprocessor).

OTOH, if you exploit the fact that X's accesses will be "read/write" (diddling)
while Y accesses as "execute" -- different permissions enable/restrict the
threads implicitly.

My interest is in the "protection" API... NOT wanting to have to special-case
execute permissions differently than read or write.  If the developer's code
can tolerate NOT having a read or write permission that he had "hoped for",
then he should be able to tolerate not having an execute permission, too!
Conversely, if the developer RELIED on having read or write traps then he
should be able to express that dependency in the execute permission of the API.

I.e., if your *desire* for a particular set of permission(s) at a point in
your code is just to enhance reliability, then you can <shrug> off not having
ANY of the desired set.  OTOH, if your desire stems out of a NEED for a
particular set of permissions -- cuz your algorithm relies on them -- then
you will have to <panic>.  The API has to expose these different cases to
the developer.

[Or, more properly, your task won't be admitted to a host that doesn't
advertise those capabilities as being available; you'll have to be
installed/migrated onto a host that DOES!  Just like if your code
RELIES on floating point hardware being present (because the emulation
is too slow)]

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Memory Protections Don Y <blockedofcourse@foo.invalid> - 2020-07-13 13:30 -0700
  Re: Memory Protections Don Y <blockedofcourse@foo.invalid> - 2020-07-13 23:45 -0700
    Re: Memory Protections Theo <theom+news@chiark.greenend.org.uk> - 2020-07-14 10:40 +0100
      Re: Memory Protections Don Y <blockedofcourse@foo.invalid> - 2020-07-14 11:44 -0700
      Re: Memory Protections mac <acolvin@efunct.com> - 2020-07-19 15:03 +0000
  Re: Memory Protections George Neuner <gneuner2@comcast.net> - 2020-07-14 06:21 -0400
    Re: Memory Protections Stefan Reuther <stefan.news@arcor.de> - 2020-07-14 18:17 +0200
    Re: Memory Protections Don Y <blockedofcourse@foo.invalid> - 2020-07-14 11:48 -0700
      Re: Memory Protections George Neuner <gneuner2@comcast.net> - 2020-07-16 02:02 -0400
        Re: Memory Protections Don Y <blockedofcourse@foo.invalid> - 2020-07-17 18:25 -0700

csiph-web