
Nobody wrote:

> On Wed, 09 Dec 2009 14:05:54 +0000, Simon Clubley wrote:
> 
> 
>>For example, you could have a model which allowed 64K of code, but allowed
>>a larger than 64K data size. (But don't ask me to remember which memory
>>model it was. :-))]
> 
> 
> Compact.
> 
> FWIW:
> 
>     Model    Data    Code
>     
>     Tiny         near
>     Small    near    near
>     Medium   near    far
>     Compact  far     near
>     Large    far     far
>     Huge     huge    huge
> 
> near = single segment, far = multiple segments without normalisation
> (pointer arithmetic only affects the offset), huge = multiple segments
> with normalisation.

Memory model just meant the type of pointers by default. It was not a 
limitation for accessible code and data spaces per se.

VLV

"Nobody" <nobody@nowhere.com> wrote in message 
news:pan.2009.12.10.17.04.54.250000@nowhere.com...
>    Tiny         near
>    Small    near    near
>    Medium   near    far
>    Compact  far     near
>    Large    far     far

Looks like a mnemonic for Double Norwich Court Bob Major!

On Wed, 09 Dec 2009 09:17:09 -0800, James Harris wrote:

>> What is so special with 'Execute Disable Bit' option and
>> why is it hightlighted so explicity in the Intel Core 2 Duo
>> processors ? Any ideas ?
> 
> They do make a fuss about a single bit don't they. In a sense it is a
> fix to a problem that didn't need to exist. Each code segment could
> have been prevented from overlapping with data but it wasn't. As much
> to the point, operating systems could have been more secure but they
> weren't.

A large part of the problem was that Windows was designed for 8086 and
Unix was designed for systems with page-level protection. The 80386 didn't
include page-level execute permission on the assumption that software
would use segments, but Unix assumes a flat address space (e.g. the
pointers returned by mmap() and passed to munmap() can be either code or
data).

> For example, why should execution of any unprivileged code
> whether it's in a buffer or not be able to subvert a system? Or why
> should a buffer overflow be able to overwrite privileged code or data?
> Neither should be possible.

In general, it can't. On both Windows NT and Unix, a buffer overflow can
only subvert that process; however, that still means that an attacker can
run code under the account in question.

Windows 95/98/ME had problems due to the bottom 1MiB of physical memory
needing to be writable by all applications, so that legacy real-mode 8086
applications worked.

OTOH, "classic" Macs  (i.e. prior to the Unix-based OSX) didn't have *any*
memory protection, yet buffer overflows were relatively uncommon, mostly
due to the use of objective-C rather than C/C++.

Linux/x86 has supported a non-executable stack since before the NX bit
was added, by making the code segment shorter than the data segment (the
stack is at the top of the user-mode address space), but this doesn't work
for the heap (which is at the bottom of the address space). However, a
non-executable stack caused problems for code which uses trampolines
(this was quite common for objective-C code), and for some emulators, so
many distributions disabled this feature.

Various compiler features can guard against buffer overflows, but they
either have a memory penalty (inserting guard pages between stack frames)
or a performance penalty (inserting canary words which are checked before
restoring the saved PC from the stack).

On Thu, 10 Dec 2009 02:23:04 +0200, Paul Keinanen wrote:

> The more or less standard practice with 32 bit OS since the 1970's has
> been 2 GiB for user data space and 2 GiB for kernel code/data.

Linux/x86 typically uses 3GiB for user-space with the top 1GiB reserved
for kernel mode.

On Wed, 09 Dec 2009 14:05:54 +0000, Simon Clubley wrote:

> For example, you could have a model which allowed 64K of code, but allowed
> a larger than 64K data size. (But don't ask me to remember which memory
> model it was. :-))]

Compact.

FWIW:

    Model    Data    Code
    
    Tiny         near
    Small    near    near
    Medium   near    far
    Compact  far     near
    Large    far     far
    Huge     huge    huge

near = single segment, far = multiple segments without normalisation
(pointer arithmetic only affects the offset), huge = multiple segments
with normalisation.

On Wed, 9 Dec 2009 14:04:13 -0800 (PST), "robertwessel2@yahoo.com"
<robertwessel2@yahoo.com> wrote:

>On Dec 8, 11:34&#4294967295;pm, Paul Keinanen <keina...@sci.fi> wrote:
>> This overlapping is a (possibly stupid) design made by the OS and
>> linker designer. Using smaller segments than 4 GiB and using separate
>> segment base address would allow protecting the code segment and
>> data+stack segment from each other.
>
>
>It's not quite that easy if you want to have a flat address space
>encompassing both your code and data - and there are very definite
>advantages to that.  

Such as ?

On a PDP-11 with separate I/D support, on a subroutine call I
preferred loosing the ability of using the (more or less useless)
R0-R5 as the parameter passing register (i.e. in-line parameters) and
be forced to use the PC as the only parameter passing register (i.e.
stack based parameter passing) when using separate I/D (64 KiB Code
and 64 KiB data space :-).

Of course, this was the days of core memory.

The situation might be different with some Harvard architecture
processors (such as PIC), in which the instruction space is in Flash
and the non-volatile data space is in RAM.

>You *can* create a code segment with a limit
>value that prevents code from executing above a certain address, and
>then mark all the corresponding pages read-only (thus the pages below
>the limit are at most execute/read, and the pages above the limit are
>read/write).  The problem is that this conflicts with the very common
>OS design of having both OS and application segments (segment != x86
>hardware segment) in the address space, but separate.  

While I fully understand the need for 32 or even 64 bit data/stack
address space for handling large data arrays, with current modular
software design methods, a 64 KiB address space should be enough,
provided that the "far" calls can be used easily.

My guess is that the reason of full code space is the frustration with
128/256/512 byte branch restrictions in most older platforms. With
current programming practices, there shouldn't be much need for
branches +/-32KiB, but instead a "far" call shouldn't be a problem.

>It would
>perhaps have been reasonable to end up with four areas in the address
>space - OS code, OS data, application code and application data (with
>both code areas below the CS limit), at the expense of additional
>fragmentation of the address space.

The more or less standard practice with 32 bit OS since the 1970's has
been 2 GiB for user data space and 2 GiB for kernel code/data.

Unfortunately, this has caused quite careless use of the virtual
space, since for example in Windows NT, it is quite hard to find at
least 100 MiB continuous address space for file mapping into virtual
address space.

On Dec 9, 11:17=A0am, James Harris <james.harri...@googlemail.com>
wrote:
> They do make a fuss about a single bit don't they. In a sense it is a
> fix to a problem that didn't need to exist. Each code segment could
> have been prevented from overlapping with data but it wasn't. As much
> to the point, operating systems could have been more secure but they
> weren't. For example, why should execution of any unprivileged code
> whether it's in a buffer or not be able to subvert a system? Or why
> should a buffer overflow be able to overwrite privileged code or data?
> Neither should be possible.


In general it cannot.  Injecting code into applications is quite
enough to do damage.

On Dec 8, 11:34=A0pm, Paul Keinanen <keina...@sci.fi> wrote:
> This overlapping is a (possibly stupid) design made by the OS and
> linker designer. Using smaller segments than 4 GiB and using separate
> segment base address would allow protecting the code segment and
> data+stack segment from each other.

It's not quite that easy if you want to have a flat address space
encompassing both your code and data - and there are very definite
advantages to that.  You *can* create a code segment with a limit
value that prevents code from executing above a certain address, and
then mark all the corresponding pages read-only (thus the pages below
the limit are at most execute/read, and the pages above the limit are
read/write).  The problem is that this conflicts with the very common
OS design of having both OS and application segments (segment !=3D x86
hardware segment) in the address space, but separate.  It would
perhaps have been reasonable to end up with four areas in the address
space - OS code, OS data, application code and application data (with
both code areas below the CS limit), at the expense of additional
fragmentation of the address space.

On Wed, 9 Dec 2009 09:17:09 -0800 (PST), James Harris
<james.harris.1@googlemail.com> wrote:

>On 8 Dec, 16:29, karthikbalaguru <karthikbalagur...@gmail.com> wrote:
>
>> Hi,
>> It seems that Intel's Execute Disable Bit functionality can
>> help prevent certain classes of malicious buffer overflow
>> attacks by allowing the processor to classify areas in memory
>> by where application code can execute and where it cannot.
>>
>> But, isn't it a normal functionality present in almost many
>> of the processors that have memory classification as
>> Read Only Memory and Read/Write Memory areas ?
>
>Beware the references to "segments" in replies. As well as being a
>generic term it is used specifically by Intel and AMD. Intel's 32-bit
>x86 architecture defines a code segment as well as a number of data
>segments. The code segment is used implicitly for instruction fetches.
>This cannot be overridden so there is a guarantee that instructions
>are fetched from the code segment.
>
>As with other segments the code segment has a base address and a limit
>so can provide security. According to AMD, however, designers of
>popular operating systems (you can guess what these might be) failed
>to make use of the code segment restrictions and made code and data
>segments overlap. As a consequence when AMD designed the 64-bit x86
>architecture they simplified the design and got rid of most of the
>segment functionality. The 64-bit modes mandate the overlap of code
>and most data segments.
>
>The older OS designs and the new 64-bit modes, therefore, had no
>protection against being told to execute code in data areas. How to
>fix it? An execute disable bit was needed. Segmentation was deprecated
>so the new bit was added in the paging structures. Execution can
>therefore be prohibited on a per-page basis.

Thanks for this explanation.  I'm intimately familiar with the P2,
having done chipset testing for Intel.  But I have not kept up.  I had
written a reply, yesterday, but hadn't posted it hoping for an
informed reply.  In that post, I had _guessed_ that the only place I
could imagine adding such a "new" feature, beyond what is already
available in the GDT and LDT, was the paging system that mediates
between linear and physical addressing.  You've confirmed my hunch.

>> What is so special with 'Execute Disable Bit' option and
>> why is it hightlighted so explicity in the Intel Core 2 Duo
>> processors ? Any ideas ?
>
>They do make a fuss about a single bit don't they. In a sense it is a
>fix to a problem that didn't need to exist. Each code segment could
>have been prevented from overlapping with data but it wasn't. As much
>to the point, operating systems could have been more secure but they
>weren't. For example, why should execution of any unprivileged code
>whether it's in a buffer or not be able to subvert a system? Or why
>should a buffer overflow be able to overwrite privileged code or data?
>Neither should be possible.

Agreed!

>Due to issues such as buffer overflow attacks the execute disable bit
>has gained a marked presence in the mind of many. This single bit
>definition has become a big selling point for CPUs from both AMD and
>Intel. Check the Intel processor manuals for full details. I think
>they are easier to read than AMDs.

That's been my experience, as well.

>By the way, I've never found a simple list of which processors support
>the bit. The official answer is to use the cpuid instruction to test
>for its presence.

Thanks very much for taking a moment.  I learned something about some
of the newer processors.

Jon