4 ms·

It's no worse than what Linux already allows via eBPF.

by pcwalton 8y ago

IncRnd 8y ago
So? Removing hw ring protections for all programs is not the answer. You are actually making my point.
- pcwalton 8y ago
  Is your position that Linux should remove eBPF?
  - IncRnd 8y ago
    That's not germane to this discussion. My position is that this project throws away defense in depth. Is your point that because eBPF exists in a different OS that there is no security impact to using Nebulet?
    - pcwalton 8y ago
      I think that having a user-accessible VM in the kernel is a useful thing that a lot of OS's eventually need for other reasons (e.g. packet filtering, syscall sandboxing). We might as well design for it properly up front.
      - IncRnd 8y ago
        Thank you for bringing that up. That's an entirely different discussion, and one that I agree is valid to have. Though, I really don't see the need for user space programs to be able to insert executable code into kernel memory, when hw ring protections would otherwise be in use. Maybe if there were already a verified set of interlocking software controls, then hw protections could be replaced, but I don't see that with running all wasm in the kernel space.
- _wmd 8y ago
  Hardware protection rings are a holdover from a time when we didn't have program formats that could be statically transformed and verified to do exactly what the operator desires. They have a nonzero performance overhead even when implemented in hardware, and in an ideal design should not be required at all Re: your followup about defensive in depth, this is a common and frankly boring fallback argument. At some point computers had much less reliable internals, and for example even the result of strlen () could vary across runs. Should we also perpetually account for the presence of unreliable registers or memory too?
  - IncRnd 8y ago
    That doesn't apply to this discussion. What program verification or analysis were performed on this system? My position about defense in depth is not a fallback argument. It was my original point.
  - kllrnohj 8y ago
    > when we didn't have program formats that could be statically transformed and verified to do exactly what the operator desires. Which we still don't. Rowhammer, spectre/meltdown, etc... proved that even if the code doesn't violate any sandbox constraints that doesn't mean it didn't violate everything the sandbox was attempting to protect. Hardware isolation is still very important and very necessary, now more than ever.
    - deleted 8y ago
      [deleted]
    - _wmd 8y ago
      JFC. The reason the bugs you refer to are so important is because they /spanned/ hardware protection domains.
      - kllrnohj 8y ago
        Yes, which means they also spanned software protection domains. Meaning your software protection didn't work, regardless of how "verifiable" the bytecode is. And a few of those so far have no known software protection domain fix, relying instead of hardware domains (eg spectre, which is why Chrome pushing site isolation hard - because they can't fix the software protection and are relying on hardware ones instead)
mort96 8y ago
Is a packet filter really as complex and with as much room for error as a WASM VM?
- gregdunn 8y ago
  BPF isn't just a packet filter. It's a JIT VM. This started back in 2011 with https://lwn.net/Articles/437981/ https://lwn.net/Articles/437981/ It's since been extended quite a bit from even that, and can be used for a variety of things, including dynamic tracing (BCC is an excellent frontend here), processing beyond just filtering (XDP), and more. https://lwn.net/Articles/740157/ https://lwn.net/Articles/740157/ It might be less complex than the WASM VM, but it's quite a bit beyond just a packet filter these days.

It's no worse than what Linux already allows via eBPF.

IncRnd 8y ago

So? Removing hw ring protections for all programs is not the answer. You are actually making my point.

pcwalton 8y ago
Is your position that Linux should remove eBPF?
- IncRnd 8y ago
  That's not germane to this discussion. My position is that this project throws away defense in depth. Is your point that because eBPF exists in a different OS that there is no security impact to using Nebulet?
  - pcwalton 8y ago
    I think that having a user-accessible VM in the kernel is a useful thing that a lot of OS's eventually need for other reasons (e.g. packet filtering, syscall sandboxing). We might as well design for it properly up front.
    - IncRnd 8y ago
      Thank you for bringing that up. That's an entirely different discussion, and one that I agree is valid to have. Though, I really don't see the need for user space programs to be able to insert executable code into kernel memory, when hw ring protections would otherwise be in use. Maybe if there were already a verified set of interlocking software controls, then hw protections could be replaced, but I don't see that with running all wasm in the kernel space.
_wmd 8y ago
Hardware protection rings are a holdover from a time when we didn't have program formats that could be statically transformed and verified to do exactly what the operator desires. They have a nonzero performance overhead even when implemented in hardware, and in an ideal design should not be required at all Re: your followup about defensive in depth, this is a common and frankly boring fallback argument. At some point computers had much less reliable internals, and for example even the result of strlen () could vary across runs. Should we also perpetually account for the presence of unreliable registers or memory too?
- IncRnd 8y ago
  That doesn't apply to this discussion. What program verification or analysis were performed on this system? My position about defense in depth is not a fallback argument. It was my original point.
- kllrnohj 8y ago
  > when we didn't have program formats that could be statically transformed and verified to do exactly what the operator desires. Which we still don't. Rowhammer, spectre/meltdown, etc... proved that even if the code doesn't violate any sandbox constraints that doesn't mean it didn't violate everything the sandbox was attempting to protect. Hardware isolation is still very important and very necessary, now more than ever.
  - deleted 8y ago
    [deleted]
  - _wmd 8y ago
    JFC. The reason the bugs you refer to are so important is because they /spanned/ hardware protection domains.
    - kllrnohj 8y ago
      Yes, which means they also spanned software protection domains. Meaning your software protection didn't work, regardless of how "verifiable" the bytecode is. And a few of those so far have no known software protection domain fix, relying instead of hardware domains (eg spectre, which is why Chrome pushing site isolation hard - because they can't fix the software protection and are relying on hardware ones instead)

mort96 8y ago

Is a packet filter really as complex and with as much room for error as a WASM VM?

gregdunn 8y ago
BPF isn't just a packet filter. It's a JIT VM. This started back in 2011 with https://lwn.net/Articles/437981/ https://lwn.net/Articles/437981/ It's since been extended quite a bit from even that, and can be used for a variety of things, including dynamic tracing (BCC is an excellent frontend here), processing beyond just filtering (XDP), and more. https://lwn.net/Articles/740157/ https://lwn.net/Articles/740157/ It might be less complex than the WASM VM, but it's quite a bit beyond just a packet filter these days.