3 ms·

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.
      - pjmlp 4y ago
        ARM MTE, Solaris SPARC ADI, CHERI, Microsoft Pluton.... Pretty much possible and already available for those listed above, with Solaris having a decade of experience in production.
        AshamedCaptain 4y ago
        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.
        4y ago

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.
    - pjmlp 4y ago
      ARM MTE, Solaris SPARC ADI, CHERI, Microsoft Pluton.... Pretty much possible and already available for those listed above, with Solaris having a decade of experience in production.
      - AshamedCaptain 4y ago
        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.
        4y ago