6 ms·

The papers linked are from 2013. Now we know the implications of Spectre make kernel JITs a potential vulnerability. You should not run untrusted code in the s

by titzer 7y ago

The papers linked are from 2013. Now we know the implications of Spectre make kernel JITs a potential vulnerability. You should not run untrusted code in the same address space with secrets it could steal.

AstralStorm 7y ago
Trusted and trustworthy is the counterpart to proven. Where you assume something is secure instead of proving it to be secure.
- tgragnato 7y ago
  You usually prove something with formal verification, and it fails when the assumptions of the underlying model are wrong. Take the axioms with a grain of salt.
  - rurban 7y ago
    Exactly, the array offset rules are missing important parts. Not just bounds checks, but also offsets larger than a page table need to be forbidden. (Spectre). IMHO arrays should be forbidden at all, replaced by a secure hash map, with a max size.
    - monocasa 7y ago
      Way to completely destroy perf by making your memory accesses totally random.
      - rurban 7y ago
        Exactly, People need to feel how bad it is to allow anyone getting user-space access into the kernel. It needs to hurt. But the prime reason is security. solaris and freebsd do have their reasons to disallow arrays in their kernel hooks.
        monocasa 7y ago
        Most Spectre variants are exploitable via specially crafted data, not just code injection. Hell, NetSpectre is remotely exploitable. Being super ascetic about what code is allowed in the kernel isn't an endgame here. We don't need to take cross domain VMs completely off the table; we just need better ways of describing those security boundaries to the hardware. It's been done before. Some of Azul's secret sauce was additional cheap security modes in the MMU that they leveraged for their GC.
        AstralStorm 7y ago
        That works, sort of, but how do you even ensure the hardware is actually working? Trust Intel or ARM after what they've shown? And trying to fully bypass cache and speculation when doing userspace to/from kernel transfers is going to suck. Remapping pages also. And if MMU is untrustworthy, well...
        monocasa 7y ago
        > That works, sort of, but how do you even ensure the hardware is actually working? Trust Intel or ARM after what they've shown? Which part are you referring to? > And trying to fully bypass cache and speculation when doing userspace to/from kernel transfers is going to suck. Remapping pages also. Here's a demonstration of doing it remotely, with specially crafted network packets. https://arxiv.org/abs/1807.10535 https://arxiv.org/abs/1807.10535 It's not as hard as you're making it seem, the root here is that hardware is currently broken. > And if MMU is untrustworthy, well... If the MMU is untrustworthy, it doesn't matter if you allow a cross domain VM or not.
candiodari 7y ago
Didn't spectre work cross-address-space ? I mean the whole point of the spectre vulnerability was that one process read kernel memory or another process' memory. So that would make executing any code anywhere on the same cpu (anything behind the same cache) potentially vulnerable. JIT or not, kernel or not, ...
- lucian1900 7y ago
  That's Meltdown, the Intel bug in memory isolation. Spectre is a CPU cache timing attack to derive data. Cache lines are cleared in between context switches, so it can only affect the same process.
  - monocasa 7y ago
    Cache lines aren't cleared on context switches, and there are Spectre variants that are cross address space. There's even a remote Spectre exploit. https://arxiv.org/abs/1807.10535 https://arxiv.org/abs/1807.10535
    - lucian1900 7y ago
      Oh. I entirely misunderstood, then. I stand corrected.
- CalChris 7y ago
  No, it was not cross address space. Actually the kernel was mapped into the high address space of every process (so it was the same address space) and the kernel mapped all of physical memory. So all of physical memory was mapped into every process' logical address space. This was OK because user processes didn't have the privilege to actually read those kernel pages. But Spectre+Meltdown bypassed the privilege enforcement to speculatively read any location and then bled that information back out via a microarchitectural channel. The solution was kernel page table isolation. Don't map the kernel and thus all of physical memory into each process. However, this now has the overhead of mapping and unmapping the kernel pages for each context switch.
monocasa 7y ago
They're just going to have to fix their broken hardware. There are Spectre variants that work cross address space. Hell, there's a Spectre variant that works remotely, with carefully crafted network packets. https://arxiv.org/abs/1807.10535 https://arxiv.org/abs/1807.10535 And don't give me that "oh, we'd have to give up speculation and OoO cores to in order to properly fix Spectre". No, we just need more than two security domains so we can describe to the processor which code should have access to which data. Make Rings 1 & 2 Great Again.

by titzer 7y ago

AstralStorm 7y ago

Trusted and trustworthy is the counterpart to proven. Where you assume something is secure instead of proving it to be secure.

tgragnato 7y ago
You usually prove something with formal verification, and it fails when the assumptions of the underlying model are wrong. Take the axioms with a grain of salt.
- rurban 7y ago
  Exactly, the array offset rules are missing important parts. Not just bounds checks, but also offsets larger than a page table need to be forbidden. (Spectre). IMHO arrays should be forbidden at all, replaced by a secure hash map, with a max size.
  - monocasa 7y ago
    Way to completely destroy perf by making your memory accesses totally random.
    - rurban 7y ago
      Exactly, People need to feel how bad it is to allow anyone getting user-space access into the kernel. It needs to hurt. But the prime reason is security. solaris and freebsd do have their reasons to disallow arrays in their kernel hooks.
      - monocasa 7y ago
        Most Spectre variants are exploitable via specially crafted data, not just code injection. Hell, NetSpectre is remotely exploitable. Being super ascetic about what code is allowed in the kernel isn't an endgame here. We don't need to take cross domain VMs completely off the table; we just need better ways of describing those security boundaries to the hardware. It's been done before. Some of Azul's secret sauce was additional cheap security modes in the MMU that they leveraged for their GC.
        AstralStorm 7y ago
        That works, sort of, but how do you even ensure the hardware is actually working? Trust Intel or ARM after what they've shown? And trying to fully bypass cache and speculation when doing userspace to/from kernel transfers is going to suck. Remapping pages also. And if MMU is untrustworthy, well...
        monocasa 7y ago
        > That works, sort of, but how do you even ensure the hardware is actually working? Trust Intel or ARM after what they've shown? Which part are you referring to? > And trying to fully bypass cache and speculation when doing userspace to/from kernel transfers is going to suck. Remapping pages also. Here's a demonstration of doing it remotely, with specially crafted network packets. https://arxiv.org/abs/1807.10535 https://arxiv.org/abs/1807.10535 It's not as hard as you're making it seem, the root here is that hardware is currently broken. > And if MMU is untrustworthy, well... If the MMU is untrustworthy, it doesn't matter if you allow a cross domain VM or not.

candiodari 7y ago

Didn't spectre work cross-address-space ? I mean the whole point of the spectre vulnerability was that one process read kernel memory or another process' memory. So that would make executing any code anywhere on the same cpu (anything behind the same cache) potentially vulnerable. JIT or not, kernel or not, ...

lucian1900 7y ago
That's Meltdown, the Intel bug in memory isolation. Spectre is a CPU cache timing attack to derive data. Cache lines are cleared in between context switches, so it can only affect the same process.
- monocasa 7y ago
  Cache lines aren't cleared on context switches, and there are Spectre variants that are cross address space. There's even a remote Spectre exploit. https://arxiv.org/abs/1807.10535 https://arxiv.org/abs/1807.10535
  - lucian1900 7y ago
    Oh. I entirely misunderstood, then. I stand corrected.
CalChris 7y ago
No, it was not cross address space. Actually the kernel was mapped into the high address space of every process (so it was the same address space) and the kernel mapped all of physical memory. So all of physical memory was mapped into every process' logical address space. This was OK because user processes didn't have the privilege to actually read those kernel pages. But Spectre+Meltdown bypassed the privilege enforcement to speculatively read any location and then bled that information back out via a microarchitectural channel. The solution was kernel page table isolation. Don't map the kernel and thus all of physical memory into each process. However, this now has the overhead of mapping and unmapping the kernel pages for each context switch.

monocasa 7y ago

They're just going to have to fix their broken hardware. There are Spectre variants that work cross address space. Hell, there's a Spectre variant that works remotely, with carefully crafted network packets. https://arxiv.org/abs/1807.10535 https://arxiv.org/abs/1807.10535 And don't give me that "oh, we'd have to give up speculation and OoO cores to in order to properly fix Spectre". No, we just need more than two security domains so we can describe to the processor which code should have access to which data. Make Rings 1 & 2 Great Again.