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

Groups > comp.arch.embedded > #29847

Re: Memory Protections

Show all headers | View raw

On 7/15/2020 11:02 PM, George Neuner wrote:
> On Tue, 14 Jul 2020 11:48:14 -0700, Don Y
> <blockedofcourse@foo.invalid> wrote:
> 
>> On 7/14/2020 3:21 AM, George Neuner wrote:
>>> On Mon, 13 Jul 2020 13:30:16 -0700, Don Y
>>> <blockedofcourse@foo.invalid> wrote:

>>>> The ONE question I am posing here is "are there any?"
>>>
>>> I'm not sure what you're getting at here: what would be a "legal"
>>> attempt to execute NX protected memory?
>>
>> The same sort of thing that would be a "legal" attempt to read
>> "no read" memory.  In THAT case, deliberately exploiting the protection
>> mechanism to detect references to memory that hasn't yet been mapped!
>>
>> A similar case exists for trapping writes to "no write" memory (e.g., CoW).
>>
>> Both are examples of "legal" accesses that have been preempted to
>> implement FEATURES.  So, code that relies on these hooks would have to
>> <panic> if the hooks were not available.
> 
> Not really. There are legitimate reasons to read-protect readable
> memory: to enable hardware assisted GC for instance.

You're just reinforcing my distinction of cases where a particular protection
is REQUIRED by the code vs. DESIRED by the developer.  If your code RELIED
on hardware assist for GC (note my emphasis on RELIED!), then, if the hosting
processor didn't provide that support, your code would fail/panic.

> But you don't GC executable code ... at least not *while* it still is
> executable ... so the analogy to protecting readable data doesn't
> hold.

Marking a part of memory as "no execute" -- KNOWING that you will
eventually want to execute <something> that (will) reside there -- is
comparable to marking a part of memory as "no read/access" KNOWING that
you will eventually want to read something that WILL reside there,
after it is "loaded" (or "something else") from some other mechanism
(which may or may not be backing store).

Marking it as "no execute" because it's an embedded JPEG image is entirely
different -- your code SHOULDN'T be trying to execute a JPEG; you
wouldn't rely on this mechanism for your code's correctness.

> The idea that you might try to verify "right to execute" doesn't wash
> either, because once a code is unprotected anyone can execute it - not
> just one process that somehow has been "verifed".

It's not a question of "verifying right to execute" -- any more than
your GC example is "verifying right to read".  You develop the algorithm
(GC in your case) with a reliance (or not) on having a particular
mechanism at your disposal.  In the absence of that mechanism (note my
"ONE question"!), you either <panic> or fall back on an alternative
algorithm (i.e., if you don't want to code and maintain an alternative
algorithm -- or, if that algorithm doesn't satisfy the same requirements
as the first -- then you can only <panic>)

And, you can only execute code that is made available to you (process).
UNavailable means "not in YOUR address space" *or* "not marked as
executable".  Just like data that isn't in your address space (or is
marked as no-write) isn't writable even if someone ELSE can write it!

[I can't prevent individual THREADS in the same process container as the
INTENDED thread from executing that code.  But, that's not a loss of
control as the "intended" thread could just as easily decide to do
whatever the other threads would!]

> Do this kind of
> thing requires segmentation (or real capabilities), not just page NX
> (unless the protection somehow is virtualized individually for all
> processes - which is not the case with any existing CPU).

Huh?  I can set a "no execute" permission at page granularity.
And, set that protection ONLY in the translation table for process A.
Process B's page table may define it as R/W.  And, process C's may
define it as "no access", at all!  So, process B could, potentially,
be building the executable image while A is potentially tied up in a
trap (if it had tried to execute the page's contents before they were
ready)

Do you expect ALL processes to share a single address space?

I'm designing the SPARC implementation, presently.  The smallest
page size is a bit larger than I'd like -- but, then again, I don't
plan on deploying a SPARC box (but, they are excellent for testing code
portability, endianness tolerance, on-the-fly data format conversions,
etc.)

It also illustrates the problems encountered when designing the "protection"
API -- SPARC only lets me support R/O, R/W, R/X, R/W/X, X/O and "no access".
After that, I'll tackle the ARM port.

I'm hoping to demo a heterogeneous system for the upcoming off-site.
Showing real-time redundancy support among dissimilar hosting nodes
should be impressive! (i.e., unplugging a SPARC and watching the
services that it was supplying migrate to an ARM or x86 -- and
/vice versa/ -- while still satisfying any timeliness constraints
that were in effect at the time of the interruption)

[Beyond that, as I said to Theo, up-thread, I'm not keen on discussing what
I'm doing or how I'm doing it!  The magic is left as an exercise for the
reader -- or, someone sufficiently interested to explore how to ACTUALLY
do it (beyond an armchair interest)]

Back to comp.arch.embedded | Previous | Next — Previous 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