I belive this is what was attemped in France (they taught set teory in an abstract way in elementary school), but with poor results and abandoned this approach after some time.
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.
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.
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.
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.
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.
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.
> 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.
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?
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.
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.
> 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.
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.
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.
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".
AFAIK Ubuntu still ships newer versions. Maybe this is just because it ships new distro versions more frequently, but the end result would still be having newer packages on the latest Ubuntu release vs the latest Debian stable. I'm not an user of either distros though, so I'll wait for someone that actually uses them to confirm/rebut.
Not sure about this, isn't it hard to convert to fiat currency for real-world spending? Since it is often used for illegal activities, Coinbase (and I guess other big exchanges as well) don't trade it.
Yes, it’s a currency swap. You need to find another person (such as a bank, or in crypto parlance, a “defi”) willing to take what you have and trade you what you want.
Yes, there are even semi-decentralized exchanges based on smart contracts, where you can find trade offers posted by others and execute them in a zero-trust way.
> Cash can also be stolen if someone takes your wallet, leaving you no recourse except the law
The issue that is often raised with Bitcoins and other cryptocurrencies is that not even the law can help you in case of theft. Now, it's true that the police wouldn't bother helping me recover a wallet with 100€ into it, but things change if someone steals millions or even billions like in this case.
I wait for Netflix (and other streaming services) to be fined due to their users accessing content that shouldn't be available in a certain territory via a VPN.
isn't that precisely why they block most VPNs now? I worked for one, and all of our content licensing agreements stipulated that we had to block VPNs, and which vendors were allowed to give us the list of VPN addresses to block. (it's Digital Element, by the way.)
Of course, we weren't liable for failing to block any VPN address not on the list, but we also weren't allowed to not block an address that was on the list, which resulted in customer complaints.
reply