An interesting thought: The top three types of computer security failings 
all come from having violating an abstract Harvard architecture abstraction 
implemented on top of a Von Neumann machine.  That is, buffer overrun, 
cross-site scriping, and SQL injection all happen on systems where the 
underlying implementation language treats code and data as if they're in 
separate address spaces and yet allows that abstraction to be broken in 
order to execute data as code. The work-arounds for all these problems 
consist of ensuring one does not break the Harvard abstraction's implementation.

For example, consider how much safer SQL would be if it was configured to 
only run prepared statements invoking stored procedures. And I daresay that 
buffer overruns were much less damaging in the days when the code was 
addressed via the code segment and the stack was addressed via the stack 
segment. (Not entirely safe from buffer overruns, mind, but much safer.)

The whole thing of DEP and base address randomization is a lame attempt to 
enforce the Harvard architecture to a greater degree without having to fix 
the unsafe languages.

-- 
Darren New, San Diego CA, USA (PST)
  "How did he die?"   "He got shot in the hand."
     "That was fatal?"
          "He was holding a live grenade at the time."

Post a reply to this message

On 2/15/2011 11:40 AM, Darren New wrote:
> An interesting thought: The top three types of computer security
> failings all come from having violating an abstract Harvard architecture
> abstraction implemented on top of a Von Neumann machine. That is, buffer
> overrun, cross-site scriping, and SQL injection all happen on systems
> where the underlying implementation language treats code and data as if
> they're in separate address spaces and yet allows that abstraction to be
> broken in order to execute data as code. The work-arounds for all these
> problems consist of ensuring one does not break the Harvard
> abstraction's implementation.
>
> For example, consider how much safer SQL would be if it was configured
> to only run prepared statements invoking stored procedures. And I
> daresay that buffer overruns were much less damaging in the days when
> the code was addressed via the code segment and the stack was addressed
> via the stack segment. (Not entirely safe from buffer overruns, mind,
> but much safer.)
>
> The whole thing of DEP and base address randomization is a lame attempt
> to enforce the Harvard architecture to a greater degree without having
> to fix the unsafe languages.
>
Ah.. So, we should fix the problem created by adding flexibility to the 
languages, so we can do more than pre-tested, pre-coded, very strict 
things, by getting rid of all the flexibility? Somehow that seems... 
kind of problematic. lol

-- 
void main () {
   If Schrödingers_cat is alive or version > 98 {
     if version = "Vista" {
       call slow_by_half();
       call DRM_everything();
     }
     call functional_code();
   }
   else
     call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models, 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

Patrick Elliott wrote:
> Ah.. So, we should fix the problem created by adding flexibility to the 
> languages, so we can do more than pre-tested, pre-coded, very strict 
> things, by getting rid of all the flexibility? 

No. If your language assumes you can't cast an arbitrary pointer to a 
function's address (for example), you can enforce (or mostly enforce except 
where you declare that you recognise you're bypassing it) that and get a 
more secure system. If your language assumes you're not on a harvard 
architecture (i.e., assumes that code and data live in the same address 
space), then you can take advantage of that and wind up with things like 
javascript and lisp.

The security failure comes from environments that assume, but don't enforce, 
that data isn't executable.

But really, my original point was descriptive rather than proscriptive.

-- 
Darren New, San Diego CA, USA (PST)
  "How did he die?"   "He got shot in the hand."
     "That was fatal?"
          "He was holding a live grenade at the time."

Post a reply to this message

On 15/02/2011 06:40 PM, Darren New wrote:
> An interesting thought: The top three types of computer security
> failings all come from having violating an abstract Harvard architecture
> abstraction implemented on top of a Von Neumann machine.

I've often wondered how a Harvard architecture machine would actually 
work. How do you get stuff into the code address space?

(I presume that the Harvard architecture isn't just theoretical, and 
that people have actually built hardware this way...)

> The whole thing of DEP and base address randomization is a lame attempt
> to enforce the Harvard architecture to a greater degree without having
> to fix the unsafe languages.

Backwards compatibility is evil.

Post a reply to this message

Invisible wrote:
> I've often wondered how a Harvard architecture machine would actually 
> work. How do you get stuff into the code address space?

http://lewisshepherd.files.wordpress.com/2010/08/ibm-402-plugboard.jpg

And that picture tells you why von Neumann's invention was hailed as an 
incredible time-saver.  That's probably a program approximately as complex 
as "add up the difference of these two columns of numbers." E.g., for 
balancing an accounting ledger, as in show the difference between the sum of 
the credits and the sum of the debits.

Alternately, you have a ROM in one half and a RAM in the other half of the 
address space, and you don't let the program counter into the second half of 
the address space.

Or actual hardware nowadays - do any of *your* programs write the the microcode?

Machines with changable microcode normally loaded the microcode off a 
special device (e.g., a floppy disk) when they booted, and the actual 
running program couldn't do so.

> (I presume that the Harvard architecture isn't just theoretical, and 
> that people have actually built hardware this way...)

http://en.wikipedia.org/wiki/Unit_record_equipment

http://bit-player.org/2006/05

Turing machines are harvard architecture abstractions.

Plus, as I said, you're using a harvard architecture machine right now, 
except the code part of the address space is in silicon wiring rather than 
1/0 bits. Microcode (including what the 6502 had, for example) is harvard 
architecture too.  You've never seen of a hacker finding a hole that lets 
them change the meaning of assembly language instructions.

>> The whole thing of DEP and base address randomization is a lame attempt
>> to enforce the Harvard architecture to a greater degree without having
>> to fix the unsafe languages.
> 
> Backwards compatibility is evil.

Yes it is.

Note that while assembly language is not technically "unsafe", it most 
definitely needs to be von neumann for any normal general purpose computer, 
or you wouldn't be able to have any sort of JIT, compiler, demand paging, 
etc.  The only place you don't need von neumann architecture is where you 
have a single-purpose device or a device where you're willing to change the 
hardware to change the behavior.

-- 
Darren New, San Diego CA, USA (PST)
  "How did he die?"   "He got shot in the hand."
     "That was fatal?"
          "He was holding a live grenade at the time."

Post a reply to this message

On 2/16/2011 8:19 PM, Darren New wrote:
> Patrick Elliott wrote:
>> Ah.. So, we should fix the problem created by adding flexibility to
>> the languages, so we can do more than pre-tested, pre-coded, very
>> strict things, by getting rid of all the flexibility?
>
> No. If your language assumes you can't cast an arbitrary pointer to a
> function's address (for example), you can enforce (or mostly enforce
> except where you declare that you recognise you're bypassing it) that
> and get a more secure system. If your language assumes you're not on a
> harvard architecture (i.e., assumes that code and data live in the same
> address space), then you can take advantage of that and wind up with
> things like javascript and lisp.
>
> The security failure comes from environments that assume, but don't
> enforce, that data isn't executable.
>
> But really, my original point was descriptive rather than proscriptive.
>
Yeah. Was taking it as proscriptive to make a joke of it. Still, would 
think there could be some sort of middle ground. Like.. checking that 
the code you are about to change from data to code isn't going to do 
something unexpected, or, if it does try to, it hits a wall (i.e., can't 
allocate the memory needed to muck things up). Always amazed me how many 
of these stupid things where a case of, "Someone put more data in the 
thing that normal, but changed X parameter, so it 'looked like' it was 
smaller, but the buffer wasn't smart enough to realize that the data was 
10k bigger than what the packet 'claimed' it contained." Uh, huh.. Got 
your Comp Sci degree from Liberty U did you, and just assumed God 
wouldn't let it happen, or something? lol

Mind, a lot of this comes from the, as previously described by someone 
else in a thread here, habit of companies assuming that you can find all 
these things, when you hacked together a "show model", with lots of 
short cuts, and suddenly got told it had to become a production model in 
50% of the time you told them it would actually take (since, obviously, 
you could show them what it did, so it much be almost finished!).

-- 
void main () {
   If Schrödingers_cat is alive or version > 98 {
     if version = "Vista" {
       call slow_by_half();
       call DRM_everything();
     }
     call functional_code();
   }
   else
     call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models, 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

> Ah.. So, we should fix the problem created by adding flexibility to
> the languages, so we can do more than pre-tested, pre-coded, very
> strict things, by getting rid of all the flexibility? Somehow that
> seems... kind of problematic. lol

Well, the C language does not specify that pointers to objects ("data
pointer", incl. void*) can be converted to function pointers nor vice versa.

The POSIX environment enforces this to allow library calls such as
dlsym() that does not distinguish between object pointers and function
pointers. But you cannot change the interface into dlsym_obj()
(returning a void*) and dlsym_func() because C does not have the concept
of generic function pointers and function pointers of different types
cannot be "converted" into each other.

I've used C (with a subset of C++ that was implemented in their
compiler) on a DSP that uses data pointers that have a different size
(and underlaying semantics) than function pointers:

http://roker.spamt.net/c++/datatypes_c55x.png

The same thing as in the MEDIUM or COMPACT memory model used in good-old
DOS ages. :-)

So don't blame (the inventors of) C, but blame the UNIX/POSIX guys who
"invented" the flat memory model and seduced legions of C programmers to
expect that "pointers are integers" and so on…

Lars R.

Post a reply to this message

On 4/19/2011 0:24, Lars R. wrote:
> Well, the C language does not specify that pointers to objects ("data
> pointer", incl. void*) can be converted to function pointers nor vice v
ersa.

As I said a while back, C (and C++) has a harvard architecture.

> http://roker.spamt.net/c++/datatypes_c55x.png

The Xerox 560 (aka Sigma 9, the computer that sent people to the moon) ha
d a 
different size pointer for each thing you could point to. A char* was 19 

bits, a long* was 17 bits, etc.  You could cast them all to integers and 

back, especially if you shifted the long* to the left, so you could still
 
come up with something not too dissimilar from what C programmers expect.
 
You couldn't union a long* and a char* and expect not to get faults if yo
u 
did it wrong.

The Burroughs B series tagged the actual hardware data, so all you had wa
s 
"pointer", and whatever it pointed to determined what the operation was. 
In 
other words, there was only an "add" instruction, and the contents of the
 
memory that the index registers pointed to determined whether you were 
adding ints, floats, array indexes, or whatever. Plus, all the array boun
ds 
were checked in hardware.  I don't think they ever ported C to that.

I worked on an HP machine where each allocation was in its own address 
space. I don't remember the details because I only actually used HLLs the
re, 
but again, it's one of those things that in theory C would be able to 
support but in practice most programs wouldn't.

> So don't blame (the inventors of) C, but blame the UNIX/POSIX guys who
> "invented" the flat memory model and seduced legions of C programmers t
o
> expect that "pointers are integers" and so on…

I think the equally flawed abstraction is having the stack and the heap i
n 
the same address space. That makes it really hard to implement on somethi
ng 
where accessing those are separate sets of operations.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

Am 19.04.2011 18:10, schrieb Darren New:
> On 4/19/2011 0:24, Lars R. wrote:
>> Well, the C language does not specify that pointers to objects ("data
>> pointer", incl. void*) can be converted to function pointers nor vice
>> versa.
> 
> As I said a while back, C (and C++) has a harvard architecture.

Not by definition. The machine model of C and C++ just does _not_
require a von-Neumann architecture. :-D

>> http://roker.spamt.net/c++/datatypes_c55x.png
> 
> The Xerox 560 (aka Sigma 9, […])
> The Burroughs B series […]

Thanks for the examples of "unusual" architectures! I still need some
exotic or awkward ones for the C++ course I'm lecturing. :-)

> I worked on an HP machine […]

Which one?

> I think the equally flawed abstraction is having the stack and the heap
> in the same address space. That makes it really hard to implement on
> something where accessing those are separate sets of operations.

Well, the "SMALL" memory model in DOS did nearly the same: Different
segments for code, stack and heap. And every current x86 CPU still uses
segmentation for every memory acces in 16- or 32-bit operation modes.
But AFAIK OS/2 2.x was the last OS that used segments explicitly, all
successors implement a "flat memory model", which was IMHO not an
advantage but a retrograde step and a prostration to lazy (or
incompetent?) C programmers. :-/ Hence we had the imprudent invention of
"NX bit" and similar things.

Sad mad world…

Lars R.

Post a reply to this message

On 4/19/2011 11:50, Lars R. wrote:
>> As I said a while back, C (and C++) has a harvard architecture.
>
> Not by definition. The machine model of C and C++ just does _not_
> require a von-Neumann architecture. :-D

Well, yes, by definition. You can't write to executable code in C. You ca
n't 
change the running program in C. Data and code are in separate address sp
aces.

In practice, no. But by definition, yes. :-)

Now, the fact that your hardware doesn't *enforce* that doesn't reflect o
n 
C. The fact that the operating system can escape out of C in order to scr
ew 
with the return stack contents and the memory mapping in order to change 
the 
executable code of a process at runtime doesn't mean that's something you
 
can do with C.  The fact that you can use undocumented compiler-specific 

behavior to cast a data pointer to a code pointer doesn't mean it's a C 
language feature.

Here, have a C interpreter. Now tell me how to write some C code that 
changes what code can run while it's running.

Perhaps we're saying the same thing. C doesn't require a Harvard 
architecture because you can simulate a harvard architecture on a von 
neumann architecture. C doesn't take advantage of a von neumann 
architecture, and indeed the biggest security hole in computer science is
 C 
(and others) running on von neumann hardware emulating a harvard 
architecture but not enforcing it. (Aka buffer overrun code injection, et
c)

>>> http://roker.spamt.net/c++/datatypes_c55x.png
>>
>> The Xerox 560 (aka Sigma 9, […])
>> The Burroughs B series […]
>
> Thanks for the examples of "unusual" architectures! I still need some
> exotic or awkward ones for the C++ course I'm lecturing. :-)
>
>> I worked on an HP machine […]
>
> Which one?

Oh, got me. 46xx maybe, is the only thing that comes to mind 30 years lat
er, 
but don't even believe that. :-)

To be fair, the X560 wasn't really what you'd call an unusual architectur
e. 
It just had an odd way of specifying pointers.

> a prostration to lazy (or incompetent?) C programmers.

I wouldn't say that. C says you can have a single int* pointer variable 
point to either automatic (i.e., stack-allocated) or heap allocated data.
 
It's built into the language that the same code has to work for both.

Now, if you put the segment register into the variable, sure, you can do 

that on the 8086. But then you have 32-bit pointers.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message