4 ms·

Intel vulnerabilities are providing additional 25% revenue to Cloud Providers.

by qaq 7y ago

bufferoverflow 7y ago
To Intel maybe. It's a loss to the cloud providers and their customers.
- iopq 7y ago
  I pay by the hour, if I need to provision more servers AWS doesn't take a hit, I do
  - sokoloff 7y ago
    On EC2 and Lambda and similar, yes. On S3 and other managed services, AWS takes the hit.
    - rdsubhas 7y ago
      They could very well optimize only for their own service costs, rather than for the customer.
    - srrr 7y ago
      Do they really need to apply all mitigation patches if they only execute their own code on machines running S3 and other managed services? (For EC2/... of course they do because they execute customer code.) I wonder if I can skip the performance penalty for my own (hardware) server too... But I am not smart enough to answer this question myself.
      - msbarnett 7y ago
        Do you run everything on the machines you only execute your own code on as root? Most people don’t. It’s a defence in depth thing — if someone hits an exploit in a service you want it to be running the lowest privileged user it can get away with so that it can’t rapidly pull all the data out of other subsystems, roam out into the local network and dump DBs, etc. With these vulnerabilities unpatched, an attacker running code as the low privilege user account can sniff credentials for other accounts on the machine, or underlying host, private keys that authenticate against this machine and therefore probably others in the network, etc. I’d say it increases risk quite a bit.
    - deleted 7y ago
      [deleted]
    - computerfriend 7y ago
      True, but for S3 the major cost is not CPU-bound.
    - bashinator 7y ago
      I'm not convinced this is the case for lambda. You get billed for lambda CPU time. If the underlying hardware is unable to provide as much CPU time after mitigations are applied, and AWS hasn't raised their rates, then I'm not the one paying for it.
  - deleted 7y ago
    [deleted]
kasey_junk 7y ago
Most cloud providers are trying to move up the value chain & provide higher margin differentiated services (managed db, queues, etc) instead of staying at the race to the bottom vm market. These intel mitigations impact those services just like everyone else.
- tln 7y ago
  Does it? If customers can't run code on those servers, then these CPU level side channel attacks aren't an issue. This assumes the servers for S3 etc are dedicated to the task.
  - TomMarius 7y ago
    If I'm offering it as a platform as a service (instead of VM/container as a service) then this adds significant costs. Interesting take: It's better to offer it as a "one click app" aside a basic cloud (docker/kubernetes) platform if you don't want to suck these costs.
  - msbarnett 7y ago
    > Does it? If customers can't run code on those servers, then these CPU level side channel attacks aren't an issue. This assumes the servers for S3 etc are dedicated to the task. I’m not sure that follows. Unpatched, most of these Intel CVEs are almost like unpatched local privilege escalation vulnerabilities. Once you’ve compromised a low privilege process you can sniff your way to more and more powerful credentials on the machine, host, and in the network. Unless higher abstraction cloud service providers are dumb enough to just run everything as root, in which case this doesn’t change anything, they probably can’t (competently) get away with not patching these. Defence in depth matters.
IfOnlyYouKnew 7y ago
In the immediate short term: maybe. But fundamentally, these vulnerabilities are (hyper)threatening their business model, because not sharing the infrastructure suddenly becomes far more attractive. So to the extend that you're suggesting that cloud providers are happy, or may even have had a hand in this: nahh.
Aissen 7y ago
Not really: https://twitter.com/waxzce/status/1129381076160454657 https://twitter.com/waxzce/status/1129381076160454657 > The performance loss is not visible for our customers, we have to manage the loss in ourselves. It’s a kind of hidden defect.
ithkuil 7y ago
other replies mentioned that the cost of the slowdown is absorbed by the cloud provider; let's just pretend it's fully passed down to the user and only nitpick at the math behind the joke: Imagine a slowdown (performance penalty) of 50%. It would double the time to complete a task, thus doubling the cost (expressed in cost increase that would be a 100% increase!). Generic formula: 1÷(1−x)−1 For x = 25% ---> 1÷(1−0.25)−1 = 33% duration (cost) increase
qes 7y ago
I run a high traffic web service in the cloud. Well over a billion requests served per month from the origin. We run our CPU's around ~60%. We've seen maybe a 2% hit from spectre & meltdown mitigations. It's hard to even tell because it's a small enough amount that it tends to get lost in the noise.

Intel vulnerabilities are providing additional 25% revenue to Cloud Providers.

by qaq 7y ago

Intel vulnerabilities are providing additional 25% revenue to Cloud Providers.

bufferoverflow 7y ago

To Intel maybe. It's a loss to the cloud providers and their customers.

iopq 7y ago
I pay by the hour, if I need to provision more servers AWS doesn't take a hit, I do
- sokoloff 7y ago
  On EC2 and Lambda and similar, yes. On S3 and other managed services, AWS takes the hit.
  - rdsubhas 7y ago
    They could very well optimize only for their own service costs, rather than for the customer.
  - srrr 7y ago
    Do they really need to apply all mitigation patches if they only execute their own code on machines running S3 and other managed services? (For EC2/... of course they do because they execute customer code.) I wonder if I can skip the performance penalty for my own (hardware) server too... But I am not smart enough to answer this question myself.
    - msbarnett 7y ago
      Do you run everything on the machines you only execute your own code on as root? Most people don’t. It’s a defence in depth thing — if someone hits an exploit in a service you want it to be running the lowest privileged user it can get away with so that it can’t rapidly pull all the data out of other subsystems, roam out into the local network and dump DBs, etc. With these vulnerabilities unpatched, an attacker running code as the low privilege user account can sniff credentials for other accounts on the machine, or underlying host, private keys that authenticate against this machine and therefore probably others in the network, etc. I’d say it increases risk quite a bit.
  - deleted 7y ago
    [deleted]
  - computerfriend 7y ago
    True, but for S3 the major cost is not CPU-bound.
  - bashinator 7y ago
    I'm not convinced this is the case for lambda. You get billed for lambda CPU time. If the underlying hardware is unable to provide as much CPU time after mitigations are applied, and AWS hasn't raised their rates, then I'm not the one paying for it.
- deleted 7y ago
  [deleted]

kasey_junk 7y ago

Most cloud providers are trying to move up the value chain & provide higher margin differentiated services (managed db, queues, etc) instead of staying at the race to the bottom vm market. These intel mitigations impact those services just like everyone else.

tln 7y ago
Does it? If customers can't run code on those servers, then these CPU level side channel attacks aren't an issue. This assumes the servers for S3 etc are dedicated to the task.
- TomMarius 7y ago
  If I'm offering it as a platform as a service (instead of VM/container as a service) then this adds significant costs. Interesting take: It's better to offer it as a "one click app" aside a basic cloud (docker/kubernetes) platform if you don't want to suck these costs.
- msbarnett 7y ago
  > Does it? If customers can't run code on those servers, then these CPU level side channel attacks aren't an issue. This assumes the servers for S3 etc are dedicated to the task. I’m not sure that follows. Unpatched, most of these Intel CVEs are almost like unpatched local privilege escalation vulnerabilities. Once you’ve compromised a low privilege process you can sniff your way to more and more powerful credentials on the machine, host, and in the network. Unless higher abstraction cloud service providers are dumb enough to just run everything as root, in which case this doesn’t change anything, they probably can’t (competently) get away with not patching these. Defence in depth matters.

IfOnlyYouKnew 7y ago

In the immediate short term: maybe. But fundamentally, these vulnerabilities are (hyper)threatening their business model, because not sharing the infrastructure suddenly becomes far more attractive. So to the extend that you're suggesting that cloud providers are happy, or may even have had a hand in this: nahh.

Aissen 7y ago

Not really: https://twitter.com/waxzce/status/1129381076160454657 https://twitter.com/waxzce/status/1129381076160454657 > The performance loss is not visible for our customers, we have to manage the loss in ourselves. It’s a kind of hidden defect.

ithkuil 7y ago

other replies mentioned that the cost of the slowdown is absorbed by the cloud provider; let's just pretend it's fully passed down to the user and only nitpick at the math behind the joke: Imagine a slowdown (performance penalty) of 50%. It would double the time to complete a task, thus doubling the cost (expressed in cost increase that would be a 100% increase!). Generic formula: 1÷(1−x)−1 For x = 25% ---> 1÷(1−0.25)−1 = 33% duration (cost) increase

qes 7y ago

I run a high traffic web service in the cloud. Well over a billion requests served per month from the origin. We run our CPU's around ~60%. We've seen maybe a 2% hit from spectre & meltdown mitigations. It's hard to even tell because it's a small enough amount that it tends to get lost in the noise.