upvote
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?

reply
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.

reply
I see. I guess this does solve the issue of a program managing to insert arbitrary machine code on an address and point the CPU at it, or replacing the memory where the machine code already exists. But I think there already exists OS-level protections against writable executable memory?

It also doesn't solve one important attack vector: the existing executable has logic that can be used maliciously (e.g. a function that sends a file to the internet), and this logic is executed based on data on memory. In this case you only need to manipulate the data, without manipulating the "code", in order to exploit it.

I'm not sure I understand why would you need special hardware for that.

I think that the principle of "code is data" is that data influences the algorithms either way, so there is not much of a point in separating the two.

reply
My understanding is that all hard-Harvards are special-purpose ROM-driven systems with static payloads developed on von Neumann computers.
reply
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.

reply
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.

reply
Yes, and that's my doubt. Compiling is turning data (text) into code (something executed by the CPU). I thought the point of the hardware is that data can't become code. If data can become code, then data is code, and it doesn't matter if the data is compiled first or interpreted at runtime. There doesn't seem to be a way to prevent "data" from becoming "code".
reply
> why a JIT wouldn't work

Uh? It would work via a file - as AOT.

reply