But programming is multiplication. A programmers work multiplies. If some person once writes code that ends up leaking users data, that data might like a thousand users data in a way that cannot be unleaked. That broken code then multiplies through time.
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.
Not everybody works in web development. Generally, C++ is mostly used for anything where performance is paramount. Personally, I write audio code. I rarely have memory issues because most of it is just number crunching. I am working in timespans of microseconds, so speed is the ultimate concern.
In fact, we have had bounds checking C and C++ extensions for decades, and practically no one uses them save for debugging purposes. This kind of shows how much interest there really is outside of some smaller circles where it may be relevant.
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.
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.
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.
No construction software for bridges will stop the engineer from building unsafe bridges. Why should we need a compiler that will do the same with software?
What stops the engineer from building bridges are the law regulations and his work environment. This regulations and work environment exists in programming too.
The crucial difference between construction engineering and software engineering is the level of accidental complexity it allows. Any junior software engineer can create and ship unmaintainable architectural monstrosities, and most stakeholders might be completely oblivious of that fact and what it means until much later. Software architecture and programming concerns can be difficult to communicate to non-technical people.
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?
Bad comparison. Brain surgeries are a method of last resort. They are unsafe because there are significant knowledge gaps in our understanding of the brain that might take centuries more to fill. Every time a neurosurgeon cuts, they are potentially doing irreversible damage to an important part of a person's consciousness, abilities and memories.
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.
Is surgery often a last resort, done when less invasive things have been ruled out or cannot be used? Yes. Is the human body the most complex “machinery” that we know, demanding our utmost respect? Is the brain the most delicate part of the body? Probably, yes.(?) Is brain surgery in turn a very delicate procedure that should be approached with a thousand-fold more caution than mere tinkering on human artifacts, such as programming? Yes.
It’s like you have gone out of your way to prove the opposite point of what you were ostensibly trying to prove.
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.