3 ms·

It's even more complex. It's not only the predictor state that would need switching/indexing, it's the result of any prediction. A speculative load in cache is

by yaantc 8y ago

It's even more complex. It's not only the predictor state that would need switching/indexing, it's the result of any prediction. A speculative load in cache is global today, and that leads to a possible side channel attack. One may think about marking a speculatively cached entry by its security context, the only context allowed to "see" it until the speculation is resolved. But that is not enough: the entry may have evicted another, and that's globally visible. Or one may not use the regular caches, but add another lookup structure (CAM) for in-fly speculative loads (and same for store), indexed by context. Another source of complexity is: what is a security context? An OS could use existing structures like processes, and it makes sense, but it's not enough. For a sandboxed application a given process or thread could run untrusted sandboxed code (Javascript) and also trusted runtime. In this case, the application need to help and manage security contexts. It's possible, but not backward compatible. I expect progress will be made, but considering the complexity/costs it may take some time...

titzer 8y ago
> It's even more complex. Oh, this one goes elbows, armpits, neck, ten thousand fathoms deep. Now just imagine that every memory access that the processor does actually consumes another type of resource, which is memory bandwidth. There are a limited number of cache-fill lines and those can be occupied or not; after tracking down all of the state of things at rest, you now have to think about the information leakage from the occupancy of the various networks of the CPU--data in flight. Tougher to analyze, but also tougher to secure. It's gonna be separate CPUs, memory busses, and disks if we really want to get rid of side-channels. And that's actually simple. Simple is better for security!
- hinkley 8y ago
  Wouldn't this mean that kernel calls are interprocess communication?
  - titzer 8y ago
    In general, yes. But one could, e.g. have a second kernel, or some microkernel subsystems, running on the other system for the most common calls. In fact, that'd be even safer. It'd be safest to have a whole machine per process :)

by yaantc 8y ago

titzer 8y ago

> It's even more complex. Oh, this one goes elbows, armpits, neck, ten thousand fathoms deep. Now just imagine that every memory access that the processor does actually consumes another type of resource, which is memory bandwidth. There are a limited number of cache-fill lines and those can be occupied or not; after tracking down all of the state of things at rest, you now have to think about the information leakage from the occupancy of the various networks of the CPU--data in flight. Tougher to analyze, but also tougher to secure. It's gonna be separate CPUs, memory busses, and disks if we really want to get rid of side-channels. And that's actually simple. Simple is better for security!

hinkley 8y ago
Wouldn't this mean that kernel calls are interprocess communication?
- titzer 8y ago
  In general, yes. But one could, e.g. have a second kernel, or some microkernel subsystems, running on the other system for the most common calls. In fact, that'd be even safer. It'd be safest to have a whole machine per process :)