AMD Zen Microarchitecture: Dual Schedulers, Micro-Op Cache and Memory Hierarchy

Re:AMD Zen Microarchitecture: Dual Schedulers, Micro-Op Cach... by tcoppi on Thursday August 18, 2016 @02:09PM (#12314952)

This is interesting. The most compelling use case IMO is protection against cold boot attacks rather than virtualization, at least until SEV has been proven empirically to do what they claim. Virtualization security is hard to get right in general and adding another layer of complexity probably won't help in the short term.

[ Parent | on HN ]

Re:AMD Zen Microarchitecture: Dual Schedulers, Micro-Op Cach... by emn13 on Thursday August 18, 2016 @03:36PM (#12315688)

Even if it turns out to be leaky, it could still be a big deal: I think it's fair to say that the greatest cloud risk isn't actively and persistently hostile providers - mostly because that sounds like an almost hopeless task. A more realistic risk is that via a VM-breakout or other hack hostile code manages to run on the hypervisor or to at least indirectly influence the hypervisor and other VMs. And that kind of code may well be harder to exploit with even slightly leaky encryption. A hacked hypervisor may not be entirely under the control of the hacker; or breaking the encryption may cause side-effects (such as instability) that causes watchers to take note; or it may simply be quite complex and require case-by-case exploits that are generally impractical.

Even a less that perfect protection from the hyper-visor may still have some value.

I'd be more worried about the performance overhead, personally - I can't imagine using this if the impact is significant, and it seems like it almost has to be.

[ Parent | on HN ]

Re:AMD Zen Microarchitecture: Dual Schedulers, Micro-Op Cach... by usefulcat on Thursday August 18, 2016 @04:06PM (#12315950)

> I'd be more worried about the performance overhead, personally - I can't imagine using this if the impact is significant, and it seems like it almost has to be.

Not necessarily. Bandwidth to main memory is already typically several times less than to L1 or L2 caches. If processor caches are not encrypted, then it seems conceivable that you could have some dedicated encryption/decryption silicon and it probably wouldn't even have to be as fast as it would need to be for general purpose use (like the Intel AES instructions).

Even if it does cost bandwidth or latency to main memory, if it's by a small enough amount it could still be a worthwhile tradeoff for some applications.

[ Parent | on HN ]

Re:AMD Zen Microarchitecture: Dual Schedulers, Micro-Op Cach... by sliverstorm on Thursday August 18, 2016 @05:02PM (#12316296)

I think it's fair to say that the greatest cloud risk isn't actively and persistently hostile providers - mostly because that sounds like an almost hopeless task.

Definitely agree. I know we like our security systems impervious to anyone and everyone, be they script kiddie or the entire NSA. However if you hand your machine over to someone else to run, (in either VM guest or box form), I think you need to acknowledge that you are incontrovertibly accepting slight vulnerability to the colo/VM host.

[ Parent | on HN ]