3 ms·

See also: this recent HN story https://news.ycombinator.com/item?id=40178652 https://news.ycombinator.com/item?id=40178652 from Cliff Biffle's blog https://clif

by gjm11 2y ago

See also: this recent HN story https://news.ycombinator.com/item?id=40178652 https://news.ycombinator.com/item?id=40178652 from Cliff Biffle's blog https://cliffle.com/blog/hubris-reply-fault/ https://cliffle.com/blog/hubris-reply-fault/ about the Hubris OS used by 0xide (https://oxide.computer/blog/hubris-and-humility https://oxide.computer/blog/hubris-and-humility). A design principle in the OS is that if you pass anything invalid to a syscall, you don't get an error back, you get your process forcibly killed. The thing linked at the start of the paragraph above is about an extension to this principle: if you have a client/server pair running on the OS, and the server gets a request it thinks is invalid, it can forcibly kill the client. All of which sounds kinda insane, but (as per cjk2's comment in this thread) apparently what actually happens is that in development things blow up all the time and get fixed, and once you get through that phase all those bugs are fixed and everything is very robust. (But Hubris's use case is quite specific and so far as I know no one is claiming that it would be better if, say, Linux or Windows worked that way.)

bcantrill 2y ago
Things don't actually blow up in development, for whatever it's worth. It's really very unusual to have a defect whereby an invalid message is sent to a task -- which was part of why REPLY_FAULT was an entirely reasonable extension of the system: it doesn't come up often, but when it does, you really want to debug it.
- gjm11 2y ago
  Ah, my apologies. I thought I remembered the Cliffle post saying that, but in fact he says it specifically about the kernel behaviour rather than about the generalization to REPLY_FAULT. I hope no one was misled.
  - bcantrill 2y ago
    No worries! (It would be quite reasonable to think that we hit this a lot in development; I just wanted to clarify it for anyone who came by the thread.) And it does sound pretty off the wall to anyone who might not understand the context of Hubris, but (to bring it back on topic with Unix terms), I would liken REPLY_FAULT to SIGSYS, which would be seen under similar terms (i.e., grievously incorrect application) and has the same disposition (i.e., core dump).

by gjm11 2y ago

bcantrill 2y ago

Things don't actually blow up in development, for whatever it's worth. It's really very unusual to have a defect whereby an invalid message is sent to a task -- which was part of why REPLY_FAULT was an entirely reasonable extension of the system: it doesn't come up often, but when it does, you really want to debug it.

gjm11 2y ago
Ah, my apologies. I thought I remembered the Cliffle post saying that, but in fact he says it specifically about the kernel behaviour rather than about the generalization to REPLY_FAULT. I hope no one was misled.
- bcantrill 2y ago
  No worries! (It would be quite reasonable to think that we hit this a lot in development; I just wanted to clarify it for anyone who came by the thread.) And it does sound pretty off the wall to anyone who might not understand the context of Hubris, but (to bring it back on topic with Unix terms), I would liken REPLY_FAULT to SIGSYS, which would be seen under similar terms (i.e., grievously incorrect application) and has the same disposition (i.e., core dump).