3 ms·

Honestly this kinda shows me that no matter what degree of robustness we design into our systems (null saftety, memory safety, thread safety etc.), some types o

Honestly this kinda shows me that no matter what degree of robustness we design into our systems (null saftety, memory safety, thread safety etc.), some types of system breaking bugs are unavoidable (such as DOSing the system by calling a system API function in an infinite loop), and are often impossible to distingushing from desired behavior.

smaudet 2y ago
How about no infinite loops (as a start)? Unless you are the kernel, and you can demonstrate that your loop is "safe" via some set of static analysis.
- banish-m4 2y ago
  Achievable with formal verification and soft- and hard-realtime worst case timing validation. It's not impossible but also not easy. It requires significant engineering investment.
- Tsarbomb 2y ago
  Are you suggesting a general solution to the halting problem?
  - jamesmunns 2y ago
    The usual solution, including in safety critical systems, is to give the judge of the halting problem a stopwatch and a gun. For example in an embedded system: a watchdog timer that you don't service during the execution of some context. If you fail to complete your task within the time, the kernel or entire system is rebooted. For example in a VM-like system, you give the code some amount of "fuel" or "budget", if it exceeds that budget, the process/tasklet/whatever is terminated by the VM. It's not a general solution to the halting problem, but a practical one.
  - fragmede 2y ago
    funnily enough, ChatGPT can examine code and can say if it will halt or not, in some small cases.
- torginus 2y ago
  Infinite loops are not that harmful by themselves if they only spin the CPU. The scheduler can schedule other work on the core if the process' timeslice runs out, or it results in a frozen application if said infinite loop happens on an event loop thread. Neither are pleasant, but they don't compromise system integrity and as such are not substantially different from other kinds of crash bugs.
  - smaudet 2y ago
    > Infinite loops are not that harmful by themselves if they only spin the CPU Categorically that's the exception, not the norm. For always-on systems, "by themselves" is pretty critical, as they can result in DOS style bugs/attacks as illustrated in the parent article. The infinite loop is most useful e.g. for the scheduler or other event loop code, which by definition this style of code does a lot more than "only" spin the CPU. For systems capable of long-term power saving operation - the system can go dormant (either no power draw or very little). An infinite loop can be the difference between weeks of power off a battery, or days/hours.
banish-m4 2y ago
That's shrugging off inferior processes and substandard work. Bugs are unnecessary because there is a finite amount of code and they can all be eliminated if the correct eyeballs spend sufficient time reviewing, testing, and simplifying behavior to focus on robust reliability and correctness. Breaking changes can be allowed in dev packs with semver release notes. There are no excuses for sloppy engineering.
KerrAvon 2y ago
Being able to DOS the system by calling an API should be considered a bug in the system. There are mitigation strategies for such things. If you can’t (for mitigation purposes) distinguish a DOS from desired behavior, there’s something very wrong with your architecture. edit: added parenthetical

smaudet 2y ago

How about no infinite loops (as a start)? Unless you are the kernel, and you can demonstrate that your loop is "safe" via some set of static analysis.

banish-m4 2y ago
Achievable with formal verification and soft- and hard-realtime worst case timing validation. It's not impossible but also not easy. It requires significant engineering investment.
Tsarbomb 2y ago
Are you suggesting a general solution to the halting problem?
- jamesmunns 2y ago
  The usual solution, including in safety critical systems, is to give the judge of the halting problem a stopwatch and a gun. For example in an embedded system: a watchdog timer that you don't service during the execution of some context. If you fail to complete your task within the time, the kernel or entire system is rebooted. For example in a VM-like system, you give the code some amount of "fuel" or "budget", if it exceeds that budget, the process/tasklet/whatever is terminated by the VM. It's not a general solution to the halting problem, but a practical one.
- fragmede 2y ago
  funnily enough, ChatGPT can examine code and can say if it will halt or not, in some small cases.
torginus 2y ago
Infinite loops are not that harmful by themselves if they only spin the CPU. The scheduler can schedule other work on the core if the process' timeslice runs out, or it results in a frozen application if said infinite loop happens on an event loop thread. Neither are pleasant, but they don't compromise system integrity and as such are not substantially different from other kinds of crash bugs.
- smaudet 2y ago
  > Infinite loops are not that harmful by themselves if they only spin the CPU Categorically that's the exception, not the norm. For always-on systems, "by themselves" is pretty critical, as they can result in DOS style bugs/attacks as illustrated in the parent article. The infinite loop is most useful e.g. for the scheduler or other event loop code, which by definition this style of code does a lot more than "only" spin the CPU. For systems capable of long-term power saving operation - the system can go dormant (either no power draw or very little). An infinite loop can be the difference between weeks of power off a battery, or days/hours.

banish-m4 2y ago

That's shrugging off inferior processes and substandard work. Bugs are unnecessary because there is a finite amount of code and they can all be eliminated if the correct eyeballs spend sufficient time reviewing, testing, and simplifying behavior to focus on robust reliability and correctness. Breaking changes can be allowed in dev packs with semver release notes. There are no excuses for sloppy engineering.

KerrAvon 2y ago

Being able to DOS the system by calling an API should be considered a bug in the system. There are mitigation strategies for such things. If you can’t (for mitigation purposes) distinguish a DOS from desired behavior, there’s something very wrong with your architecture. edit: added parenthetical