6 ms·

We have a security document that addresses the big picture, and this specific concern as well: https://github.com/fastly/lucet/blob/master/SECURITY.md#caveats h

We have a security document that addresses the big picture, and this specific concern as well: https://github.com/fastly/lucet/blob/master/SECURITY.md#caveats https://github.com/fastly/lucet/blob/master/SECURITY.md#cave... For speculative execution, we don't yet implement all of the mitigations possible in Lucet, but will in the near future.

tick_tock_tick 8y ago
So currently it does compromise on security? Seems extremely misleading to claim any security if you are just currently ignoring the last years worth of major security issues.
- Yetanfou 8y ago
  From what I gather the thing is based on WASI which in early beta and for which many parts don't exist or don't work, networking and file access being a few of those [1]: Note that everything here is a prototype, and while a lot of stuff works, there are numerous missing features and some rough edges. One big thing that's not done yet is the actual mechanism to provide a directory as a pre-opened capability, to allow files to be opened. Some of the pieces are there (__wasilibc_register_preopened_fd) but they're not used yet. Networking support is also incomplete. In other words, this is a somewhat premature announcement when it comes to fulfilling those promises. [1] https://github.com/CraneStation/wasmtime/blob/master/docs/WASI-intro.md https://github.com/CraneStation/wasmtime/blob/master/docs/WA...
  - sunfish 8y ago
    That sentence about pre-opened directory capabilities not being supported is actually outdated. They're supported now, so I've now updated the documentation. Thanks for pointing that out!
- kllrnohj 8y ago
  It also compromises on resource abuse: "lucet does not currently provide a framework for protecting against guests that consume excessive CPU time (e.g. via an infinite loop). These protections must be provided by the host environment." I'm not sure how you're supposed to handle that, either, given host environment usually does limiting at a process granularity but this doesn't use multiple processes.
  - int_19h 8y ago
    Most OSes have a way to specify priority for a given thread.
    - kllrnohj 8y ago
      Priority yes, but that's barely useful. cgroups, rlimits, cpulimit, etc... are far more useful here, and are all per-process.
      - kentonv 8y ago
        You can use timer_create to arrange to deliver a signal after some amount of CPU time elapsed, then terminate the sandbox from the signal handler.
kllrnohj 8y ago
Given that in-process sandboxing in the face of spectre is currently an unsolved problem, how do you plan on actually addressing it? The only established mitigation at this point is to just use process isolation, so what's the plan or is there just not one?
- haimez 8y ago
  Even interprocess isolation is not a solved problem in the face of SMT (hyperthreading), so yes- there is none. You simply can’t deliver these kinds of shared metal products and defend against cache timing attacks. You also can’t deliver these kinds of products at this price and be profitable without sharing metal, so here we are. If you care about being isolated, you can’t share hardware- simple as that.
  - kllrnohj 8y ago
    There's a huge difference in viability & mitigations here, though. In a shared metal system a portsmash attack isn't likely to be practically viable, and worst case is sched affinity or similar is used to just firewall off processes from co-inhabiting the same physical core. Kernel scheduler could even do this in a clever way, this has a very clear path to which it is basically fully mitigated. So all signs point to shared metal still being viable security-wise, with mitigations either already deployed or pretty straightforward. Shared hardware will remain totally fine. Shared-process, though, nobody is really talking about making that viable from a security perspective.
amelius 8y ago
It would be interesting to see if you could compile+run+reproduce this: https://github.com/flxwu/spectre-attack-demo https://github.com/flxwu/spectre-attack-demo

tick_tock_tick 8y ago

So currently it does compromise on security? Seems extremely misleading to claim any security if you are just currently ignoring the last years worth of major security issues.

Yetanfou 8y ago
From what I gather the thing is based on WASI which in early beta and for which many parts don't exist or don't work, networking and file access being a few of those [1]: Note that everything here is a prototype, and while a lot of stuff works, there are numerous missing features and some rough edges. One big thing that's not done yet is the actual mechanism to provide a directory as a pre-opened capability, to allow files to be opened. Some of the pieces are there (__wasilibc_register_preopened_fd) but they're not used yet. Networking support is also incomplete. In other words, this is a somewhat premature announcement when it comes to fulfilling those promises. [1] https://github.com/CraneStation/wasmtime/blob/master/docs/WASI-intro.md https://github.com/CraneStation/wasmtime/blob/master/docs/WA...
- sunfish 8y ago
  That sentence about pre-opened directory capabilities not being supported is actually outdated. They're supported now, so I've now updated the documentation. Thanks for pointing that out!
kllrnohj 8y ago
It also compromises on resource abuse: "lucet does not currently provide a framework for protecting against guests that consume excessive CPU time (e.g. via an infinite loop). These protections must be provided by the host environment." I'm not sure how you're supposed to handle that, either, given host environment usually does limiting at a process granularity but this doesn't use multiple processes.
- int_19h 8y ago
  Most OSes have a way to specify priority for a given thread.
  - kllrnohj 8y ago
    Priority yes, but that's barely useful. cgroups, rlimits, cpulimit, etc... are far more useful here, and are all per-process.
    - kentonv 8y ago
      You can use timer_create to arrange to deliver a signal after some amount of CPU time elapsed, then terminate the sandbox from the signal handler.

kllrnohj 8y ago

Given that in-process sandboxing in the face of spectre is currently an unsolved problem, how do you plan on actually addressing it? The only established mitigation at this point is to just use process isolation, so what's the plan or is there just not one?

haimez 8y ago
Even interprocess isolation is not a solved problem in the face of SMT (hyperthreading), so yes- there is none. You simply can’t deliver these kinds of shared metal products and defend against cache timing attacks. You also can’t deliver these kinds of products at this price and be profitable without sharing metal, so here we are. If you care about being isolated, you can’t share hardware- simple as that.
- kllrnohj 8y ago
  There's a huge difference in viability & mitigations here, though. In a shared metal system a portsmash attack isn't likely to be practically viable, and worst case is sched affinity or similar is used to just firewall off processes from co-inhabiting the same physical core. Kernel scheduler could even do this in a clever way, this has a very clear path to which it is basically fully mitigated. So all signs point to shared metal still being viable security-wise, with mitigations either already deployed or pretty straightforward. Shared hardware will remain totally fine. Shared-process, though, nobody is really talking about making that viable from a security perspective.

amelius 8y ago

It would be interesting to see if you could compile+run+reproduce this: https://github.com/flxwu/spectre-attack-demo https://github.com/flxwu/spectre-attack-demo