5 ms·

Systems programming in any language would benefit immensely from better hardware accelerated bounds checking. While Intel/AMD have put incredible effort into h

Systems programming in any language would benefit immensely from better hardware accelerated bounds checking. While Intel/AMD have put incredible effort into hyperthreading, virtualization, predictive loading, etc, page faults have more or less stayed the same since the NX bit was introduced. The world would be a lot safer if we had hardware features like cacheline faults, poison words, bounded MOV instructions, hardware ASLR, and auto-encrypted cachelines. Per-process hardware encrypted memory would also mitigate spectre and friends as reading another process's memory would become meaningless.

zozbot234 6y ago
> Systems programming in any language would benefit immensely from better hardware accelerated bounds checking. ... The world would be a lot safer if we had hardware features like cacheline faults, poison words, bounded MOV instructions, hardware ASLR, and auto-encrypted cachelines. This isn't really true. The main performance cost of these safety checks (and largely of others such as overflow checking) is inability to optimize because the compiler needs to preserve partial results/states in case a fault occurs. The checks themselves are trivial.
- CoolGuySteve 6y ago
  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/
jcranmer 6y ago
You mean that Intel should invest in something like MPX?
- my123 6y ago
  MPX is dead, and was so expensive that 100% software bounds checking was cheaper...
  - jcranmer 6y ago
    That was my point. :-) It's not clear that hardware bounds checking acceleration is actually a meaningful win.
    - pjmlp 6y ago
      Sure it is, Intel screw up. Solaris SPARC, iOS and now Android 11, all make use of some kind of hardware validation in memory accesses.
      - my123 6y ago
        MTE today, Morello as the experiment for fully safe C tomorrow: https://developer.arm.com/architectures/cpu-architecture/a-profile/morello https://developer.arm.com/architectures/cpu-architecture/a-p...
        pjmlp 6y ago
        Any help is welcomed. Microsoft is also having a go with Checked C. The main problem is forcing developers to actually use them, I guess that is why Google has decided to make MTE a requirement for Android 11 on ARM devices.
monadic2 6y ago
> The world would be a lot safer if we had hardware features like cacheline faults, poison words, bounded MOV instructions, hardware ASLR, and auto-encrypted cachelines. Sure, the world would be a lot safer if we used microkernels, too, but the tech world has been obsessed with performance over all other characteristics for decades.
gchadwick 6y ago
> Systems programming in any language would benefit immensely from better hardware accelerated bounds checking. [Mostly discussed deeper in the thread already but felt it was worth bringing up directly as a reply to this] This is an active area of development though still plenty of work to do. The Cambridge University Computer Lab have been doing research in this area in the form of CHERI: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ this gives you hardware capabilities which are effectively pointers with bounds given out by the OS. Want to access something? You need the appropriate capability to do so. ARM announced MTE last year, which whilst far less capable than CHERI begins to give you something (though it's targeted for bug hunting effectively rather than providing any actual security/safety properties): 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... ARM are also building a hardware CHERI implementation, Morello: https://developer.arm.com/architectures/cpu-architecture/a-profile/morello https://developer.arm.com/architectures/cpu-architecture/a-p.... There's already CHERI implementations running BSD on FPGAs, this will take it to the next level with real silicon using modern ARM processors (maybe you could run android on it for instance?). I think Intel have been looking along similar lines but I'm far less in touch with what they're up to so I don't have links.
todd8 6y ago
My first full time professional job (1976) involved writing assembly language for the TI 960, a process control minicomputer with a 64K data address space and a different 64K instruction space. At first, I just thought it was odd to make the hardware more complex by having two address spaces. However, this prevented a common cause of difficult to find bugs in asm programming, and I came to appreciate that hardware could make programming safer. Hardware architecture, programming languages, and compilers advanced rapidly, but safety always seemed to take a backseat and was left up to the programmers. I’m glad to see developments like Rust and I look forward to using it for a real project soon.
pjmlp 6y ago
You have it on CHERI, ARM and SPARC, it was Intel that screw up. So make use of Solaris SPARC, iOS or Android 11 (ARM HMT is a requirement).

zozbot234 6y ago

> Systems programming in any language would benefit immensely from better hardware accelerated bounds checking. ... The world would be a lot safer if we had hardware features like cacheline faults, poison words, bounded MOV instructions, hardware ASLR, and auto-encrypted cachelines. This isn't really true. The main performance cost of these safety checks (and largely of others such as overflow checking) is inability to optimize because the compiler needs to preserve partial results/states in case a fault occurs. The checks themselves are trivial.

CoolGuySteve 6y ago
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/

jcranmer 6y ago

You mean that Intel should invest in something like MPX?

my123 6y ago
MPX is dead, and was so expensive that 100% software bounds checking was cheaper...
- jcranmer 6y ago
  That was my point. :-) It's not clear that hardware bounds checking acceleration is actually a meaningful win.
  - pjmlp 6y ago
    Sure it is, Intel screw up. Solaris SPARC, iOS and now Android 11, all make use of some kind of hardware validation in memory accesses.
    - my123 6y ago
      MTE today, Morello as the experiment for fully safe C tomorrow: https://developer.arm.com/architectures/cpu-architecture/a-profile/morello https://developer.arm.com/architectures/cpu-architecture/a-p...
      - pjmlp 6y ago
        Any help is welcomed. Microsoft is also having a go with Checked C. The main problem is forcing developers to actually use them, I guess that is why Google has decided to make MTE a requirement for Android 11 on ARM devices.

monadic2 6y ago

> The world would be a lot safer if we had hardware features like cacheline faults, poison words, bounded MOV instructions, hardware ASLR, and auto-encrypted cachelines. Sure, the world would be a lot safer if we used microkernels, too, but the tech world has been obsessed with performance over all other characteristics for decades.

gchadwick 6y ago

> Systems programming in any language would benefit immensely from better hardware accelerated bounds checking. [Mostly discussed deeper in the thread already but felt it was worth bringing up directly as a reply to this] This is an active area of development though still plenty of work to do. The Cambridge University Computer Lab have been doing research in this area in the form of CHERI: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ this gives you hardware capabilities which are effectively pointers with bounds given out by the OS. Want to access something? You need the appropriate capability to do so. ARM announced MTE last year, which whilst far less capable than CHERI begins to give you something (though it's targeted for bug hunting effectively rather than providing any actual security/safety properties): 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... ARM are also building a hardware CHERI implementation, Morello: https://developer.arm.com/architectures/cpu-architecture/a-profile/morello https://developer.arm.com/architectures/cpu-architecture/a-p.... There's already CHERI implementations running BSD on FPGAs, this will take it to the next level with real silicon using modern ARM processors (maybe you could run android on it for instance?). I think Intel have been looking along similar lines but I'm far less in touch with what they're up to so I don't have links.

todd8 6y ago

My first full time professional job (1976) involved writing assembly language for the TI 960, a process control minicomputer with a 64K data address space and a different 64K instruction space. At first, I just thought it was odd to make the hardware more complex by having two address spaces. However, this prevented a common cause of difficult to find bugs in asm programming, and I came to appreciate that hardware could make programming safer. Hardware architecture, programming languages, and compilers advanced rapidly, but safety always seemed to take a backseat and was left up to the programmers. I’m glad to see developments like Rust and I look forward to using it for a real project soon.

pjmlp 6y ago

You have it on CHERI, ARM and SPARC, it was Intel that screw up. So make use of Solaris SPARC, iOS or Android 11 (ARM HMT is a requirement).