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.
> And languages which require unsafe blocks to write any real system code.
The difference you've missed is cultural. Rust's unsafe blocks just denote code which the compiler can't check, which if you have the appropriate culture makes those blocks a focus for human oversight in a way which cannot be sustained in the legacy languages where the whole codebase has the same problem.
Also, there's a lot of security and performance critical code which isn't "real system code" by this weird definition. Whole domains where it's just greed and stupidity versus a correct solution with better performance, and yet the greed and stupidity gets ahead as often as not. Depressing.
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.
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.
> And languages which require unsafe blocks to write any real system code.
The difference you've missed is cultural. Rust's unsafe blocks just denote code which the compiler can't check, which if you have the appropriate culture makes those blocks a focus for human oversight in a way which cannot be sustained in the legacy languages where the whole codebase has the same problem.
Also, there's a lot of security and performance critical code which isn't "real system code" by this weird definition. Whole domains where it's just greed and stupidity versus a correct solution with better performance, and yet the greed and stupidity gets ahead as often as not. Depressing.
2 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