Re: Overview Of New Intel Core i7(Nehalem) Processor

On Thu, 11 Jun 2009 17:54:37 -0700 (PDT), MooseFET
<kensmith@xxxxxxxxx> wrote:

On Jun 11, 5:18 pm, John Larkin
<jjlar...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
On Thu, 11 Jun 2009 15:42:01 -0700 (PDT), MooseFET



<kensm...@xxxxxxxxx> wrote:
On Jun 11, 1:32 pm, John Larkin
<jjlar...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
On Thu, 11 Jun 2009 06:31:19 -0700 (PDT), MooseFET

<kensm...@xxxxxxxxx> wrote:
On Jun 10, 7:41 pm, John Larkin
[....]

If x86 had serious i/d space separation, and Microcrap used it, all
sorts of exploits would be impossible.

Code space being in different chips, on a different bus is the ideal.
The memory can be logically divided into sections and security can be
good, however, it requires that the hardware prevent the application
from causing the memory usage to change.  If the x86 segmentation
didn't have mistakes in how it was done, it could have worked for
this.  It would still be a pigs breakfast but it would have worked.

Ideally, there should be two stacks, one for the return addresses and
a different one for the passed parameters and local variables.  The
processor could have the parameter stack protected against accesses
beyond the limit of what is permitted for the current subroutine.
This boundary number would automatically be updated on a return.

Yes. C mixes up parameters, local variables, buffers, pointers, and
return addresses all on the same stack. Then apparently interleaves
stacks in the same address space as the subroutine code itself!
There's no way to apply hardware memory-management protections to a
tangled mess like that.

There is nothing about the C language that requires this.  C doesn't
allow for returns to places other than where you were called from and
the parameter stack doesn't have to contain the return addresses.

Right. It has occurred to me that Microsoft's compilers and linkers
create such messes. Passed params and such could easily be in buffer
pools (in *data* space) that are not on the stack. Of course,
Microsoft would arrange for memory leaks in managing the buffers.

Just making parameter/local space its own stack would make things a
lot better. Since the x86 can do a DS:(DI+X) style addressing, the
hardware could do it. It would just be a matter of compiler design.


C is just a klugey PDP-11 assembler. In the early PDP-11 days, a lot
of dangerous tricks were popular, based on abusing the 11's addressing
modes. C seems to have inherited them.

There were mistakes in the design of C that people have gotten so used
to that they now believe that it is how things are supposed to be.
One of the biggies is if you declare a native type, the variable name
is the value. On complex types, the variable name is a pointer. It
would be better if the syntax made it clear what the nature of the
variable is.


Umm, what's wrong with subscripts? And bounds checking?

John


.

Relevant Pages

  • Re: XP sometimes balks on boot-up
    ... to catch this trap. ... Memory corruption, other hardware ... The most common cause of this is hardware memory corruption. ... A kernel stack overflow. ...
    (microsoft.public.windowsxp.general)
  • Re: a dozen cpus on a chip
    ... It is still possible to write something that will crash, ... memory, or write to memory it doesn't own should be terminated with a ... I think that hardware designers could do a lot to improve matters. ... Having a call-return stack, a parameter stack, return value area, and ...
    (sci.electronics.design)
  • Re: Overview Of New Intel Core i7(Nehalem) Processor
    ... The memory can be logically divided into sections and security can be ... return addresses all on the same stack. ... the parameter stack doesn't have to contain the return addresses. ...  There is nothing that requires only one CPU do ...
    (sci.electronics.design)
  • Re: Overview Of New Intel Core i7(Nehalem) Processor
    ... The memory can be logically divided into sections and security can be ... return addresses all on the same stack. ... the parameter stack doesn't have to contain the return addresses. ...  There is nothing that requires only one CPU do ...
    (sci.electronics.design)
  • Re: Overview Of New Intel Core i7(Nehalem) Processor
    ... The memory can be logically divided into sections and security can be ... return addresses all on the same stack. ... the parameter stack doesn't have to contain the return addresses. ... Run the OS in its own CPU! ...
    (sci.electronics.design)