3 ms·

TLBleed: When Protecting Your CPU Caches is Not Enough

39 points by blopeur 8y ago

sctb 8y ago
Is there anything more substantial about this out there? We can update the link if so.
- blopeur 8y ago
  It seems that this is the main reason behind OpenBSD disabling Hyperthreading support. But at the moment there is not a lot of information out there. I think that if we start to see other distribution (Redhat) disabling hyperthreading too we might have another Meltdown on our hands.
exabrial 8y ago
I'm beginning to think that running any software on the same physical machine where secure code needs to run is a liability. Someone could backdoor a stupid useless utility and grab important keys. What scares me is virtualization; could this attack be practical on EC2 across guests instead of hyperthreading? (I know there's a very large difference in the way these two concepts work) Finally, how exactly is this possible with a EDDSA or Ed25519 based ECC curve? The claim to fame there is that because they don't branch, side channel attacks are much harder.
- deliver8r 8y ago
  Your first sentence is why part of hardening systems is getting down to a bare minimum footprint of installed software. To your second question, cloud vendors are generally very happy to sell you threads instead of cores on multi-tennant hosts. So, almost certainly- if not with this attack, than with a Spectre variant or something as yet undiscovered/undisclosed. If you want to avoid that some let you pay extra for dedicated hardware.
  - BeeOnRope 8y ago
    To be fair, all of the standard host types that AWS offers, for example, are pairs of hyperthreads, so you are getting a dedicated CPU and are presumably not scheduled on the same core as a thread from another tenant. That is, unless Amazon has made some unusual scheduling decisions. I didn't check the other cloud providers.
    - deliver8r 8y ago
      Given that CPU steal remains an ongoing problem (ie, another tenant is eating into your instance's allocated processor share), on what do you base your implication that AWS is binding cores to specific VMs?
notaplumber 8y ago
Previous discussion: https://news.ycombinator.com/item?id=17350278 https://news.ycombinator.com/item?id=17350278 Connection(s): https://www.mail-archive.com/source-changes@openbsd.org/msg99159.html https://www.mail-archive.com/source-changes@openbsd.org/msg9... https://www.mail-archive.com/source-changes@openbsd.org/msg99161.html https://www.mail-archive.com/source-changes@openbsd.org/msg9...
RachelF 8y ago
More details today at The Register https://www.theregister.co.uk/2018/06/22/intel_tlbleed_key_data_leak/ https://www.theregister.co.uk/2018/06/22/intel_tlbleed_key_d...

39 points by blopeur 8y ago

sctb 8y ago

Is there anything more substantial about this out there? We can update the link if so.

blopeur 8y ago
It seems that this is the main reason behind OpenBSD disabling Hyperthreading support. But at the moment there is not a lot of information out there. I think that if we start to see other distribution (Redhat) disabling hyperthreading too we might have another Meltdown on our hands.

exabrial 8y ago

I'm beginning to think that running any software on the same physical machine where secure code needs to run is a liability. Someone could backdoor a stupid useless utility and grab important keys. What scares me is virtualization; could this attack be practical on EC2 across guests instead of hyperthreading? (I know there's a very large difference in the way these two concepts work) Finally, how exactly is this possible with a EDDSA or Ed25519 based ECC curve? The claim to fame there is that because they don't branch, side channel attacks are much harder.

deliver8r 8y ago
Your first sentence is why part of hardening systems is getting down to a bare minimum footprint of installed software. To your second question, cloud vendors are generally very happy to sell you threads instead of cores on multi-tennant hosts. So, almost certainly- if not with this attack, than with a Spectre variant or something as yet undiscovered/undisclosed. If you want to avoid that some let you pay extra for dedicated hardware.
- BeeOnRope 8y ago
  To be fair, all of the standard host types that AWS offers, for example, are pairs of hyperthreads, so you are getting a dedicated CPU and are presumably not scheduled on the same core as a thread from another tenant. That is, unless Amazon has made some unusual scheduling decisions. I didn't check the other cloud providers.
  - deliver8r 8y ago
    Given that CPU steal remains an ongoing problem (ie, another tenant is eating into your instance's allocated processor share), on what do you base your implication that AWS is binding cores to specific VMs?

notaplumber 8y ago

Previous discussion: https://news.ycombinator.com/item?id=17350278 https://news.ycombinator.com/item?id=17350278 Connection(s): https://www.mail-archive.com/source-changes@openbsd.org/msg99159.html https://www.mail-archive.com/source-changes@openbsd.org/msg9... https://www.mail-archive.com/source-changes@openbsd.org/msg99161.html https://www.mail-archive.com/source-changes@openbsd.org/msg9...

RachelF 8y ago

More details today at The Register https://www.theregister.co.uk/2018/06/22/intel_tlbleed_key_data_leak/ https://www.theregister.co.uk/2018/06/22/intel_tlbleed_key_d...