I agree.
But the butthurt side of me wants to say: let those who wish for unsafety be unsafe.
But the butthurt side of me wants to say: let those who wish for unsafety be unsafe.
You would not say: Let those [civil engineers] who like unsafe bridges build unsafe bridges
Because the people using them might not be able to judge the unsafety of the system. Because the work of programmers multiply we have a huge responsibility and a huge chance to improve the world.
Edit: and there is no way to prevent that damage except by detailed planning and by stopping to cut when the patient (under local anestesia) ceases talking or performing their craft. Other damage can only be detected later though.
It’s like you have gone out of your way to prove the opposite point of what you were ostensibly trying to prove.
I really doubt we are every going to see a "hardened C++" making any inroads, but at least I find that slightly more plausible than any other new language displacing it.
Trying to do otherwise will trap.
If your system provides a special allocator that actually does tell the hardware which allocations correspond to which object then that's nice (and not a new thing... many lisp machines had this, plus x86 segmentation, etc.), but it really does not prevent and cannot prevent a process using the allocated memory however it sees fit. The only thing that could is throwing turing-completeness out of the window.
Yes, (ancient) x86 segments are a form of memory tagging. I always found it ironic that many people complain about "the PDP-11 memory model" and yet we already had a popular architecture trying to get away from it.. only to result in one of the most hated memory models ever. While you can definitely do better, I am skeptical that any new type of memory tagging is going to improve significantly on it.
I think pjmlp is referring to this: https://msrc-blog.microsoft.com/2022/01/20/an_armful_of_cher...
In order to create a system where you can't have a way to avoid bounds checking (as the above post was claiming), you would basically have to throw turing-completeness away, e.g. by preventing the implementation of arrays, lists, etc. The moment you can implement practically any data structure whatsoever, you can use it to build an allocator on top of it (through a heap... or not), and then proceed to access each (sub)object allocated by it without any bounds checking whatsoever. From the point of view of the hardware/OS, you will only have one large object. This is literally how most user programs work today (from the point of view of the hardware/OS).
You can provide a system allocator that tags objects separately as you allocate, but there is no way to prevent a user program from managing its own memory as it sees fit.
Pretty much possible and already available for those listed above, with Solaris having a decade of experience in production.
However it is now being combined with ARM technology to provide such capabilities in selected Windows devices.
https://blogs.windows.com/windowsexperience/2022/02/28/mwc-2...
If a process wants to commit suicide, there is hardly anything that can be prevented I guess.
These measures prevent access to the tagging metadata from userspace, that is how they prevent it, and usually MMU isn't accessible to userspace.
> By using spare bits in the cache and in the memory hierarchy, the hardware allows the software to assign version numbers to regions of memory at the granularity of a cache line. The software sets the high bits of the virtual address pointer used to reference a data object with the same version assigned to the target memory in which the data object resides.
> On execution, the processor compares the version encoded in the pointer and referenced by a load or store instruction, with the version assigned to the target memory.
https://docs.oracle.com/cd/E86824_01/html/E54766/adi-3c.html...
Now if one goes out of their way to work around security mitigation and enjoy the freedom of corrupting their data, maybe they should ask themselves if they are on the right business.
You mean PAC. PAC does not really do what you think it does; the original program can still corrupt its data as much as it wants (even due to bugs). And I don't think it has anything to do with Pluton.
> If a process wants to commit suicide, there is hardly anything that can be prevented I guess.
> Now if one goes out of their way to work around security mitigation and enjoy the freedom of corrupting their data, maybe they should ask themselves if they are on the right business.
No; what I have been trying to do for the entire comment chain is to show that this is how things work _right now_ (the entire process' memory being a single opaque object/blob with the same tag), and that for obvious reasons you cannot forbid that and just claim that "there will be NO alternative" because you will always be able to continue doing what everyone is doing _right now_, barring a significantly upheaval in the traditional definitions of computing.
If you provide an allocator that integrates more closely with the hardware then that is all and fine, but you just _cannot_ claim there will be no alternative specially when the alternative is just to continue what you're doing right now.
Again, we've had many architectures with memory tagging, hardware bounds checking, whatever you can think of. E.g. even x86 had memory tagging at a time (386 segmentation which was globally panned), hardware bounds checking (MPX, completely ignored due to the reduced performance), etc.
And is one of the drivers to have memory hardware tagging enabled in all devices, just like Microsoft is doing with Pluton, Oracle has been doing for a decade with Solaris SPARC, and Apple is adding to their ARM flavours as well.
What stops the engineer from building bridges are the law regulations and his work environment. This regulations and work environment exists in programming too.
Regulations and work environments seem to not exist to a sufficient degree in programming to prevent the sort of errors that efforts like from TA are directed against. The attitude of many programmers towards testing would be considered reckless in many other domains.
On the other hand, compilers and IDEs have very much become part of our work environment and should help as much as feasible in avoiding as many errors ahead of time.
We might also put construction engineering on too much of a pedestal here. Bridges are very well-defined artifacts that humans have been building for centuries. How well exactly are we doing with other infrastructure projects?