Hacker News
points by thephyber 3 days ago | 0 comments
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.

[–] AlienRobot 3 days ago
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.

[–] thephyber 2 days ago
> 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.

This is clearly wrong in the sense that you allow your users to submit data to your website via a form, but you shouldn't trust that data in an `eval(...)` statement.

There is value in logically separating data / instructions. Having a physical separation may reduce some categories of bugs / security problems. Obviously as you rightly point out that the memory full of instructions has to get populated sometime, but when, how often, by whom, and with what safeguards are all relevant questions to the overall security of the model.

I think we generally agree, but you are taking the "code is just data" entirely too far to the point that you are blinding yourself to the value of the gradations in the middle.