4 ms·

MTE and CHERI are so different that it’s hard and maybe not even possible to do both at the same time (you might not have enough spare bits in a CHERI 128 bit p

MTE and CHERI are so different that it’s hard and maybe not even possible to do both at the same time (you might not have enough spare bits in a CHERI 128 bit ptr for the MTE tag) They also imply a very different system architecture.

quotemstr 1y ago
> MTE and CHERI are so different that it’s hard and maybe not even possible to do both at the same time (you might not have enough spare bits in a CHERI 128 bit ptr for the MTE tag) Why would you need MTE if you have CHERI?
- pizlonator 1y ago
  Not saying you’d want both. Just answering why MTE isn’t a path to CHERI But here’s a reason to do both: CHERI’s UAF story isn’t great. Adding MTE means you get a probabilistic story at least
  - quotemstr 1y ago
    Some progress on UAF though! https://dl.acm.org/doi/10.1145/3703595.3705878 https://dl.acm.org/doi/10.1145/3703595.3705878
  - bri3d 1y ago
    True! On the flip side, MTE sucks at intra-object corruption: if I get access to a heap object with pointers, MTE doesn't affect me, I can go ahead and write to that object because I own the tag. Overall my _personal_ opinion is that CHERI is a huge win at a huge cost, while MTE is a huge win at a low cost. But, there are definitely vulnerability classes that each system excels at.
    - pizlonator 1y ago
      I think the intra object issue might be niche enough to not matter. And CHERI fixes it only optionally, if you accept having to change a lot more code
      - bri3d 1y ago
        I think I broadly agree with you. IMO tagging is practically much, much more valuable than capabilities systems modeled like CHERI.
        quotemstr 1y ago
        Yes, but CHERI opens whole new system design possibilities, including things like ultra-cheap intra-address-space security boundaries. See https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/20160728micro-journal-cheri-final.pdf https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201607... > We have used CHERI’s ISA facilities as a foundation to build a software object-capability model supporting orders of magnitude greater compartmentalization performance, and hence granularity, than current designs. We use capabilities to build a hardware-software domain-transition mechanism and programming model suitable for safe communication between mutually distrusting software and https://github.com/CTSRD-CHERI/cheripedia/wiki/Colocation-Tutorial https://github.com/CTSRD-CHERI/cheripedia/wiki/Colocation-Tu... > Processes are Unix' natural compartments, and a lot of existing software makes use of that model. The problem is, they are heavy-weight; communication and context switching overhead make using them for fine-grained compartmentalisation impractical. Cocalls, being fast (order of magnitude slower than a function call, order of magnitude faster than a cheapest syscall), aim to fix that problem. This functionality revolves around two functions: cocall(2) for the caller (client) side, and coaccept(2) for the callee (service) side. Underneath they are implemented using CHERI magic in the form of CInvoke / LDPBR CPU instruction to switch protection domains without the need to enter the kernel, but from the API user point of view they mostly look like ordinary system calls and follow the same conventions, errno et al. There's a decent chance that we get back whatever performance we pay for CHERI with interest as new systems architecture possibilities open up. MTE helps us secure existing architectures. CHERI makes new architectures possible.
        saagarjha 1y ago
        Yes, but this breaks mirror mappings.
- bri3d 1y ago
  Why would you need CHERI if you have working mitigations that don't demand a second bus? I think it's two halves of the same coin and Apple chose the second half of the coin. The two systems are largely orthogonal; I think if Apple chose to go from one to the other it will be a generational change rather than an incremental one. The advantage of MTE/MIE is you can do it incrementally by just changing the high bits the allocator supplies; CHERI requires a fundamental paradigm shift. Apple love paradigm shifts but there's no indication they're going to do one here; if they do, it will be a separate effort.
  - als0 1y ago
    Second bus?
    - bri3d 1y ago
      CHERI fundamentally relies on capabilities living in memory that is architecturally separate from program memory. You could do so using a bus firewall, but then you're at the same place as MIE with the SPTM.
      - MBCook 1y ago
        So something like having built in RAM for the pagetables that aren’t part of the normal pool? That way no matter what kind of attack you come up with user space cannot pass a pointer to it?
      - jrtc27 1y ago
        That's not true. Capabilities are in main memory as much as any other data. The tags are in separate memory (whether a wider SRAM, DRAM ECC bits, or a separate table off on the side in a fraction of memory that's managed by the memory controller; all three schemes have been implemented and have trade-offs). But this is also true of MTE; you do not want those tags in normal software-visible main memory either, they need to be protected.
      - Findecanor 1y ago
        A CHERI capability is stored in main memory but with the tag bit for that location set. The tags are stored in separate memory pages, also in main memory in current designs. Maybe you've been confused by a description of how it works inside a processor. In early CHERI designs, capabilities were in different architectural processor registers from integers. In recent CHERI designs, the same register numbers are used for capabilities and other registers. A micro-architecture could be designed to have either all registers be capability registers with the tag bit, or use register renaming to separate integer and capability registers. I suppose a CHERI MCU for embedded systems with small memory could theoretically have tag pages in separate SRAM instead of caching main memory, but I have not seen that.
leoc 1y ago
Sure, I'm not suggesting that Apple might actually do both at the same time. They could however implement the less burdensome one now while intending to replace it with the the all-singing-all-dancing alternative down the line.
- pizlonator 1y ago
  Gotcha. My point about different systems architectures makes me think it’s unlikely that you’d want to do that
jrtc27 1y ago
We actually have ideas for how to combine the two; see section C.5 of https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-987.pdf https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-987.pdf

quotemstr 1y ago

> MTE and CHERI are so different that it’s hard and maybe not even possible to do both at the same time (you might not have enough spare bits in a CHERI 128 bit ptr for the MTE tag) Why would you need MTE if you have CHERI?

pizlonator 1y ago
Not saying you’d want both. Just answering why MTE isn’t a path to CHERI But here’s a reason to do both: CHERI’s UAF story isn’t great. Adding MTE means you get a probabilistic story at least
- quotemstr 1y ago
  Some progress on UAF though! https://dl.acm.org/doi/10.1145/3703595.3705878 https://dl.acm.org/doi/10.1145/3703595.3705878
- bri3d 1y ago
  True! On the flip side, MTE sucks at intra-object corruption: if I get access to a heap object with pointers, MTE doesn't affect me, I can go ahead and write to that object because I own the tag. Overall my _personal_ opinion is that CHERI is a huge win at a huge cost, while MTE is a huge win at a low cost. But, there are definitely vulnerability classes that each system excels at.
  - pizlonator 1y ago
    I think the intra object issue might be niche enough to not matter. And CHERI fixes it only optionally, if you accept having to change a lot more code
    - bri3d 1y ago
      I think I broadly agree with you. IMO tagging is practically much, much more valuable than capabilities systems modeled like CHERI.
      - quotemstr 1y ago
        Yes, but CHERI opens whole new system design possibilities, including things like ultra-cheap intra-address-space security boundaries. See https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/20160728micro-journal-cheri-final.pdf https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201607... > We have used CHERI’s ISA facilities as a foundation to build a software object-capability model supporting orders of magnitude greater compartmentalization performance, and hence granularity, than current designs. We use capabilities to build a hardware-software domain-transition mechanism and programming model suitable for safe communication between mutually distrusting software and https://github.com/CTSRD-CHERI/cheripedia/wiki/Colocation-Tutorial https://github.com/CTSRD-CHERI/cheripedia/wiki/Colocation-Tu... > Processes are Unix' natural compartments, and a lot of existing software makes use of that model. The problem is, they are heavy-weight; communication and context switching overhead make using them for fine-grained compartmentalisation impractical. Cocalls, being fast (order of magnitude slower than a function call, order of magnitude faster than a cheapest syscall), aim to fix that problem. This functionality revolves around two functions: cocall(2) for the caller (client) side, and coaccept(2) for the callee (service) side. Underneath they are implemented using CHERI magic in the form of CInvoke / LDPBR CPU instruction to switch protection domains without the need to enter the kernel, but from the API user point of view they mostly look like ordinary system calls and follow the same conventions, errno et al. There's a decent chance that we get back whatever performance we pay for CHERI with interest as new systems architecture possibilities open up. MTE helps us secure existing architectures. CHERI makes new architectures possible.
        saagarjha 1y ago
        Yes, but this breaks mirror mappings.
bri3d 1y ago
Why would you need CHERI if you have working mitigations that don't demand a second bus? I think it's two halves of the same coin and Apple chose the second half of the coin. The two systems are largely orthogonal; I think if Apple chose to go from one to the other it will be a generational change rather than an incremental one. The advantage of MTE/MIE is you can do it incrementally by just changing the high bits the allocator supplies; CHERI requires a fundamental paradigm shift. Apple love paradigm shifts but there's no indication they're going to do one here; if they do, it will be a separate effort.
- als0 1y ago
  Second bus?
  - bri3d 1y ago
    CHERI fundamentally relies on capabilities living in memory that is architecturally separate from program memory. You could do so using a bus firewall, but then you're at the same place as MIE with the SPTM.
    - MBCook 1y ago
      So something like having built in RAM for the pagetables that aren’t part of the normal pool? That way no matter what kind of attack you come up with user space cannot pass a pointer to it?
    - jrtc27 1y ago
      That's not true. Capabilities are in main memory as much as any other data. The tags are in separate memory (whether a wider SRAM, DRAM ECC bits, or a separate table off on the side in a fraction of memory that's managed by the memory controller; all three schemes have been implemented and have trade-offs). But this is also true of MTE; you do not want those tags in normal software-visible main memory either, they need to be protected.
    - Findecanor 1y ago
      A CHERI capability is stored in main memory but with the tag bit for that location set. The tags are stored in separate memory pages, also in main memory in current designs. Maybe you've been confused by a description of how it works inside a processor. In early CHERI designs, capabilities were in different architectural processor registers from integers. In recent CHERI designs, the same register numbers are used for capabilities and other registers. A micro-architecture could be designed to have either all registers be capability registers with the tag bit, or use register renaming to separate integer and capability registers. I suppose a CHERI MCU for embedded systems with small memory could theoretically have tag pages in separate SRAM instead of caching main memory, but I have not seen that.

leoc 1y ago

Sure, I'm not suggesting that Apple might actually do both at the same time. They could however implement the less burdensome one now while intending to replace it with the the all-singing-all-dancing alternative down the line.

pizlonator 1y ago
Gotcha. My point about different systems architectures makes me think it’s unlikely that you’d want to do that

jrtc27 1y ago

We actually have ideas for how to combine the two; see section C.5 of https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-987.pdf https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-987.pdf