7 ms·

I’m open to a slow but secure processor. Certainly for my personal computing.

by monadic2 6y ago

pjmlp 6y ago
I feel the same about bounds checking in programming languages, apparently not everyone does.
- KMag 6y ago
  I vaguely remember a story about a hardware manufacturer (Burroughs? Symbolics?) that had a processor with instructions that could bounds-check array accesses with zero latency overhead. It was a great feature for Algol/Lisp, but some customers asked for an option in their Fortran compiler to disable the bounds check. The sales engineer replied that the bounds checks were zero-cost, but the customers replied that the bounds checks broke their progrems... their programs had silent (or at least unnoticed) array bounds bugs, and the customers preferred to keep those bugs, thank you very much! I wish I had kept the link. I've tired a couple times to find the story. Does this ring any bells for anyone?
  - pjmlp 6y ago
    Burroughs definitely had bounds checking. https://en.wikipedia.org/wiki/Burroughs_large_systems https://en.wikipedia.org/wiki/Burroughs_large_systems Its system programming language (initially ESPOL then NEWP), also has support for explicit unsafe code blocks, and there is zero Assembly support. All CPU low level operations are exposed via intrisics. All of this in 1961, almost 10 years before C was invented. Still being sold nowadays, and naturally Unisys uses security as one of the selling features. https://www.unisys.com/offerings/clearpath-forward/clearpath-forward-products/clearpath-mcp-software https://www.unisys.com/offerings/clearpath-forward/clearpath... Regarding bounds checking, what I keep around is Hoare's Turing award speech. "Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
    - monadic2 6y ago
      I used to agree heavily with this, but nowadays we have effective techniques of memory safety on the software level and I find myself ambivalent on which level of abstraction this occurs. I do think it means C is probably eventually doomed as a system language, though. I’m curious if we’ll ever see e.g. rust in the *bsd codebases.
      - pjmlp 6y ago
        Except we don't, that is why ARM, Apple, Microsoft, Google, Oracle are all pursuing variants of hardware memory tagging for taming C, as those software solutions have proven not to work.
        monadic2 6y ago
        Sure, but hardware memory tagging is also not proven to work. Anyway, it's unclear with which criteria you're judging "proven not to work" with as we're both typing via the software right now, unlike a hardware solution.
        pjmlp 6y ago
        Sure it is, thanks to CVE database entries. Here are Google's rationale for enabling it on Android, > Platform hardening - We’ve expanded use of compiler-based sanitizers in security-critical components, including BoundSan, IntSan, CFI, and Shadow-Call Stack. We’re also enabling heap pointer tagging for apps targeting Android 11 or higher, to help apps catch memory issues in production. These hardening improvements may surface more repeatable/reproducible app crashes in your code, so please test your apps. We've used HWAsan to find and fix many memory errors in the system, and we now offer HWAsan-enabled system images to help you find such issues in your apps. https://android-developers.googleblog.com/2020/02/Android-11-developer-preview.html https://android-developers.googleblog.com/2020/02/Android-11... > Starting in Android R, for 64-bit processes, all heap allocations have an implementation defined tag set in the top byte of the pointer on devices with kernel support for ARM Top-byte Ignore (TBI). Any application that modifies this tag is terminated when the tag is checked during deallocation. This is necessary for future hardware with ARM Memory Tagging Extension (MTE) support. https://source.android.com/devices/tech/debug/tagged-pointers https://source.android.com/devices/tech/debug/tagged-pointer... "Adopting the Arm Memory Tagging Extension in Android" https://security.googleblog.com/2019/08/adopting-arm-memory-tagging-extension.html https://security.googleblog.com/2019/08/adopting-arm-memory-... "Detecting Memory Corruption Bugs With HWASan" > Native code in memory-unsafe languages like C and C++ is often vulnerable to memory corruption bugs. Our data shows that issues like use-after-free, double-free, and heap buffer overflows generally constitute more than 65% of High & Critical security bugs in Chrome and Android. > HWASan is based on memory tagging and depends on the Top Byte Ignore feature present in all 64-bit ARM CPUs and the associated kernel support. Every memory allocation is assigned a random 8-bit tag that is stored in the most significant byte (MSB) of the address, but ignored by the CPU. As a result, this tagged pointer can be used in place of a regular pointer without any code changes. https://android-developers.googleblog.com/2020/02/detecting-memory-corruption-bugs-with-hwasan.html https://android-developers.googleblog.com/2020/02/detecting-... The post is already too long just with Android, otherwise I would provide similar references for iOS, Solaris on SPARC, Azure Sphere / Phonon.
mehrdadn 6y ago
Try underclocking your CPU to like 30% of its max speed and see if your programs still run comfortably. This would've made sense in a world where programs didn't become more bloated and slower over time, but it would have visible repercussions given our software today.
- pjmlp 6y ago
  That would be positive though, maybe then not so many people would be running Python sites on Django or Electron apps.
  - andybak 6y ago
    It sounds like you want to actively discourage the use of Python and Django irrespective of performance concerns? Care to elaborate or was it just flippant snide?
    - pjmlp 6y ago
      More like discourage the use of pure scripting without any regard for JIT/AOT toolchains or coding without performance considerations, in opposition to what we used to care about. The example with Python and Django was what came quickest to mind, but I can gladly expand it to include Ruby and Rails, or any other stack that falls under the same Web sites/desktop applications with scripting languages umbrella.
      - andybak 6y ago
        The usual retort is "the scripting language is rarely the bottleneck" as well as "developer time is more expensive than hardware". Between these two get-out clauses, aren't you talking about a very small minority of use-cases? Those where the scripting language is the bottleneck and the problem can't simply be solved by spending a few $ more on your VPS?
        pjmlp 6y ago

I’m open to a slow but secure processor. Certainly for my personal computing.

pjmlp 6y ago

I feel the same about bounds checking in programming languages, apparently not everyone does.

KMag 6y ago
I vaguely remember a story about a hardware manufacturer (Burroughs? Symbolics?) that had a processor with instructions that could bounds-check array accesses with zero latency overhead. It was a great feature for Algol/Lisp, but some customers asked for an option in their Fortran compiler to disable the bounds check. The sales engineer replied that the bounds checks were zero-cost, but the customers replied that the bounds checks broke their progrems... their programs had silent (or at least unnoticed) array bounds bugs, and the customers preferred to keep those bugs, thank you very much! I wish I had kept the link. I've tired a couple times to find the story. Does this ring any bells for anyone?
- pjmlp 6y ago
  Burroughs definitely had bounds checking. https://en.wikipedia.org/wiki/Burroughs_large_systems https://en.wikipedia.org/wiki/Burroughs_large_systems Its system programming language (initially ESPOL then NEWP), also has support for explicit unsafe code blocks, and there is zero Assembly support. All CPU low level operations are exposed via intrisics. All of this in 1961, almost 10 years before C was invented. Still being sold nowadays, and naturally Unisys uses security as one of the selling features. https://www.unisys.com/offerings/clearpath-forward/clearpath-forward-products/clearpath-mcp-software https://www.unisys.com/offerings/clearpath-forward/clearpath... Regarding bounds checking, what I keep around is Hoare's Turing award speech. "Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
  - monadic2 6y ago
    I used to agree heavily with this, but nowadays we have effective techniques of memory safety on the software level and I find myself ambivalent on which level of abstraction this occurs. I do think it means C is probably eventually doomed as a system language, though. I’m curious if we’ll ever see e.g. rust in the *bsd codebases.
    - pjmlp 6y ago
      Except we don't, that is why ARM, Apple, Microsoft, Google, Oracle are all pursuing variants of hardware memory tagging for taming C, as those software solutions have proven not to work.
      - monadic2 6y ago
        Sure, but hardware memory tagging is also not proven to work. Anyway, it's unclear with which criteria you're judging "proven not to work" with as we're both typing via the software right now, unlike a hardware solution.
        pjmlp 6y ago
        Sure it is, thanks to CVE database entries. Here are Google's rationale for enabling it on Android, > Platform hardening - We’ve expanded use of compiler-based sanitizers in security-critical components, including BoundSan, IntSan, CFI, and Shadow-Call Stack. We’re also enabling heap pointer tagging for apps targeting Android 11 or higher, to help apps catch memory issues in production. These hardening improvements may surface more repeatable/reproducible app crashes in your code, so please test your apps. We've used HWAsan to find and fix many memory errors in the system, and we now offer HWAsan-enabled system images to help you find such issues in your apps. https://android-developers.googleblog.com/2020/02/Android-11-developer-preview.html https://android-developers.googleblog.com/2020/02/Android-11... > Starting in Android R, for 64-bit processes, all heap allocations have an implementation defined tag set in the top byte of the pointer on devices with kernel support for ARM Top-byte Ignore (TBI). Any application that modifies this tag is terminated when the tag is checked during deallocation. This is necessary for future hardware with ARM Memory Tagging Extension (MTE) support. https://source.android.com/devices/tech/debug/tagged-pointers https://source.android.com/devices/tech/debug/tagged-pointer... "Adopting the Arm Memory Tagging Extension in Android" https://security.googleblog.com/2019/08/adopting-arm-memory-tagging-extension.html https://security.googleblog.com/2019/08/adopting-arm-memory-... "Detecting Memory Corruption Bugs With HWASan" > Native code in memory-unsafe languages like C and C++ is often vulnerable to memory corruption bugs. Our data shows that issues like use-after-free, double-free, and heap buffer overflows generally constitute more than 65% of High & Critical security bugs in Chrome and Android. > HWASan is based on memory tagging and depends on the Top Byte Ignore feature present in all 64-bit ARM CPUs and the associated kernel support. Every memory allocation is assigned a random 8-bit tag that is stored in the most significant byte (MSB) of the address, but ignored by the CPU. As a result, this tagged pointer can be used in place of a regular pointer without any code changes. https://android-developers.googleblog.com/2020/02/detecting-memory-corruption-bugs-with-hwasan.html https://android-developers.googleblog.com/2020/02/detecting-... The post is already too long just with Android, otherwise I would provide similar references for iOS, Solaris on SPARC, Azure Sphere / Phonon.

mehrdadn 6y ago

Try underclocking your CPU to like 30% of its max speed and see if your programs still run comfortably. This would've made sense in a world where programs didn't become more bloated and slower over time, but it would have visible repercussions given our software today.

pjmlp 6y ago
That would be positive though, maybe then not so many people would be running Python sites on Django or Electron apps.
- andybak 6y ago
  It sounds like you want to actively discourage the use of Python and Django irrespective of performance concerns? Care to elaborate or was it just flippant snide?
  - pjmlp 6y ago
    More like discourage the use of pure scripting without any regard for JIT/AOT toolchains or coding without performance considerations, in opposition to what we used to care about. The example with Python and Django was what came quickest to mind, but I can gladly expand it to include Ruby and Rails, or any other stack that falls under the same Web sites/desktop applications with scripting languages umbrella.
    - andybak 6y ago
      The usual retort is "the scripting language is rarely the bottleneck" as well as "developer time is more expensive than hardware". Between these two get-out clauses, aren't you talking about a very small minority of use-cases? Those where the scripting language is the bottleneck and the problem can't simply be solved by spending a few $ more on your VPS?
      - pjmlp 6y ago