Hacker News new | past | comments | ask | show | jobs | submit
GTP | on: AI is forcing us to pay off 40 years of technical debt
Basically, have an explicit distinction between data and code at the architectural level, to enforce "Write xor Execute" in hardware. In this way, you would prevent e.g. a buffer overflow letting an attacker injecting shellcode that gets executed later by somehow pointing at it. AFAIK the issue would still remain with some programming languages though.
sznio | parent | next
don't we already have the NX bit?

and it's not sufficient anyways. even with NX you could have the attacker control a function pointer you call. in any sufficiently complex program you'll have enough widgets to build anything you want just out of data.

code and data are the same thing. whatever inputs your system receives is "code" that your application interprets, just like your application is the code that the CPU interprets. turtles all the way down.

intrasight | root | parent | next
In a Harvard architecture, it's not possible to point the CPU at data.
TeMPOraL | root | parent | next
But that's just irrelevant confusion of terms.

There is no fundamental distinction between code and data. This separation does not exist as category in actual reality (and I vividly remember that being one of the bigger points GEB made, early on). They're fundamentally one and the same, and classifying some bits as data and some as code is a point of view that really depends on what you're doing and why.

As for Harvard architecture - every time you branch on your "data", you're effectively executing it, and your "code" can be seen as emulating a system where your "data" is the actual code.

rootlocus | root | parent | next
So JIT is not possible on a Harvard architecture?
| root | parent
{"deleted":true,"id":50373944,"parent":50371103,"time":1793842601,"type":"comment"}
mxey | root | parent
What about return oriented programming?
ihavesomeexampl | parent | next
But.. alter data that gets executed (interpeter?), I mean, how does this work even in theory? All data is potentially code?
AdamH12113 | root | parent | next
To clarify what intrasight is talking about: A Harvard architecture CPU has two physically separate memory busses for code and data. This makes it possible to build a computer with a program memory that cannot be altered through the data bus. In practice, this isn't normally done -- even on Harvard architecture microcontrollers, the flash and RAM are connected to both busses because memory is expensive. And having inalterable program memory doesn't save you from stack-smashing attacks that alter a return address.
intrasight | root | parent
All data is potentially code only in a Von Neumann architecture, but not in a Harvard architecture, where there's a separation of data and code with different memory access to each.
esterna | root | parent | next
Code and data being equivalent is a consequence of Turing completeness; you can always write a Python interpreter, point it at "data" and have it execute that via interpretation.
lelanthran | root | parent
> All data is potentially code only in a Von Neumann architecture, but not in a Harvard architecture, where there's a separation of data and code with different memory access to each.

Says you. I wrote a program for a Hardvard architecture chip (PIC) that read bytecode from the data memory and executed it. Updates were made by replacing the data block with a new data block.

In practice, there is no way to separate data and instructions. After all, JS downloaded inside a webpage is literally data, and it gets executed.

tosapple | parent | next
and we don't believe a sterilized virtual machine creates a similar situation?

any respective machine doesn't require full Turing completeness?

any ad-hoc machine allows for mutations and flexibility, which I'm sure is an added strength.

2nd edit,

Also, didn't we have a weaker model of this with segmented non-flat memory models on i386-

AlienRobot | parent
How do you turn text into code in this architecture? Through the kernel?
SSLy | root | parent
you don't. I also believe that JITs would be impossible under strict Harvard.
AlienRobot | root | parent
Wait, how do you create programs then? How do you compile?

That doesn't even make sense, to be honest. Interpreted languages like Python aren't running machine code. They are taking data and executing machine code based on the data. Is Python safe?

thephyber | root | parent | next
According to Wikipedia, Modified Harvard Architecture is a common thing and appears to have properties of both Harvard and Von Neumann architectures. It's probably worth discussing a specific device, OS, and programming language rather than having a vague discussion where both parties are constantly describing different goalposts.

It's not that hard to imagine that in a specific embedded device the kernel / compiler have access to write to the instruction memory space while user space programs don't have any API / permissions to do that.

loading story #50376639
SSLy | root | parent | next
My understanding is that all hard-Harvards are special-purpose ROM-driven systems with static payloads developed on von Neumann computers.
AdamH12113 | root | parent | next
This sort of thing is much more common in microcontrollers, where the code is cross-compiled on another computer and written to flash memory through a debug interface.

In practice, it's usually possible to write to the embedded flash memory via software, but it's much more difficult and disruptive than a simple CPU memory access.

Merad | root | parent
A compiler writes machine code do a file. The OS then loads the code from the file into executable memory before it runs the program. The compiler isn't actually trying to execute the machine code it produces. This is why a JIT wouldn't work - the JIT bypasses the interpreter and produces machine code _that executes directly on the CPU_ inside of the same app.

I don't know any details about Python's architecture, but it's totally possible to write an interpreter for machine code; that's basically what an emulator is. The trade off is that pure interpreters tend to be very slow.

loading story #50376656
loading story #50372174