4 ms·

> I don't buy it. Windows provides stable driver ABIs and works just fine. Depends on the driver, but often they are buggy and will never be updated for the li

by flukus 9y ago

> I don't buy it. Windows provides stable driver ABIs and works just fine. Depends on the driver, but often they are buggy and will never be updated for the life of a device. Once a device has been sold the manufacturer doesn't care about support. Most linux CVE's are in drivers, imagine how many are lurking in the binary blobs of random third parties?

quotemstr 9y ago
> Most linux CVE's are in drivers, imagine how many are lurking in the binary blobs of random third parties? That's why we should sandbox drivers as much as possible! I'm a big fan of punting a lot of driver work to userspace. How are we supposed to do that if drivers are allowed to use the entire Linux kernel internal API and do whatever they want? How can we possibly isolate a driver that thinks it has the right to take mmap_sem and twiddle PTE bits?
- catern 9y ago
  Sandboxing isn't a substitute for having your drivers be open source. Even if all drivers were written in safe languages, you'd still have CVEs and still want to fix those CVEs.
  - quotemstr 9y ago
    Closed source Linux drivers exist. Open source Windows drivers exist. An unstable kernel ABI is neither necessary nor sufficient a condition for open sourcing drivers.
    - catern 9y ago
      True but irrelevant. The key new "feature" of Fuschia is that its stable ABI makes closed-source drivers easier to write in the short term, relative to Linux. As a result, the vast majority of Fuschia drivers will be closed-source. Don't you agree? I believe supporting a stable API and closed-source drivers will result in a technically inferior, more complex, less stable kernel. The Linux model of including all the drivers in a single open source codebase, where the drivers can be refactored and improved along with the rest of the kernel, is a genuinely superior way to develop a kernel, which produces a genuinely technically superior product. I just hope Google realizes this before they sink too many millions into Fuschia.
      - quotemstr 9y ago
        I think we can at least agree that the proof is in the pudding.
  - naasking 9y ago
    You seriously think that open source drivers would have fewer CVEs than sandboxed drivers?
    - catern 9y ago
      How exactly are you going to sandbox your drivers? Run them in user-mode, perhaps? But then you've constructed a microkernel, and no-one uses your system because it's slow. Anyway, what I said is that sandboxing isn't a substitute for open-sourcing. They are complements, not substitutes.
      - naasking 9y ago
        > But then you've constructed a microkernel, and no-one uses your system because it's slow. FUD. L4 is the most widely deployed kernel in the world. > Anyway, what I said is that sandboxing isn't a substitute for open-sourcing. Given reality, something must substitute for open source drivers. Sandboxing is certainly the obvious choice.
        catern 9y ago
        >Given reality, something must substitute for open source drivers Linux is quite real, I assure you.

by flukus 9y ago

quotemstr 9y ago

> Most linux CVE's are in drivers, imagine how many are lurking in the binary blobs of random third parties? That's why we should sandbox drivers as much as possible! I'm a big fan of punting a lot of driver work to userspace. How are we supposed to do that if drivers are allowed to use the entire Linux kernel internal API and do whatever they want? How can we possibly isolate a driver that thinks it has the right to take mmap_sem and twiddle PTE bits?

catern 9y ago
Sandboxing isn't a substitute for having your drivers be open source. Even if all drivers were written in safe languages, you'd still have CVEs and still want to fix those CVEs.
- quotemstr 9y ago
  Closed source Linux drivers exist. Open source Windows drivers exist. An unstable kernel ABI is neither necessary nor sufficient a condition for open sourcing drivers.
  - catern 9y ago
    True but irrelevant. The key new "feature" of Fuschia is that its stable ABI makes closed-source drivers easier to write in the short term, relative to Linux. As a result, the vast majority of Fuschia drivers will be closed-source. Don't you agree? I believe supporting a stable API and closed-source drivers will result in a technically inferior, more complex, less stable kernel. The Linux model of including all the drivers in a single open source codebase, where the drivers can be refactored and improved along with the rest of the kernel, is a genuinely superior way to develop a kernel, which produces a genuinely technically superior product. I just hope Google realizes this before they sink too many millions into Fuschia.
    - quotemstr 9y ago
      I think we can at least agree that the proof is in the pudding.
- naasking 9y ago
  You seriously think that open source drivers would have fewer CVEs than sandboxed drivers?
  - catern 9y ago
    How exactly are you going to sandbox your drivers? Run them in user-mode, perhaps? But then you've constructed a microkernel, and no-one uses your system because it's slow. Anyway, what I said is that sandboxing isn't a substitute for open-sourcing. They are complements, not substitutes.
    - naasking 9y ago
      > But then you've constructed a microkernel, and no-one uses your system because it's slow. FUD. L4 is the most widely deployed kernel in the world. > Anyway, what I said is that sandboxing isn't a substitute for open-sourcing. Given reality, something must substitute for open source drivers. Sandboxing is certainly the obvious choice.
      - catern 9y ago
        >Given reality, something must substitute for open source drivers Linux is quite real, I assure you.