No, this is a feature created for memory-unsafe languages which has turned out to be yet another memory safety attack vector. But there's no way to prevent this.
And languages which require unsafe blocks to write any real system code.
> But there's no way to prevent this
There isn't. There are only mitigations. The environment is actively hostile.
You can try to bake them in the hardware, which has huge up front design costs, and if a vulnerability is ever found, they become useless instantly.
You can try to bake them into the language, which has moderate continual design costs, but if someone simply types 'unsafe' anywhere in your codebase they become useless instantly.
You can try to enforce them in the frame work of your own code, which has moderate up front design costs, is possibly less reliable than the other methods, but they can be changed and redeployed when vulnerabilities are discovered.
These problems don't go away simply because you made a particular hardware or language choice. You can't sweep this engineering under the rug and then act like your software is more secure than anything else.
Oh no, I meant that this feature was made so people could continue to use memory-unsafe languages, but it turns out to be defeatable. If only there was some way to prevent this.
This is not a bug caused by memory unsafe languages.
No, this is a feature created for memory-unsafe languages which has turned out to be yet another memory safety attack vector. But there's no way to prevent this.
> for memory-unsafe languages
And languages which require unsafe blocks to write any real system code.
> But there's no way to prevent this
There isn't. There are only mitigations. The environment is actively hostile.
You can try to bake them in the hardware, which has huge up front design costs, and if a vulnerability is ever found, they become useless instantly.
You can try to bake them into the language, which has moderate continual design costs, but if someone simply types 'unsafe' anywhere in your codebase they become useless instantly.
You can try to enforce them in the frame work of your own code, which has moderate up front design costs, is possibly less reliable than the other methods, but they can be changed and redeployed when vulnerabilities are discovered.
These problems don't go away simply because you made a particular hardware or language choice. You can't sweep this engineering under the rug and then act like your software is more secure than anything else.
3 replies →
Memory safe languages contain memory bugs as soon as eg you want them to be fast enough to implement a JIT.
The only exception is if the microcode responsible for this was written in C somehow. I highly doubt it though.
Oh no, I meant that this feature was made so people could continue to use memory-unsafe languages, but it turns out to be defeatable. If only there was some way to prevent this.
That's the point. /s