Yes, a comment mentions something that I have seen more than once in practice: project use bound-checked access on std::vector, but it was too slow, so instead people turn to calling data() to get a raw pointer and use operator[] on that one which removes all possible form of safety.
They won't have any alternative when running in platforms with hardware memory tagging, it will be only a matter of time until all new mainstream OSes are only available in such form.
Obviously they would have an alternative, you can just mark all your memory with the same tag. Object tagging in hardware is practically as old as... lisp?
Certainly you still can. It's not like the kernel is going to forbid a user process from using its memory to arrange a heap (or anything else) in any way it wants.
I think we are miscommunicating here, because you are claiming something which is obviously impossible. What is going to prevent a process from _writing to AND reading from its own memory_ exactly? Its "own memory" may be anything including potentially a large object of size "MAXMEM" that it just got from the system, which the program is then going to arrange into any way it likes and which is going to include a heap and vectors and whatever. This is not a ridiculous over-the-top example, this is literally how most programs under most operating systems work these days...
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.
Which is still object-granularity memory tagging, and under no circumstances it can prevent a program from using its own memory any way it wants (e.g. by simply never requesting more than one object), and they obviously don't even claim to do so.
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.
How would any of these prevent a process from doing whatever it wants with its own memory, for example in the way I described on my previous post? Also Microsoft Pluton at least does not do memory tagging.
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.
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.
> However it is now being combined with ARM technology
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.
I'm currently working with very good researchers on formal verification of a part of the software I'm writing in rewriting logic with Maude - formalizing a fairly simplified version of the execution engine algorithms (0.005% of the c++ codebase maybe, 2500 lines of c++ at most) is taking ~a year roughly so far. That's not really viable for general development especially with requirements which evolve all the time.
