Does REPLY_FAULT cascade? Meaning, if A is waiting in a SEND to B, and B is waiting in a SEND to C, and C does REPLY_FAULT, does A get killed along with B (and any further tasks that may be waiting on A)? Because if not, a malicious task could just delegate its experiments to a helper task. And if yes, that seems rather brittle overall (without having any further familiarity with Hubris). Furthermore, if SENDs can be circular/reciprocal, a task may also inadvertently kill itself that way — which (for scenarios like B –> A –> B) may incentivize not using REPLY_FAULT.
It seems that Hubris is not designed as a general-purpose operating system. Processes are defined at build time.
The reason why servers can shoot back at their clients is reliability, not security. Errors are thought to originate from bugs, not from deliberate attacks. The extreme reaction of the kernel ensures that developers find them as soon as possible.
Of course, there is an overlap with security, and this can be a useful fallback measure in the event that a process tries to do something that it isn't supposed to do.
> It seems that Hubris is not designed as a general-purpose operating system. Processes are defined at build time.
These are both correct.
Well, I mean, Hubris is general in the sense that, if you're doing an embedded system and you can deal with the constraints it has, like the latter, it can work for your projects. But it's not trying to be anything other than a good embedded OS, or to handle any project.
I think when B gets faulted A would get an error about a dead server and would have the opportunity resend the same message to a newly reset server not a cascading crash.
