Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #29844
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Memory Protections |
| Date | 2020-07-14 11:48 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <rekulq$c1b$1@dont-email.me> (permalink) |
| References | <reig95$pab$1@dont-email.me> <9b1rgf5mn82jguosum324pja890g91pnf5@4ax.com> |
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:
>
>> For no-execute, I don't see any use beyond that of enhancing
>> confidence in the codebase; I don't see any *features* that
>> rely on detecting "legal" attempts to execute particular
>> regions of memory (assuming execute-access is treated as
>> a special case of read-access).
>>
>> 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.
OTOH, if you use the protections to detect errant accesses ("can't happen"),
then you are relying on it to reinforce your belief that your code is robust.
The absence of the hooks might be troubling (if you lack confidence in
your testing regime) but shouldn't interfere with your code's proper operation.
> Obviously something like a JIT compiler needs to be able to switch off
> NX for the code buffer so a program can execute it ... but there's no
> point to allowing access before the code is ready
Unless you *truly* JIT the code "as needed" (i.e., a memory region at
a time) *or* are JIT'ing in parallel with execution. The executing thread
could be accessing "already JIT'ed" portions of the code without having
to wait for the JIT compiler to "finish".
[Think about how a code image would be built, in detail, if it spanned
multiple memory allocation units AND YOU DIDN'T HAVE A BACKING STORE!]
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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