5 ms·

Partial results like, say, a hardware exception firing instead of forcing the compiler to reason about it? I want efence on steroids.

arcticbull 6y ago
To the maximum extent, bounds checking should be elided via greater compiler knowledge of what exactly is happening. This would leave arbitrary bounds checks limited to user input, in which case the vast majority of the performance penalty goes away right? "Bounds" are a higher-order programming language concept that I suggest may not have a place in hardware.
- steveklabnik 6y ago
  Compilers already do this. It would still be nice to have cheaper checks; compilers are not omniscient.
  - arcticbull 6y ago
    Yeah, for sure. I think I was having trouble envisioning what exactly a "cheaper" check could look like in hardware. Bounds checking is basically read length, subtract your index, and a conditional branch (potentially with a hint that it would succeed). To do this properly in hardware I suppose you'd need a list of memory regions that are "live" and default the rest to "dead", though how many do you support? What does updating the list look like? Page tables are pretty slow to update, and those don't change too often. Array tables would be pretty gnarly, and impose a further penalty on context switching as they'd have to be thread-local and app-local. I wonder if this is a case akin to spinlocks. Sure, I'd love a lock that doesn't busy-wait, but there's not really a cleaner solution -- in hardware or otherwise. Maybe I'm just not seeing something obvious, though!
    - saagarjha 6y ago
      You might find an almost-practical (not shipping yet, but should very soon) example helpful: https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/enhancing-memory-safety https://community.arm.com/developer/ip-products/processors/b...
      - arcticbull 6y ago
        That's brilliant, and I retract my statement completely. Thanks for sharing!
    - jabl 6y ago
      In addition to ARM MTE, see also Cheri: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

arcticbull 6y ago

To the maximum extent, bounds checking should be elided via greater compiler knowledge of what exactly is happening. This would leave arbitrary bounds checks limited to user input, in which case the vast majority of the performance penalty goes away right? "Bounds" are a higher-order programming language concept that I suggest may not have a place in hardware.

steveklabnik 6y ago
Compilers already do this. It would still be nice to have cheaper checks; compilers are not omniscient.
- arcticbull 6y ago
  Yeah, for sure. I think I was having trouble envisioning what exactly a "cheaper" check could look like in hardware. Bounds checking is basically read length, subtract your index, and a conditional branch (potentially with a hint that it would succeed). To do this properly in hardware I suppose you'd need a list of memory regions that are "live" and default the rest to "dead", though how many do you support? What does updating the list look like? Page tables are pretty slow to update, and those don't change too often. Array tables would be pretty gnarly, and impose a further penalty on context switching as they'd have to be thread-local and app-local. I wonder if this is a case akin to spinlocks. Sure, I'd love a lock that doesn't busy-wait, but there's not really a cleaner solution -- in hardware or otherwise. Maybe I'm just not seeing something obvious, though!
  - saagarjha 6y ago
    You might find an almost-practical (not shipping yet, but should very soon) example helpful: https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/enhancing-memory-safety https://community.arm.com/developer/ip-products/processors/b...
    - arcticbull 6y ago
      That's brilliant, and I retract my statement completely. Thanks for sharing!
  - jabl 6y ago
    In addition to ARM MTE, see also Cheri: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/