3 ms·

If your WiFi driver crashes and restarts, at the minimum, I think it could be treated as if you lost network connectivity for a short time. This is a situation

If your WiFi driver crashes and restarts, at the minimum, I think it could be treated as if you lost network connectivity for a short time. This is a situation that applications should be able to handle anyway, since it happens all the time on laptops. There are plenty of applications out there that just don’t respond to configuration changes gracefully. For example, if you have a music program running, and then you plug a MIDI keyboard in, is the new MIDI keyboard recognized by your music program? Maybe so, and you can use it immediately. Maybe not, and you have to restart the application. If your MIDI driver crashes, maybe the music program doesn’t handle it gracefully, and you have to quit and relaunch the program. But that is miles better than crashing the system and rebooting.

taeric 3y ago
It really depends on what all is done "in the driver," though? Since, per the application, the data may have been passed off to the driver with a successful message pass. And if I have to have secrets in the driver for it to be able to connect to access points and such, it seems dubious how protected from all of my secrets the system can be between all parties. MIDI is actually an easy example, all told. If I unplug and replug a keyboard in, I expect it to probably not handle any persistent state of the keyboard correctly. (For fun, it is common for the "at rest" value of peddles to be discovered at connect time. Good luck with that if the driver crashes.)
- klodolph 3y ago
  > Since, per the application, the data may have been passed off to the driver with a successful message pass. The application already knows that the data is not guaranteed to be delivered, or even sent at all. That’s just the nature of network programming—it’s inherently unreliable. > And if I have to have secrets in the driver for it to be able to connect to access points and such, it seems dubious how protected from all of my secrets the system can be between all parties. To make an analogy—locking your front door doesn’t protect thieves from stealing your plastic flamingoes and garden gnomes, but it does make it harder to steal the $50,000 in cash you have hidden under the mattress. The point of isolation is to reduce the effect of failures. If you have a buggy WiFi driver, in a monolithic kernel, that could be really bad—it could even be a remotely exploitable vulnerability in the kernel itself. In other words, you have no front door, and the thieves can steal the $50,000 hidden under your mattress. If your WiFi driver is unprivileged, then the thieves have only broken through your front gate, and they can only steal your garden gnomes and plastic flamingoes. They need to combine the vulnerability with a local privilege escalation vulnerability, or be happy with the value of plastic flamingoes. > For fun, it is common for the "at rest" value of peddles to be discovered at connect time. The keyboard itself does this, either when it’s turned on, or through the configuration menu (or not at all). It’s not something that has anything to do with drivers or connecting the keyboard.
  - taeric 3y ago
    Applications are usually written to know that anything sent over the network could be lost. You don't usually do the same for sending to the different devices. Are you expecting retry logic in all places sending to a device? We /could/ turn all computation into remote procedure calls. There is plenty of precedence that that will not end well. You do it where you have to. Not everywhere. And fair point on the device learning its "off" position at startup. Though, that really leans into another point I made in another branch. That level of "isolated and can restart" is already largely accomplished by having extra compute on the devices you are connecting to. I really can't see much benefit it doing everything in the RPC paradigm. I get the promise. I'm not buying the evidence that you can solve this by making it transparent that all things are "servers" and some are remote.
    - klodolph 3y ago
      > Applications are usually written to know that anything sent over the network could be lost. Generally they are—when you make an HTTP request, the client waits until it receives an HTTP response before it reports success. > We /could/ turn all computation into remote procedure calls. There is plenty of precedence that that will not end well. You do it where you have to. Not everywhere. I think you may be having some kind of a different conversation here. I don’t understand your position, and I don’t think you understand mine.
      - taeric 3y ago
        Microkernels treating every system in the machine as a "service" is literally asking developers to treat everything as a distributed system. No? Was literally a selling point early on in the literature for them. There are good arguments for this in some environments.
- CRConrad 3y ago
  > For fun, it is common for the "at rest" value of pedals > to be discovered at connect time.

taeric 3y ago

It really depends on what all is done "in the driver," though? Since, per the application, the data may have been passed off to the driver with a successful message pass. And if I have to have secrets in the driver for it to be able to connect to access points and such, it seems dubious how protected from all of my secrets the system can be between all parties. MIDI is actually an easy example, all told. If I unplug and replug a keyboard in, I expect it to probably not handle any persistent state of the keyboard correctly. (For fun, it is common for the "at rest" value of peddles to be discovered at connect time. Good luck with that if the driver crashes.)

klodolph 3y ago
> Since, per the application, the data may have been passed off to the driver with a successful message pass. The application already knows that the data is not guaranteed to be delivered, or even sent at all. That’s just the nature of network programming—it’s inherently unreliable. > And if I have to have secrets in the driver for it to be able to connect to access points and such, it seems dubious how protected from all of my secrets the system can be between all parties. To make an analogy—locking your front door doesn’t protect thieves from stealing your plastic flamingoes and garden gnomes, but it does make it harder to steal the $50,000 in cash you have hidden under the mattress. The point of isolation is to reduce the effect of failures. If you have a buggy WiFi driver, in a monolithic kernel, that could be really bad—it could even be a remotely exploitable vulnerability in the kernel itself. In other words, you have no front door, and the thieves can steal the $50,000 hidden under your mattress. If your WiFi driver is unprivileged, then the thieves have only broken through your front gate, and they can only steal your garden gnomes and plastic flamingoes. They need to combine the vulnerability with a local privilege escalation vulnerability, or be happy with the value of plastic flamingoes. > For fun, it is common for the "at rest" value of peddles to be discovered at connect time. The keyboard itself does this, either when it’s turned on, or through the configuration menu (or not at all). It’s not something that has anything to do with drivers or connecting the keyboard.
- taeric 3y ago
  Applications are usually written to know that anything sent over the network could be lost. You don't usually do the same for sending to the different devices. Are you expecting retry logic in all places sending to a device? We /could/ turn all computation into remote procedure calls. There is plenty of precedence that that will not end well. You do it where you have to. Not everywhere. And fair point on the device learning its "off" position at startup. Though, that really leans into another point I made in another branch. That level of "isolated and can restart" is already largely accomplished by having extra compute on the devices you are connecting to. I really can't see much benefit it doing everything in the RPC paradigm. I get the promise. I'm not buying the evidence that you can solve this by making it transparent that all things are "servers" and some are remote.
  - klodolph 3y ago
    > Applications are usually written to know that anything sent over the network could be lost. Generally they are—when you make an HTTP request, the client waits until it receives an HTTP response before it reports success. > We /could/ turn all computation into remote procedure calls. There is plenty of precedence that that will not end well. You do it where you have to. Not everywhere. I think you may be having some kind of a different conversation here. I don’t understand your position, and I don’t think you understand mine.
    - taeric 3y ago
      Microkernels treating every system in the machine as a "service" is literally asking developers to treat everything as a distributed system. No? Was literally a selling point early on in the literature for them. There are good arguments for this in some environments.
CRConrad 3y ago
> For fun, it is common for the "at rest" value of pedals > to be discovered at connect time.