On 01/04/2018 10:52, Brett Glass wrote:> At 08:01 AM 1/4/2018, Dag-Erling Sm??rgrav wrote: > >> This is irrelevant.? We are talking about timing-based side-channel >> attacks.? The attacker is not able to access protected memory directly, >> but is able to deduce its contents by repeatedly performing illegal >> memory accesses and then checking how they affect the cache. > > This is something I do not yet fully understand; perhaps someone here > on the list can help explain it to me. The "Spectre" attack is claimed > to work by altering the contents of the cache via a speculatively > executed instruction. But the contents of that memory are not revealed > directly to the program. So, how does it deduce the contents of physical > memory merely from the fact that there's a cache miss on its address?You can speculatively execute code based on the value of a fetched memory address, which may eventually fault. This can be used to pull things into cache, which can then be measured. The attack looks like this: 1) Fetch kernel/other process memory, which eventually faults 2) Do a bit-shift/mask operation to pluck out one bit of the fetched value. This gets executed speculatively on the fetched value in (1). 3) Execute fetches of two different addresses depending on some bit in the fetched value in (1) (say, 0x100000 for 0 vs 0x200000 for 1). This also gets executed speculatively despite the fact that (1) ends up faulting. 4) Recover from fault in (1) 5) Measure performance of accesses to the two addresses to determine which one is cached. The really terrible thing about this is that it suggests a *class* of attacks: side-channels based on CPU implementations, of which this is the first (and most obvious) one to be discovered. I suspect this is going to be dogging us for years to come.
At 09:03 AM 1/4/2018, Eric McCorkle wrote:>The attack looks like this: > >1) Fetch kernel/other process memory, which eventually faults >2) Do a bit-shift/mask operation to pluck out one bit of the fetched >value. This gets executed speculatively on the fetched value in (1). >3) Execute fetches of two different addresses depending on some bit in >the fetched value in (1) (say, 0x100000 for 0 vs 0x200000 for 1). This >also gets executed speculatively despite the fact that (1) ends up faulting. >4) Recover from fault in (1) >5) Measure performance of accesses to the two addresses to determine >which one is cached.Hmmmm. The obvious way to combat this would be to make this class of fault fatal rather than allowing recovery to occur. Of course, this would reveal errors in sloppy code, which some developers would not like. (I recall how much some folks squawked back in the olden days, when segmentation faults - remember segments? - revealed bugs in their code. I, personally, liked segmentation because I was a perfectionist.... I wanted my code to crash dramatically if there was an error so I could fix it.) --Brett Glass
In message <736a2b77-d4a0-b03f-8a6b-6a717f5744d4 at metricspace.net>, Eric McCorkle <eric at metricspace.net> wrote:>The attack looks like this: > >1) Fetch kernel/other process memory, which eventually faults >2) Do a bit-shift/mask operation to pluck out one bit of the fetched >value. This gets executed speculatively on the fetched value in (1). >3) Execute fetches of two different addresses depending on some bit in >the fetched value in (1) (say, 0x100000 for 0 vs 0x200000 for 1). This >also gets executed speculatively despite the fact that (1) ends up faulting. >4) Recover from fault in (1) >5) Measure performance of accesses to the two addresses to determine >which one is cached.I must say, that's one hell of a round-about way to read just one bit that you wern't supposed to have access to. But of course, that doesn't really matter if you are an attacker. If the above steps can be repeated, programatically, ad infinitum, to read bits from "protected" memory... and I see no reason why they can't be... then yea, this bug is every bit as bad as the media is making it out to be, and maybe even worse. All your secrets are belong to us! Time to invest in abacuses... or is that abacai? Regards, rfg