Re: NX bit versus standard permissions?
From: Matt (spamtrap_at_crayne.org)
Date: 09/15/04
- Previous message: spamtrap_at_crayne.org: "Re: Can't get full drive transfer rate -- what am I doing wrong?"
- In reply to: Bob Masta: "Re: NX bit versus standard permissions?"
- Next in thread: Brian Mitchell: "Re: NX bit versus standard permissions?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 15 Sep 2004 19:29:43 +0000 (UTC)
"Bob Masta" <NoSpam@daqarta.com> wrote in message
news:4146dc6a.540273@news.itd.umich.edu...
> On Mon, 13 Sep 2004 15:33:15 +0000 (UTC), Ivan Korotkov
> <spamtrap@crayne.org> wrote:
>
>>> I'm getting really confused here! What are those
>>> IMAGE_SCN_MEM_EXECUTE,
>>> IMAGE_SCN_MEM_READ, and IMAGE_SCN_MEM_WRITE
>>> flags in the PE header 'Characteristics' section for? If they don't
>>> control access to the sections, then why do I need to
>>> set them properly in order to include data and code
>>> together in one section?
>>
>>No, you seem to miss the idea. Data and code are not included in one
>>section. Section is not a segment neither a page. It is a COFF term that
>>stands for a series of pages with similar protection and content. .data
>>has MEM_READ | MEM_WRITE flags, i.e. all pages which this section is
>>mapped to will have RW(+NX if any) flags. .text (.code) has MEM_READ |
>>MEM_EXEC, i.e. it's pages will be given RX permission. The same flags are
>>available for VirtualProtect(). When CPU has no NX bit, MEM_EXEC flag is
>>useless - it's just ignored. But it should always be set for pages in code
>>section for future compatibility.
>
> Sorry if I'm being dense here, but I still don't get it!
[...]
Since Windows 2000 and possibly prior, Windows has defined 8 page
permissions for VirtualProtect (not counting modifies like PAGE_GUARD):
PAGE_NOACCESS, PAGE_READONLY, PAGE_READWRITE, PAGE_WRITECOPY, PAGE_EXECUTE,
PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE, and PAGE_EXECUTE_WRITECOPY.
They're fairly self-explanitory. You can simplify it and think of it as an
orthogonal RWX model of permission bits even though notably W/WX are not
supported combinations of bits. Also, you can ignore the write-copy flags;
they're used only with shared memory -- on forked processes, and on certain
file mapping objects (NT section objects).
Now, if the CPU has no way to enforce NX, the execute permission is
effectively ignored. As others have stated, x86 CPUs could *only* enforce
execution permissions through the cs segment, but since cs is flat on most
systems, there is no way to prevent execution of arbitrary code. That
changes on CPUs with NX.
The flags on the COFF sections determine the bits set on the pages in that
section at runtime. If the COFF section is marked as RW, then the page gets
PAGE_WRITECOPY. If it is marked as RX, it gets PAGE_EXECUTE_READ.
Fortunately tools have been good about setting the execute bit in the code
section, so binaries are generally forward-compatible.
For you, you can continue leaving the code section as RWX and it will work
just fine on NX CPUs. The memory will be marked PAGE_EXECUTE_WRITECOPY. You
can write into it and it will become PAGE_EXECUTE_READWRITE. It will still
be executable. If, however, you did not mark it as RWX and had instead used
RW, then it would fault as soon as the first instruction executed.
-Matt
- Previous message: spamtrap_at_crayne.org: "Re: Can't get full drive transfer rate -- what am I doing wrong?"
- In reply to: Bob Masta: "Re: NX bit versus standard permissions?"
- Next in thread: Brian Mitchell: "Re: NX bit versus standard permissions?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
