3 ms·

> With properly designed OoO, Spectre cannot defeat process isolation It's worth noting that no existing or announced common hardware is "properly designed" ac

by twtw 8y ago

> With properly designed OoO, Spectre cannot defeat process isolation It's worth noting that no existing or announced common hardware is "properly designed" according to this condition. Even the "fixed" Intel hardware that's been announced is still vulnerable to spectre v1 across process boundaries.

Zenst 8y ago
I'm not aware of a spectre v1 attack for the altair 8800, or indeed any of the CPU's of that era, Z80, 6502, 8086/8.... But then, things moved on, standard ways to add more cache with multiple cores was lapped up and later on we found a design flaw that echoed back for a decade or more upon all these multi-core CPU's. Though in fairness and to put some context upon all this, CPU design is more complex than writing TAX laws. Yet we have exploits for TAX laws appearing and used all the time by large corporations. Whilst the comparison is not ideal and some would say, unfair. It does highlight that nothing is perfect and what we may class as perfect today (or darn close), could and may very well be classed as swiss cheese in the future. It gets down to how far away that future is. After all, we still have encryption utilised that we have (on paper) shown to be flawed to future quantum CPU's! But in a World that was aware of Y2k decades before the event, the penchant of business to drive everything to the last minute for profit will always be a factor in advancements. After all, if CPU cores had isolated caches instead of sharing, then that would mitigate so many issues, yet it would cost more to make and most consumers would not appreciate the extra cost for what to them is little value in return above and beyond the cheaper solution. That's business for you and CPU's are made by them for profit.
Tuna-Fish 8y ago
> It's worth noting that no existing or announced common hardware is "properly designed" according to this condition. Even the "fixed" Intel hardware that's been announced is still vulnerable to spectre v1 across process boundaries. AMD Zen is. Spectre v1 (bounds check bypass) only works inside processes. All it allows you to do is to read any memory location currently mapped into your address space, and so it gives anything that can execute code complete read access to the address space of the process it's running in. On Intel CPUs, this also allows reading the kernel address space, unless kpti is used. Eventually, the ability to read kernel memory will be removed, and so kpti becomes unneccessary. On all AMD post-BD cpus, spectre v1 cannot be used to read kernel address space. All the rest of spectre (and meltdown) can eventually be fixed, but it is effectively impossible to make a cpu that is both fast and doesn't exhibit spectre v1.
- twtw 8y ago
  > Spectre v1 (bounds check bypass) only works inside processes I don't think this is true. If it is, why did Linux add speculation barriers to bounds checks in the kernel? I was in a discussion of this last week on another thread - see my previous comments for why I think spectre v1 has impact across processes.
  - gpderetta 8y ago
    Hi twtw, I think you were having that discussion with me. So, I went and read the whole lkml threads you linked and if I understood correctly, regarding spectre v1, the kernel is only expected vulnerable to bpf based attacks or similar. As far as I understand, the speculation barriers are used to protect arrays directly accessible by bpf programs. There is a mention of out of process attacks to other userspace programs, but no details. By carefully crafting inputs, I'm ready to admit that it might be theoretical ly possible to attack some exploitable branches, but the big deal with spectre is the high bandwidth that can be attained by directly running code in process. Do you have any pointer to any description of an even remotely practical out of process spectre v1 attack that doesn't involve executing code in process? Repurposing an interface that is not meant to be used to run code (I e. Build your own VM) is fair game.
    - twtw 8y ago
      Here's alan cox saying what I've been trying to say, from https://marc.info/?l=linux-kernel&m=151503218808512&w=2 https://marc.info/?l=linux-kernel&m=151503218808512&w=2: > If you read the papers you need a very specific construct in order to not only cause a speculative load of an address you choose but also to then manage to cause a second operation that in some way reveals bits of data or allows you to ask questions. > BPF allows you to construct those sequences relatively easily and it's the one case where a user space application can fairly easily place code it wants to execute in the kernel. Without BPF you have to find the right construct in the kernel, prime all the right predictions and measure the result without getting killed off. There are places you can do that but they are not so easy and we don't (at this point) think there are that many. > The same situation occurs in user space with interpreters and JITs,hence the paper talking about javascript. Any JIT with the ability to do timing is particularly vulnerable to versions of this specific attack because the attacker gets to create the code pattern rather than have to find it. --- > big deal with spectre is the high bandwidth that can be attained by directly running code in process That depends on your perspective. If you are an OS developer who strives to guarantee process isolation, than it is a pretty big deal that spectre v1 allows you to read memory from the kernel or from other processes, even if it might be tricky to do so. If you write a JS JIT, then yeah you are probably most concerned about the single-process case. > remotely practical IMO, most spectre attacks are not remotely practical. No, I don't have a pointer. The only actual demonstrations of spectre I've seen is the one included with the original paper (single process).

by twtw 8y ago

Zenst 8y ago

I'm not aware of a spectre v1 attack for the altair 8800, or indeed any of the CPU's of that era, Z80, 6502, 8086/8.... But then, things moved on, standard ways to add more cache with multiple cores was lapped up and later on we found a design flaw that echoed back for a decade or more upon all these multi-core CPU's. Though in fairness and to put some context upon all this, CPU design is more complex than writing TAX laws. Yet we have exploits for TAX laws appearing and used all the time by large corporations. Whilst the comparison is not ideal and some would say, unfair. It does highlight that nothing is perfect and what we may class as perfect today (or darn close), could and may very well be classed as swiss cheese in the future. It gets down to how far away that future is. After all, we still have encryption utilised that we have (on paper) shown to be flawed to future quantum CPU's! But in a World that was aware of Y2k decades before the event, the penchant of business to drive everything to the last minute for profit will always be a factor in advancements. After all, if CPU cores had isolated caches instead of sharing, then that would mitigate so many issues, yet it would cost more to make and most consumers would not appreciate the extra cost for what to them is little value in return above and beyond the cheaper solution. That's business for you and CPU's are made by them for profit.

Tuna-Fish 8y ago

> It's worth noting that no existing or announced common hardware is "properly designed" according to this condition. Even the "fixed" Intel hardware that's been announced is still vulnerable to spectre v1 across process boundaries. AMD Zen is. Spectre v1 (bounds check bypass) only works inside processes. All it allows you to do is to read any memory location currently mapped into your address space, and so it gives anything that can execute code complete read access to the address space of the process it's running in. On Intel CPUs, this also allows reading the kernel address space, unless kpti is used. Eventually, the ability to read kernel memory will be removed, and so kpti becomes unneccessary. On all AMD post-BD cpus, spectre v1 cannot be used to read kernel address space. All the rest of spectre (and meltdown) can eventually be fixed, but it is effectively impossible to make a cpu that is both fast and doesn't exhibit spectre v1.

twtw 8y ago
> Spectre v1 (bounds check bypass) only works inside processes I don't think this is true. If it is, why did Linux add speculation barriers to bounds checks in the kernel? I was in a discussion of this last week on another thread - see my previous comments for why I think spectre v1 has impact across processes.
- gpderetta 8y ago
  Hi twtw, I think you were having that discussion with me. So, I went and read the whole lkml threads you linked and if I understood correctly, regarding spectre v1, the kernel is only expected vulnerable to bpf based attacks or similar. As far as I understand, the speculation barriers are used to protect arrays directly accessible by bpf programs. There is a mention of out of process attacks to other userspace programs, but no details. By carefully crafting inputs, I'm ready to admit that it might be theoretical ly possible to attack some exploitable branches, but the big deal with spectre is the high bandwidth that can be attained by directly running code in process. Do you have any pointer to any description of an even remotely practical out of process spectre v1 attack that doesn't involve executing code in process? Repurposing an interface that is not meant to be used to run code (I e. Build your own VM) is fair game.
  - twtw 8y ago
    Here's alan cox saying what I've been trying to say, from https://marc.info/?l=linux-kernel&m=151503218808512&w=2 https://marc.info/?l=linux-kernel&m=151503218808512&w=2: > If you read the papers you need a very specific construct in order to not only cause a speculative load of an address you choose but also to then manage to cause a second operation that in some way reveals bits of data or allows you to ask questions. > BPF allows you to construct those sequences relatively easily and it's the one case where a user space application can fairly easily place code it wants to execute in the kernel. Without BPF you have to find the right construct in the kernel, prime all the right predictions and measure the result without getting killed off. There are places you can do that but they are not so easy and we don't (at this point) think there are that many. > The same situation occurs in user space with interpreters and JITs,hence the paper talking about javascript. Any JIT with the ability to do timing is particularly vulnerable to versions of this specific attack because the attacker gets to create the code pattern rather than have to find it. --- > big deal with spectre is the high bandwidth that can be attained by directly running code in process That depends on your perspective. If you are an OS developer who strives to guarantee process isolation, than it is a pretty big deal that spectre v1 allows you to read memory from the kernel or from other processes, even if it might be tricky to do so. If you write a JS JIT, then yeah you are probably most concerned about the single-process case. > remotely practical IMO, most spectre attacks are not remotely practical. No, I don't have a pointer. The only actual demonstrations of spectre I've seen is the one included with the original paper (single process).