3 ms·

I didn't even know rings 1 and 2 were even relegated to the dustbin.... so everything is ring 0 now?? Which brings me to another something I don't understand a

by tomc1985 9y ago

I didn't even know rings 1 and 2 were even relegated to the dustbin.... so everything is ring 0 now?? Which brings me to another something I don't understand about this. If mispredictions leave their calculations in cache why can't that cached data be cleared after the branch is determined to be bad?

monocasa 9y ago
> I didn't even know rings 1 and 2 were even relegated to the dustbin.... so everything is ring 0 now?? It's all either ring 3 (user) or ring 0 (kernel) for the purposes of this discussion. The biggest architectural impediment is the single bit for ring selection in page table entries. And since long mode requires paging, there's currently not a way to select rings 1 and 2. Although you might be able to play with some of the hypervisor extensions to give you guest ring 0 context inside a regular user process... See Akaros for a good example of what that looks like. > Which brings me to another something I don't understand about this. If mispredictions leave their calculations in cache why can't that cached data be cleared after the branch is determined to be bad? Because the cache is a fixed size, and that just kicks the can down the road. You'll just test for the eviction in your exploit instead.
deleted 9y ago
[deleted]
CamperBob2 9y ago
If mispredictions leave their calculations in cache why can't that cached data be cleared after the branch is determined to be bad? "Clearing the cached data" is just as detectable as caching the data in the first place. You'd have to treat the line fill as a transaction that could be rolled back. Unfortunately, transactional memory and CPU caches lie at polar-opposite ends of the performance spectrum.
- caf 9y ago
  You don't have to roll it back, you could have speculated loads store into a speculation buffer rather than directly into the cache, then at retirement the spec buffer entry is committed to the cache.
  - CamperBob2 9y ago
    Perhaps, but isn't the time taken by the line fill ultimately what's leaking the information? Sure, it's probed by monitoring L1 eviction, but I'd still be nervous about the timing. IMHO the only safe way to do a fetch from prohibited memory is to not do it at all.
    - caf 9y ago
      No, you can't time what happens on the mis-speculated path itself. What's leaking the information is the change to the cache state which is observable after the original mis-speculated branch is resolved (by timing subsequent accesses to addresses that alias in the cache). You can also observe changes to the TLB state, though - so you'd have to do the same buffering-and-commit dance there as well. Maybe you can also leak data through the BTB or RTB (double-Spectre!), or by tieing up particular execution units conditionally which is observable by a sibling hyperthread?

monocasa 9y ago

> I didn't even know rings 1 and 2 were even relegated to the dustbin.... so everything is ring 0 now?? It's all either ring 3 (user) or ring 0 (kernel) for the purposes of this discussion. The biggest architectural impediment is the single bit for ring selection in page table entries. And since long mode requires paging, there's currently not a way to select rings 1 and 2. Although you might be able to play with some of the hypervisor extensions to give you guest ring 0 context inside a regular user process... See Akaros for a good example of what that looks like. > Which brings me to another something I don't understand about this. If mispredictions leave their calculations in cache why can't that cached data be cleared after the branch is determined to be bad? Because the cache is a fixed size, and that just kicks the can down the road. You'll just test for the eviction in your exploit instead.

deleted 9y ago

[deleted]

CamperBob2 9y ago

If mispredictions leave their calculations in cache why can't that cached data be cleared after the branch is determined to be bad? "Clearing the cached data" is just as detectable as caching the data in the first place. You'd have to treat the line fill as a transaction that could be rolled back. Unfortunately, transactional memory and CPU caches lie at polar-opposite ends of the performance spectrum.

caf 9y ago
You don't have to roll it back, you could have speculated loads store into a speculation buffer rather than directly into the cache, then at retirement the spec buffer entry is committed to the cache.
- CamperBob2 9y ago
  Perhaps, but isn't the time taken by the line fill ultimately what's leaking the information? Sure, it's probed by monitoring L1 eviction, but I'd still be nervous about the timing. IMHO the only safe way to do a fetch from prohibited memory is to not do it at all.
  - caf 9y ago
    No, you can't time what happens on the mis-speculated path itself. What's leaking the information is the change to the cache state which is observable after the original mis-speculated branch is resolved (by timing subsequent accesses to addresses that alias in the cache). You can also observe changes to the TLB state, though - so you'd have to do the same buffering-and-commit dance there as well. Maybe you can also leak data through the BTB or RTB (double-Spectre!), or by tieing up particular execution units conditionally which is observable by a sibling hyperthread?