11–20 of 159 posts
Does that mean hyperthreading is effectively unpatchably insecure? Cloud Providers are gonna have a bad time if this is true.
Thinking about this, they're probably gonna introduce "insecure but cheap" instances for customers that don't mind the chance of data leaks and takeovers...
https://mechanical-sympathy.blogspot.com/2011/07/false-shari...
How about an architecture more like Erlang's, where you have independent processes with their own CPU core, where each has their own memory, but where you have much faster communications supported at lower hardware levels? Why not have a multi-processor architecture designed for direct support of Hoare CSP-inspired languages?
Hypercube topology: http://web.eecs.umich.edu/~qstout/pap/IEEEM86.pdf
Does that mean hyperthreading is effectively unpatchably insecure? Cloud Providers are gonna have a bad time if this is true.
Thinking about this, they're probably gonna introduce "insecure but cheap" instances for customers that don't mind the chance of data leaks and takeovers...
Edit: https://www.amd.com/en/corporate/security-updates
> 8/14/18 – Updated: As in the case with Meltdown, we believe our processors are not susceptible to these new speculative execution attack variants: L1 Terminal Fault – SGX (also known as Foreshadow) CVE 2018-3615, L1 Terminal Fault – OS/SMM (also known as Foreshadow-NG) CVE 2018-3620, and L1 Terminal Fault – VMM (also known as Foreshadow-NG) CVE 2018-3646, due to our hardware paging architecture protections. We are advising customers running AMD EPYC™ processors in their data centers, including in virtualized environments, to not implement Foreshadow-related software mitigations for their AMD platforms.
For those on AMD platforms, how do you disable software mitigations for Foreshadow? Is this automatically done by browsers, operating systems and hypervisors?
Does this mean AMD hyperthreading has a performance + security advantage over currently shipping Intel processors? Edit: https://www.amd.com/en/corporate/security-updates > 8/14/18 – Updated: As in the case with Meltdown, we believe our processors are not susceptible to these new speculative execution attack variants: L1 Terminal Fault – SGX (also known as Foreshadow) CVE 2018-3615, L1 Terminal Fault – OS/SMM (also k…
Earlier quoted context omitted.
Is it a feasible solution to enable hyperthreading only for threads or forks of the same process? Then they can use this ability, but other processes cannot do timing attacks on this process in this core... I think
I'm guessing someone at Amazon is looking at this right now.
Earlier quoted context omitted.
Thinking about this, they're probably gonna introduce "insecure but cheap" instances for customers that don't mind the chance of data leaks and takeovers...
That would be hard to market.
Imagine buying a car that says, "Save $5000 for a less safe version without airbags." Yes, I know Airbags are DOT requirement, just trying to make a point.
Edit: I think people are missing my point. I am not saying they don't sell cheaper models that are less safe. My point is that they don't ACTIVELY market them as such. Point me to an advertisement that says "Save $5000 for a less safe car!". This is in the spirit of what the GP was talking about whether cloud providers can market as "Less secure but cheaper HT option".
Earlier quoted context omitted.
Question: If I rent 4 core AWS instance, does it mean 4 physical cores or 4 hyper threaded cores? Is there a standard to this definition of “cores” across GCP, DO, Linode, etc. I don’t have the experience or knowledge about cloud computing but just have a DO instance running a web server. I’m curious.
I asked this a while ago: a cloud core is always just a hyperthread.
Say you have 100 adders, the processor tries to schedule as many instructions as it can on those 100 adders, but eventually it will run into data dependencies. The left over units can go to a hyperthread.
My understanding (let me know if I'm wrong) is that Hyperthread aware OSes (which is like what, everything since WinXP/Linux kernel 2.4?) will schedule lower priority tasks to the logical cores and higher priority tasks to the real cores.
So when it comes to a hosted provider (a.k.a cloud provider, a.k.a somebody else's computer), what you get pretty much depends on the virtualisation layer they use: Vmware, KVM, Xen, Hyper-V, etc.
Do hypervisors typically peg VMs to a real physical core? I was always under the impression they over-provision on most hosts, so you're getting part of a core and the vCPUs the list in the product documents just indicates your priority and how may vCPUs appear to your particular VM.
Does that mean hyperthreading is effectively unpatchably insecure? Cloud Providers are gonna have a bad time if this is true.
Vmware have disclaimers in the mitigation options that preclude turning off HT, meaning, use at your own risk. [1]
I am still waiting on a comment from Linode [2]
Openstack have some knobs you can adjust, but it really depends on your workloads and what risk you are willing to accept. [3]
AWS have their own custom hypervisor and are said to have worked around the issue. [4] Amazon had info on this before others. It appears they have a special relationship with Intel?
I have not found any hardware or OS vendors that are willing to say that you can leave HT enabled. It is a very heated topic because folks will have to increase their VM infrastructure anywhere from 5% to 50% depending on their workload profiles. For public clouds, you can't predict workload profiles.
Edit: Oops I left out the main site for L1TF [5]
[1] - https://kb.vmware.com/s/article/55806
[2] - https://blog.linode.com/2018/08/16/intels-l1tf-cpu-vulnerabi...
[3] - https://access.redhat.com/articles/3569281
[4] - https://aws.amazon.com/security/security-bulletins/AWS-2018-...
Does this mean AMD hyperthreading has a performance + security advantage over currently shipping Intel processors? Edit: https://www.amd.com/en/corporate/security-updates > 8/14/18 – Updated: As in the case with Meltdown, we believe our processors are not susceptible to these new speculative execution attack variants: L1 Terminal Fault – SGX (also known as Foreshadow) CVE 2018-3615, L1 Terminal Fault – OS/SMM (also k…
Yes!