Re: far pointer

CBFalconer wrote: 
Malcolm wrote:

"pete" <pfiland@xxxxxxxxxxxxxx> wrote


I'm reading Malcolm as being wrong.
The restriction that pointers must be calculated within the
object, has nothing to do with comparing pointers for equality.


Example restored.

/* OK */
int x[256];

int *ptr1 = x;
int *ptr2 = x + 128;

while(ptr2 != ptr1)
 ptr2--;

/* silly game, may work as expected may go horribly wrong */
int x[128];
int y[128];

int *ptr1 = x;
int *ptr2 = y;

while(ptr2 != ptr1)
 ptr2--;

These could easily compile to exactly the same machine code.
What the hacker who wrote the second example is relying on is that
array y is probably next to array x in memory. As he decrements,
ptr2 will eventually count down to ptr1, which is the start of x.
If we write a value as we loop, array x will be set.

Unfortunately, it could happen that x and y are in different
segments on a DOS machine. Therefore the array will be set, as
before, but the loop won't terminate properly because ptr1 and ptr2
don't compare as equal, despite pointing to the same physical
location. This only happens because we've managed to defeat C's
pointer management system. It can't happen if we do things properly,
as in example 1.



It's worse than that, and doesn't require segmented memory.  There
is no guarantee, even given a stack machine (which we are not) that
x is assigned space above (or below) y. It is likely (but again not
guaranteed) that one of those two cases will apply.

On the DS9000 the direction is the opposite of whatever you test,
and all i/o is memory mapped. There is no memory access violation
for this run. The act of pointing to an i/o location causes a
default set of 1's to be written for efficiency reasons. A 1 bit
launches a missile. For safety reasons the designers have required
confirmation with a matching 1 bit in the 127 adjacent locations. Now, if you guess wrong, all missiles are launched.

Sounds like the Safety mechanism still needs work. The Security side is rock solid. There is no way to find out where the launching missles are coming from or where they are going. :-)

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
                    --- Albert Einstein ---
.

Relevant Pages

  • Re: Dusty Deck and C memory manager, Part 1
    ... CMEMC.C -- C memory management routines for use with FORTRAN. ... Return an index into ARRAY representing LENGTH words of available ... void *ptr, *malloc; ... Rather than introduce Cray pointers and use C routines to allocate memory for Fortran arrays, you could use straight F90, for example: ...
    (comp.lang.fortran)
  • Re: Simple C containers, std::vector analog
    ... You're right about not needing to care very much about the memory ... blocks, in not knowing the ultimate size of the growable array, because ... there is no realloc function, and besides realloc might be having ... whether it's used for the list of array block pointers only or a C++ ...
    (comp.lang.c)
  • Re: Differance between Array and Pointers
    ... Well, except that arrays tend to be much larger than pointers, and the ... An array is a contiguous region of memory containing N elements of M ... indexing vs. a loop). ...
    (comp.arch.embedded)
  • Re: Array of Pointers
    ... > Gerald wrote: ... >> I have a problem with an array of pointers. ... > complex) data structure than a simple array to do this efficiently. ... I'm aiming for accuracy, speed and low memory use, in that order. ...
    (comp.lang.c)
  • Re: far pointer
    ... has nothing to do with comparing pointers for equality. ... > array y is probably next to array x in memory. ... and doesn't require segmented memory. ...
    (comp.lang.c)