4 ms·

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

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.

pjmlp 4y ago
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.
- AshamedCaptain 4y ago
  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?
  - pjmlp 4y ago
    Not when only the kernel is allowed to do that, and syscalls require root access.
    - AshamedCaptain 4y ago
      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.
      - pjmlp 4y ago
        Yes it will, because the relevant assembly instructions aren't available to userspace, in most current designs. Trying to do otherwise will trap.
        AshamedCaptain 4y ago
        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.
        jcelerier 4y ago
        > What is going to prevent a process from _writing to AND reading from its own memory_ exactly? I think pjmlp is referring to this: https://msrc-blog.microsoft.com/2022/01/20/an_armful_of_cheris/ https://msrc-blog.microsoft.com/2022/01/20/an_armful_of_cher...
        AshamedCaptain 4y ago
        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.
- jcelerier 4y ago
  I'm coming from a side where people are nowadays literally working with their own FPGAs to get more performance though haha
  - pjmlp 4y ago
    Hopefully they are doing VHDL with formal verification, for the sake of their data consistency.
    - jcelerier 4y ago
      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.

pjmlp 4y ago

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.

AshamedCaptain 4y ago
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?
- pjmlp 4y ago
  Not when only the kernel is allowed to do that, and syscalls require root access.
  - AshamedCaptain 4y ago
    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.
    - pjmlp 4y ago
      Yes it will, because the relevant assembly instructions aren't available to userspace, in most current designs. Trying to do otherwise will trap.
      - AshamedCaptain 4y ago
        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.
        jcelerier 4y ago
        > What is going to prevent a process from _writing to AND reading from its own memory_ exactly? I think pjmlp is referring to this: https://msrc-blog.microsoft.com/2022/01/20/an_armful_of_cheris/ https://msrc-blog.microsoft.com/2022/01/20/an_armful_of_cher...
        AshamedCaptain 4y ago
        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.
jcelerier 4y ago
I'm coming from a side where people are nowadays literally working with their own FPGAs to get more performance though haha
- pjmlp 4y ago
  Hopefully they are doing VHDL with formal verification, for the sake of their data consistency.
  - jcelerier 4y ago
    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.