11 ms·

Eventually, it will be obvious that running shared workloads on a single piece of physical hardware has fundamentally unremediatable security implications. This

by 015a 5y ago

Eventually, it will be obvious that running shared workloads on a single piece of physical hardware has fundamentally unremediatable security implications. This slow recognition is deeply perpendicular with how the current landscape of x86 chips are both manufactured and priced, as well as how cloud providers have structured billions of dollars in DC investment; in other words, they'll down-play it. This will be a massive opportunity for ARM & SoC manufacturers in the coming years, as its far better positioned to offer, for example, a single rack appliance with 64 individual 2-core mini-computers at a price-point competitive with a 128 core x86 rack, as one computer. Computing moves in cycles: - 2000s: gigahertz race on each core - 2010s: increase core counts, multicore everything - 2020s: back to core-efficiency and increasing per-core performance. M1 is already leading this charge, but is obviously a mismatch for a DC environment. AMD and Intel need to adjust, or face extinction. Its not just about pushing ultra-high per-core performance (they're both good at this); its about pushing for more efficiency, so per-blade density in a DC can be pushed higher in the face of more, smaller individual computers. If they don't evolve, AWS will for them [1]. [1] https://aws.amazon.com/ec2/graviton/ https://aws.amazon.com/ec2/graviton/

baq 5y ago
AMD and Intel deliver CPUs tailor made for large cloud customers already; those SKUs are not available via normal channels.
- belter 5y ago
  Can you elaborate or provide a reference on how those CPUs are different?
  - Syonyk 5y ago
    Anyone who would know the fine grained differences is almost certainly NDA'd up quite tightly. But it's likely things like different core counts, frequency performance curves, perhaps more or different memory/IO controller counts, perhaps instruction extensions of some particular interest (I'd wager BF16 was available in data center SKUs long before consumer SKUs), etc. It's nothing radical, but if you're going to buy an awful lot of them and want something slightly custom, Intel will definitely do that for you.
    - javajosh 5y ago
      What kind of levers do big ISPs/cloud providers want over their CPUs, other than the basic efficiency gains we all want? Isn't it risky doing any customization since you don't get commodity pricing?
      - to11mtm 5y ago
        > Isn't it risky doing any customization since you don't get commodity pricing? Depends on how many you order and how reasonable the customization is. Like, what if I wanted a 10,000 38 core Xeons with a 2.5GHz Base clock and 3.5GHz Turbo clock? Such a part doesn't exist, yet sits smack dab between two existing Models, the Xeon Platnium 8368 and 8368Q. Assuming yields are already good enough, that might be the sort of thing a CPU maker will do. (Might need more than 10k units though, IDK.)
        baq 5y ago
        I'd wager Pat doesn't get out of bed for 10k units and neither does Lisa.
      - swiftcoder 5y ago
        At AWS scale you can feasibly just buy up the entire run of chips. What's a few million CPUs more or less between friends?
        mywittyname 5y ago
        Additionally, Amazon is absolutely the type of company to create their own x86 processor if Intel/AMD are unwilling to make some customization. Intel does not want to be competing with an Amazon Basics processor.
        Grazester 5y ago
        You basically need a license for X86 from Intel for this. Do you think x86 is open source!
  - baq 5y ago
    not really, just heard about those. but it wouldn't really be that much different than a customized SKU for a playstation or an xbox.
    - belltaco 5y ago
      But what model number would they show up as in the OS facing the users? From what I see most CPU names are the ones available in the market.
  - ThrowawayR2 5y ago
    A recent HN posting points to a news article about AMDs customized processors for Facebook although it provides little detail: https://news.ycombinator.com/item?id=29204257 https://news.ycombinator.com/item?id=29204257 "The custom Epyc 7003 part that Facebook has commissioned from AMD has 36 cores out of its potential 64 cores activated, and with a bunch of optimizations for Facebook applications at the web, database, and inference tiers of its application stack."
- dathinab 5y ago
  Their next gen "normal" server CPUs also have "cloud optimized CPUs". While this seems to be mainly about Power/Heat/Perf. optimizing for typical "cloud" workloads it might also have design decisions related to this problem. We will see, but they look interesting anyway.
throwaway894345 5y ago
> Eventually, it will be obvious that running shared workloads on a single piece of physical hardware has fundamentally unremediatable security implications. If I understand correctly, Homomorphic Encryption aims to solve for these kinds of attacks (although presumably the computations are more expensive and programs must be restructured to use HE primitives?). https://en.wikipedia.org/wiki/Homomorphic_encryption https://en.wikipedia.org/wiki/Homomorphic_encryption EDIT: Why the downvotes? Am I mistaken?
- pbronez 5y ago
  Yeah HE is a totally different security model. It moves all the trust out of the hardware. You ship encrypted workloads to an untrusted party, who computes on the encrypted data and returns an encrypted result. Then you decrypt the result to use it. And yeah, this is just as inefficient as you'd think.
  - rocqua 5y ago
    I'd say its much more inefficient as you'd think. Firstly the computations on encrypted data just take a LOT longer, especially for Fully Homomorphic encryption. With a single 64 bit addition taking microseconds. Secondly, the FHE code cannot branch based on data. If it could, it would know something about the data, and it wouldn't be proper encryption. This means an if statement becomes "calculate both branches, and throw away the result you don't need". Similarly, a for loop becomes "give me an upper bound of how long this will run", then "loop for exactly the upper bound number of times, if the loop is 'done' early, just throw away the result of the remaining operations". FHE is really cool, and has its uses in situations where you want to cooperate without needing to trust, but it is stupidly inefficient. (Things get really cool if two parties want to cooperate and the computing party can e.g. branch based on their local unencrypted data)
- teddyh 5y ago
  HE is stupidly inefficient, and is entirely an academic oddity, and there is every indication that it will always remain that way. Bringing up HE in a context of real problems needing real solutions is unproductive.
landonxjames 5y ago
"We have never shared two threads on a core between EC2 instances" - https://www.youtube.com/watch?v=kQ4H6XO-iao&t=2485s https://www.youtube.com/watch?v=kQ4H6XO-iao&t=2485s Interesting that AWS has been mitigating for side channel attacks since before they became a big news item. Curious about Azure and GCP's stance on this
- mlyle 5y ago
  Maybe they were super smart and foresaw side-channel being such a big problem. Or, maybe, they just thought the lack of deterministic performance created billing/accounting/customer service problems. (One hyperthread can just about completely starve in many circumstances).
  - thrashh 5y ago
    Well, you pick EC2 because you want dedicated cores. You pick a VPS because you want to save costs and share cores. So it’s not so much AWS choosing as you the customer choosing.
    - secondcoming 5y ago
      I was under the impression that AWS provides vCPUs, not dedicated CPUs unless you go bare-metal?
      - vngzs 5y ago
        You get dedicated time on a core while your task is running. For instance t3.medium is 2 vCPUs (because hyperthreading) but as you can see in [0] it's only one physical core. [0]: https://aws.amazon.com/ec2/physicalcores/ https://aws.amazon.com/ec2/physicalcores/
      - bostik 5y ago
        You can get dedicated tenancy instances in AWS, for an upfront monthly cost of ~$1.2k (per account) and about +10% on top of your normal EC2 instance costs. I ran the numbers back in 2015 and persuaded the previous employer to go for dedicated tenancy with all performance-critical and privacy-sensitive workloads. I was effectively hedging against unknown but practically guaranteed cross-VM attacks to pacify a paranoid regulator. Then Rowhammer happened. Less than a day later, our contact with the regulator comes to me asking how it affects us. Being able to answer - with absolute confidence - that it did not, was one of the proudest moments of my career. And the turnaround from "regulator comes asking awkward questions" to "regulator is happy and sees no reason to ask again" of less than 48 hours must be some kind of record too.
com2kid 5y ago
> Eventually, it will be obvious that running shared workloads on a single piece of physical hardware has fundamentally unremediatable security implications. Sure, but this is worse than that. This is "your online poker game client can gets access to your web browser's bank account session info." We need process isolation within a single machine, or else we are kinda screwed as a field.
- jeremyjh 5y ago
  Right, we may be entering an era in which secure network computing is impractical and the impact could be very far reaching.
  - johnvaluk 5y ago
    I've been experimenting with isolating work activity from personal activity. It's amazing how difficult it is to prevent information from leaking between networks and applications. It's hard to find alternative solutions for entrenched convergence/convenience features like copy/paste, messaging and entertainment. Working remotely reveals too much about your personal and work relationships to corporations and VPNs only help to connect more dots. I can't curl up in a hammock with 3 laptops and a phone on a nice day, so I keep returning to a single device that does it all.
  - orlytho 5y ago
    Sorry, entering? Just like climate change some of us have been warning that a lack of focus on and willingness to challenge the fundamentals of building software and systems would lead to non-securable computing in the general case. That warning has been sounding since the 1990s. Nobody cares. It took a meat plant and pipeline paying a ransom in cryptocurrency for everyone to notice that we are completely and irredeemably fucked as a computing species. We are already there, my guy, and it’s only a matter of time now. Think about someone trying to do basic ETL. Like having a tabular file and summing it or something. Don’t use Excel, we say, stand up a $4 million Spark and AWS architecture with seven hundred pitfalls that can let bored Russians take over your whole network as if they were going to the dry cleaners because remember, you just might be Google someday. That’s where we are. It’s been a complete industry failure for a decade and it’s only getting worse. Accelerating, even: now you need some operationally-terrifying Kubernetes to even be at the table, and then as an industry we (rightly) say running this stuff ourselves is too hard, so pay Amazon to do it rather than even ponder if we have settled on the right approach. Tada: Humanity just lost computing to three companies. We very likely aren’t getting it back. There are probably 5,000 people doing this work who can adequately secure such a system and make it mostly impermeable. Where middle computing is royally screwed is that nearly all of them work in San Francisco or its clones abroad. So then you get “best practice” blog posts and industry think pieces and the lowest bidder ties them together into something resembling a competent computing system. That’s been the state of the art since 2004 everywhere except Santa Clara county. With the exception of some areas in the IC and DoD, I just described the entirety of US government IT. That ETL example? It’s actually real and underpins a small part of Medicare across several government contracts. Because the tools the valley exports are all they’ve got, and we sure love building systems with massive footguns, and then shaming organizations publicly for missing item #543 on the tribal “secure your computing system” checklist and shooting themselves. The entire industry must change, top to bottom, but just like climate change, again, that’s a nonstarter. Posix and the Web are not the path forward and I hope I live to see the industry figure that out. I’m increasingly skeptical. The good news is my hometown might flood into the sea first, sparing me from considering in my last moments that every argument I’ve ever made in this profession has fallen on deaf ears and that everyone has to derive our industry’s peril from first principles for themselves.
KingMachiavelli 5y ago
I don't see how Graviton/custom ARM chips are evidence of this predicted trend. ARM chips tend to have even higher thread counts and poorer per-core performance. The biggest security difference is the absence of SMT/hyper-threading. I think it will come down to what you are willing to call 'individual' processors. But actually having physically distinct memory seems like a lot of overhead for attacks that won't matter for 90% of users. Also I would think that the on-board ECC of DDR5 would protect it against these types of attacks.
- 015a 5y ago
  Graviton is not a prediction of the trend; its a signal that Amazon is willing to make very deep investment into custom, customer-facing hardware if Intel/AMD can't deliver what they need. The trend is yet to come. My statement is that, if AMD/Intel doesn't adapt, Amazon has the hardware investment to leave them behind, just like Apple did. But to be clear on two points: They will probably adapt. And Amazon/etc will probably never leave them behind fully. DCs, especially public cloud, are not all-or-nothing like Apple's Mac Lineup is. Then the question follows, why would they want something Intel/AMD isn't offering right now? The trend is System-on-Chip. Beyond Security (this isn't the last electrical interference/speculative execution-like attack we'll see). SoCs are easier to service (easier != cheaper. holistic replacement versus per-component debugging. servers are cattle, not pets). Denser. More vertically integrated. Capable of far higher IO performance. Lots of benefits. Mega-servers with 256 cores and 4 terabytes of memory still have a huge place in all DCs; but not when multiple untrusted workloads are running simultaneously. They're not for EC2/Fargate/Lambda/etc; they're for S3. Highly managed, trusted workloads.
api 5y ago
I am not at all convinced that this is not a solvable problem. It may require significant changes in how schedulers work, such as resurrecting the idea of processor affinity. Unfortunately it will likely have negative performance implications for multi-tenant work loads.
passivate 5y ago
But you still need data exchange between parallel/concurrent workloads. The security focus will shift to the data nodes which exchange data between the CPUs. And then the focus will probably shift towards latency and performance and moving these data modules closer to each other.. kinda like RAM :P
temac 5y ago
The M1 family certainly doesn't go into the direction of less cores, and even if you had a single one you could probably rowhammer during your timeslice and then patiently wait for the target process to execute. Since even individual computers execute random garbage code straight from the Internet (e.g. JS), there is still a needed for internal security. That being said, and even if I consider that a quite different subject, I agree that the current efficiency story of Intel is not very good, but I hope they will improve in a not so far future. The dev lifecycle of CPUs is quite long and it seems to be an obvious target. I suspect they will be forced to improve their efficiency, because that's actually were the performance potential is today (the current dissipation level of their last desktop CPUs is not reasonable, and prevents scalability). And trying to lower the core count also can yield to high consumption, e.g. if you want your performance back by increasing the frequency. Wide and "slow" is needed, and it is harder to increase the internal number of execution units per core and have them actually used, than to increase the core count -- plus ironically one way to do that is through HT, which goes against your wish to share less hardware. (Now if you compare their P-core and E-core in Alder Lake the story is more complicated, but their marketing figures seem very strange, so I won't conclude anything for now. The current instances of P-core we have is for that weird desktop market with unreasonable high TDP anyway.) Now if you really want miniaturized individual computers that would not be shared at all, I'm not sure the market will actually go into that direction because big systems will continue to be needed (and clusters are a niche mostly for HPC), and I'm not sure a "slightly more secure on smaller systems" market would be interesting enough. Esp. in an era of chip shortage. And also because it would still be bigger than a shared equivalent system make with the same techs... But if that's really a niche that has to be addressed, I suspect it would mostly be a matter for Intel to create new small and slower SKUs ("slower" compared to their desktops insanities) -- they even kind of have that already, but yes the physical miniaturization aspect is not handled yet -- that does not really depends that much on the cores, though. And even in those computers, I'm not sure there would be much demand for very low core counts. The threading of pretty much all workloads tends to increase, nowadays. One last point, after the e.g. Pentium 4 fiasco nobody really left the IPC race. AMD had some difficulties when trying "weird" ideas (part of which were because of their marketing communication), and then again a completely new design from scratch to market takes time. In general there was a pause of performance growth around 2016 for a few years, and that was mostly Intel having process problems and the rest of the industry catching up (and then overtaking them).
oopsyDoodl 5y ago
Intel gets it and is adjusting to be a foundry that builds chips to application spec. For me cloud computing is just where the best pay is. I do not at all see it as the future of computing. One reason is ML will help us realize we write code we don’t need; so much of it is syntax sugar for business specific needs; infra, security… it’ll be realized cloud software is solving unemployment not technical problems of value. That many issues with software back in the day were lower quality networks, and consumer hardware. I mean any phone can abstract metadata from any one users amount of behavior, we do it in a DC because that’s where the jobs are. Chip manufacturing will include ML normalized logic for specific application. LAN IOT will improve and we’ll realize the Metaverse can be implemented with a local client and AI generated art, on a mobile GPUs power in a few years. Middle men like Zuckerberg face the most uncertain future. He failed to diversify as well as Bezos, Newell, and others. IMO, Valve is a serious threat with Steamdeck; an open IOT brain in a kid friendly form factor could be the new cigarette. Even Apple may have to take them seriously. My kids iPads need replacing soon; a flat glass slab with no interactive controls, requiring another $800+ machine to develop on, bloated development tools, fees, and a bunch of cloud logins, are not going to motivate kids to feel creative.
froh 5y ago
IBM Z series silicon (z architecture and it's predecessors s390,...) Is designed with multi tenancy in mind from the get go. Finding a way to escape virtualization let alone partitioning to access confidential competitor data was a no go. And indeed to my understanding spectre, meltdown, rowhammer and similar attacks are not an issue there. https://en.wikipedia.org/wiki/Z/Architecture https://en.wikipedia.org/wiki/Z/Architecture I wonder when more features from the mainframe cross pollinate Intel amd arm CPU architectures.
- monocasa 5y ago
  Z Series is very much susceptible to meltdown, spectre, and rowhammer. IBM says that it should be fine because Spectre et al need to be running untrusted workloads to work, but they haven't updated their advisories since NetSpectre. : / A lot of the talk of mainframe levels of security is specious at best.
  - froh 5y ago
    Wow. Your right, for spectre patches were needed on system z. https://www.suse.com/de-de/support/kb/doc/?id=000019105 https://www.suse.com/de-de/support/kb/doc/?id=000019105 Meltdown didn't affect z nor amd.
    - monocasa 5y ago
      Series Z and POWER up to and including POWER9 are susceptible to meltdown as well. https://www.zdnet.com/article/meltdown-spectre-ibm-preps-firmware-and-os-fixes-for-vulnerable-power-cpus/ https://www.zdnet.com/article/meltdown-spectre-ibm-preps-fir...
      - froh 5y ago
        Ok. debian is even more explicit than suse above regarding "no meltdown on Z": https://wiki.debian.org/DebianSecurity/SpectreMeltdown#System_z_.28s390x.29 https://wiki.debian.org/DebianSecurity/SpectreMeltdown#Syste...
      - 5y ago
short12 5y ago
AMD seems to be doing just fine. With a roadmap for the future. They will be just fine
deleted 5y ago
[deleted]
Arrath 5y ago
> This will be a massive opportunity for ARM & SoC manufacturers in the coming years, as its far better positioned to offer, for example, a single rack appliance with 64 individual 2-core mini-computers at a price-point competitive with a 128 core x86 rack, as one computer. I'm curious about the eventual end-game of security in this space. Take the 64 individual processors in your example, give each one their own independent memory bus to their own ram chip, isolate them from each other as much as possible. What else can be done, if a malicious process on processor Z has to go all the way to disk to try to get back at data working on processor J, is that as maximally secure as it can be without being in a completely separate chassis with only network access to the other device?
- 015a 5y ago
  I think what you describe is a likely end-state, and what large cloud providers will move to. The problem right now is that a setup like this isn't cheap; but its only expensive because economics of scale aren't behind it; that will change if demand for more isolated VMs increases. Essentially, a board with an array of "mini computers", 1-4 cores bussed to their own physically and logically isolated memory pool. Storage is oftentimes already networked in public cloud, and seemingly less susceptible to these kinds of attacks, so probably little change is necessary there. Its also likely we'll see vendors produce more "card computers", like the raspberry pi, but oriented at a server environment. At massive scale like what AWS runs at, these are less compelling, but they do have advantages; the biggest being, maintenance is a cinch, and the blast radius on one failing is isolated to just the workload on that card. I imagine these will be more interesting for current VPS providers like DigitalOcean, who also want to offer dedicated hosts with smaller core/memory counts. Even RPis today are super compelling; a $50 multicore computer that's easy to manufacture and replace, with density high enough to fit 100+ inside a 4U? Just need a bit more core perf and ARM adoption (though its easy to see Intel also hoping on this train with their long-term investment in pro/consumer NUCs). Writing is on the wall. The tipping point will be an industry thought leader saying, in effect, "you should be using dedicated hosts, because at this point physics is our enemy and we're not winning, by the way here's a new dedicated host instance type that's perfectly suited for horizontally scaled workloads, its 20% more expensive than virtual hosts of the same size, byeeee".
FpUser 5y ago
>"as its far better positioned to offer, for example, a single rack appliance with 64 individual 2-core mini-computers at a price-point competitive with a 128 core x86 rack," I have server application capable of utilizing many threads and thousands requests/s. You think I will deploy it on tiny 2 core CPU? No thank you, it currently runs on powerful dedicated server from Hetzner where I control everything. >"AMD and Intel need to adjust, or face extinction .... If they don't evolve, AWS will for them..." Sounds like pontification / FUD.
- tadbit 5y ago
  > Sounds like pontification / FUD. Sounds like you didn't fully grasp what the grandparent was writing about. >> Eventually, it will be obvious that running shared workloads on a single piece of physical hardware has fundamentally unremediatable security implications > I have server application capable of utilizing many threads and thousands requests/s. You think I will deploy it on tiny 2 core CPU? No thank you, it currently runs on powerful dedicated server from Hetzner where I control everything. Your use case isn't covered here, you're neither a cloud nor VPS customer. There will always be individuals and companies looking for dedicated hosting solutions, or just hosting it themselves. However, for the rest of the world that wants to run their stuff in the cloud that's where Amazon's and other companies investments in ARM come into play. That's where we'll see disruption, the extinction the grandparent was talking about.

by 015a 5y ago

baq 5y ago

AMD and Intel deliver CPUs tailor made for large cloud customers already; those SKUs are not available via normal channels.

belter 5y ago
Can you elaborate or provide a reference on how those CPUs are different?
- Syonyk 5y ago
  Anyone who would know the fine grained differences is almost certainly NDA'd up quite tightly. But it's likely things like different core counts, frequency performance curves, perhaps more or different memory/IO controller counts, perhaps instruction extensions of some particular interest (I'd wager BF16 was available in data center SKUs long before consumer SKUs), etc. It's nothing radical, but if you're going to buy an awful lot of them and want something slightly custom, Intel will definitely do that for you.
  - javajosh 5y ago
    What kind of levers do big ISPs/cloud providers want over their CPUs, other than the basic efficiency gains we all want? Isn't it risky doing any customization since you don't get commodity pricing?
    - to11mtm 5y ago
      > Isn't it risky doing any customization since you don't get commodity pricing? Depends on how many you order and how reasonable the customization is. Like, what if I wanted a 10,000 38 core Xeons with a 2.5GHz Base clock and 3.5GHz Turbo clock? Such a part doesn't exist, yet sits smack dab between two existing Models, the Xeon Platnium 8368 and 8368Q. Assuming yields are already good enough, that might be the sort of thing a CPU maker will do. (Might need more than 10k units though, IDK.)
      - baq 5y ago
        I'd wager Pat doesn't get out of bed for 10k units and neither does Lisa.
    - swiftcoder 5y ago
      At AWS scale you can feasibly just buy up the entire run of chips. What's a few million CPUs more or less between friends?
      - mywittyname 5y ago
        Additionally, Amazon is absolutely the type of company to create their own x86 processor if Intel/AMD are unwilling to make some customization. Intel does not want to be competing with an Amazon Basics processor.
        Grazester 5y ago
        You basically need a license for X86 from Intel for this. Do you think x86 is open source!
- baq 5y ago
  not really, just heard about those. but it wouldn't really be that much different than a customized SKU for a playstation or an xbox.
  - belltaco 5y ago
    But what model number would they show up as in the OS facing the users? From what I see most CPU names are the ones available in the market.
- ThrowawayR2 5y ago
  A recent HN posting points to a news article about AMDs customized processors for Facebook although it provides little detail: https://news.ycombinator.com/item?id=29204257 https://news.ycombinator.com/item?id=29204257 "The custom Epyc 7003 part that Facebook has commissioned from AMD has 36 cores out of its potential 64 cores activated, and with a bunch of optimizations for Facebook applications at the web, database, and inference tiers of its application stack."
dathinab 5y ago
Their next gen "normal" server CPUs also have "cloud optimized CPUs". While this seems to be mainly about Power/Heat/Perf. optimizing for typical "cloud" workloads it might also have design decisions related to this problem. We will see, but they look interesting anyway.

throwaway894345 5y ago

> Eventually, it will be obvious that running shared workloads on a single piece of physical hardware has fundamentally unremediatable security implications. If I understand correctly, Homomorphic Encryption aims to solve for these kinds of attacks (although presumably the computations are more expensive and programs must be restructured to use HE primitives?). https://en.wikipedia.org/wiki/Homomorphic_encryption https://en.wikipedia.org/wiki/Homomorphic_encryption EDIT: Why the downvotes? Am I mistaken?

pbronez 5y ago
Yeah HE is a totally different security model. It moves all the trust out of the hardware. You ship encrypted workloads to an untrusted party, who computes on the encrypted data and returns an encrypted result. Then you decrypt the result to use it. And yeah, this is just as inefficient as you'd think.
- rocqua 5y ago
  I'd say its much more inefficient as you'd think. Firstly the computations on encrypted data just take a LOT longer, especially for Fully Homomorphic encryption. With a single 64 bit addition taking microseconds. Secondly, the FHE code cannot branch based on data. If it could, it would know something about the data, and it wouldn't be proper encryption. This means an if statement becomes "calculate both branches, and throw away the result you don't need". Similarly, a for loop becomes "give me an upper bound of how long this will run", then "loop for exactly the upper bound number of times, if the loop is 'done' early, just throw away the result of the remaining operations". FHE is really cool, and has its uses in situations where you want to cooperate without needing to trust, but it is stupidly inefficient. (Things get really cool if two parties want to cooperate and the computing party can e.g. branch based on their local unencrypted data)
teddyh 5y ago
HE is stupidly inefficient, and is entirely an academic oddity, and there is every indication that it will always remain that way. Bringing up HE in a context of real problems needing real solutions is unproductive.

landonxjames 5y ago

"We have never shared two threads on a core between EC2 instances" - https://www.youtube.com/watch?v=kQ4H6XO-iao&t=2485s https://www.youtube.com/watch?v=kQ4H6XO-iao&t=2485s Interesting that AWS has been mitigating for side channel attacks since before they became a big news item. Curious about Azure and GCP's stance on this

mlyle 5y ago
Maybe they were super smart and foresaw side-channel being such a big problem. Or, maybe, they just thought the lack of deterministic performance created billing/accounting/customer service problems. (One hyperthread can just about completely starve in many circumstances).
- thrashh 5y ago
  Well, you pick EC2 because you want dedicated cores. You pick a VPS because you want to save costs and share cores. So it’s not so much AWS choosing as you the customer choosing.
  - secondcoming 5y ago
    I was under the impression that AWS provides vCPUs, not dedicated CPUs unless you go bare-metal?
    - vngzs 5y ago
      You get dedicated time on a core while your task is running. For instance t3.medium is 2 vCPUs (because hyperthreading) but as you can see in [0] it's only one physical core. [0]: https://aws.amazon.com/ec2/physicalcores/ https://aws.amazon.com/ec2/physicalcores/
    - bostik 5y ago
      You can get dedicated tenancy instances in AWS, for an upfront monthly cost of ~$1.2k (per account) and about +10% on top of your normal EC2 instance costs. I ran the numbers back in 2015 and persuaded the previous employer to go for dedicated tenancy with all performance-critical and privacy-sensitive workloads. I was effectively hedging against unknown but practically guaranteed cross-VM attacks to pacify a paranoid regulator. Then Rowhammer happened. Less than a day later, our contact with the regulator comes to me asking how it affects us. Being able to answer - with absolute confidence - that it did not, was one of the proudest moments of my career. And the turnaround from "regulator comes asking awkward questions" to "regulator is happy and sees no reason to ask again" of less than 48 hours must be some kind of record too.

com2kid 5y ago

> Eventually, it will be obvious that running shared workloads on a single piece of physical hardware has fundamentally unremediatable security implications. Sure, but this is worse than that. This is "your online poker game client can gets access to your web browser's bank account session info." We need process isolation within a single machine, or else we are kinda screwed as a field.

jeremyjh 5y ago
Right, we may be entering an era in which secure network computing is impractical and the impact could be very far reaching.
- johnvaluk 5y ago
  I've been experimenting with isolating work activity from personal activity. It's amazing how difficult it is to prevent information from leaking between networks and applications. It's hard to find alternative solutions for entrenched convergence/convenience features like copy/paste, messaging and entertainment. Working remotely reveals too much about your personal and work relationships to corporations and VPNs only help to connect more dots. I can't curl up in a hammock with 3 laptops and a phone on a nice day, so I keep returning to a single device that does it all.
- orlytho 5y ago
  Sorry, entering? Just like climate change some of us have been warning that a lack of focus on and willingness to challenge the fundamentals of building software and systems would lead to non-securable computing in the general case. That warning has been sounding since the 1990s. Nobody cares. It took a meat plant and pipeline paying a ransom in cryptocurrency for everyone to notice that we are completely and irredeemably fucked as a computing species. We are already there, my guy, and it’s only a matter of time now. Think about someone trying to do basic ETL. Like having a tabular file and summing it or something. Don’t use Excel, we say, stand up a $4 million Spark and AWS architecture with seven hundred pitfalls that can let bored Russians take over your whole network as if they were going to the dry cleaners because remember, you just might be Google someday. That’s where we are. It’s been a complete industry failure for a decade and it’s only getting worse. Accelerating, even: now you need some operationally-terrifying Kubernetes to even be at the table, and then as an industry we (rightly) say running this stuff ourselves is too hard, so pay Amazon to do it rather than even ponder if we have settled on the right approach. Tada: Humanity just lost computing to three companies. We very likely aren’t getting it back. There are probably 5,000 people doing this work who can adequately secure such a system and make it mostly impermeable. Where middle computing is royally screwed is that nearly all of them work in San Francisco or its clones abroad. So then you get “best practice” blog posts and industry think pieces and the lowest bidder ties them together into something resembling a competent computing system. That’s been the state of the art since 2004 everywhere except Santa Clara county. With the exception of some areas in the IC and DoD, I just described the entirety of US government IT. That ETL example? It’s actually real and underpins a small part of Medicare across several government contracts. Because the tools the valley exports are all they’ve got, and we sure love building systems with massive footguns, and then shaming organizations publicly for missing item #543 on the tribal “secure your computing system” checklist and shooting themselves. The entire industry must change, top to bottom, but just like climate change, again, that’s a nonstarter. Posix and the Web are not the path forward and I hope I live to see the industry figure that out. I’m increasingly skeptical. The good news is my hometown might flood into the sea first, sparing me from considering in my last moments that every argument I’ve ever made in this profession has fallen on deaf ears and that everyone has to derive our industry’s peril from first principles for themselves.

KingMachiavelli 5y ago

I don't see how Graviton/custom ARM chips are evidence of this predicted trend. ARM chips tend to have even higher thread counts and poorer per-core performance. The biggest security difference is the absence of SMT/hyper-threading. I think it will come down to what you are willing to call 'individual' processors. But actually having physically distinct memory seems like a lot of overhead for attacks that won't matter for 90% of users. Also I would think that the on-board ECC of DDR5 would protect it against these types of attacks.

015a 5y ago
Graviton is not a prediction of the trend; its a signal that Amazon is willing to make very deep investment into custom, customer-facing hardware if Intel/AMD can't deliver what they need. The trend is yet to come. My statement is that, if AMD/Intel doesn't adapt, Amazon has the hardware investment to leave them behind, just like Apple did. But to be clear on two points: They will probably adapt. And Amazon/etc will probably never leave them behind fully. DCs, especially public cloud, are not all-or-nothing like Apple's Mac Lineup is. Then the question follows, why would they want something Intel/AMD isn't offering right now? The trend is System-on-Chip. Beyond Security (this isn't the last electrical interference/speculative execution-like attack we'll see). SoCs are easier to service (easier != cheaper. holistic replacement versus per-component debugging. servers are cattle, not pets). Denser. More vertically integrated. Capable of far higher IO performance. Lots of benefits. Mega-servers with 256 cores and 4 terabytes of memory still have a huge place in all DCs; but not when multiple untrusted workloads are running simultaneously. They're not for EC2/Fargate/Lambda/etc; they're for S3. Highly managed, trusted workloads.

api 5y ago

I am not at all convinced that this is not a solvable problem. It may require significant changes in how schedulers work, such as resurrecting the idea of processor affinity. Unfortunately it will likely have negative performance implications for multi-tenant work loads.

passivate 5y ago

But you still need data exchange between parallel/concurrent workloads. The security focus will shift to the data nodes which exchange data between the CPUs. And then the focus will probably shift towards latency and performance and moving these data modules closer to each other.. kinda like RAM :P

temac 5y ago

The M1 family certainly doesn't go into the direction of less cores, and even if you had a single one you could probably rowhammer during your timeslice and then patiently wait for the target process to execute. Since even individual computers execute random garbage code straight from the Internet (e.g. JS), there is still a needed for internal security. That being said, and even if I consider that a quite different subject, I agree that the current efficiency story of Intel is not very good, but I hope they will improve in a not so far future. The dev lifecycle of CPUs is quite long and it seems to be an obvious target. I suspect they will be forced to improve their efficiency, because that's actually were the performance potential is today (the current dissipation level of their last desktop CPUs is not reasonable, and prevents scalability). And trying to lower the core count also can yield to high consumption, e.g. if you want your performance back by increasing the frequency. Wide and "slow" is needed, and it is harder to increase the internal number of execution units per core and have them actually used, than to increase the core count -- plus ironically one way to do that is through HT, which goes against your wish to share less hardware. (Now if you compare their P-core and E-core in Alder Lake the story is more complicated, but their marketing figures seem very strange, so I won't conclude anything for now. The current instances of P-core we have is for that weird desktop market with unreasonable high TDP anyway.) Now if you really want miniaturized individual computers that would not be shared at all, I'm not sure the market will actually go into that direction because big systems will continue to be needed (and clusters are a niche mostly for HPC), and I'm not sure a "slightly more secure on smaller systems" market would be interesting enough. Esp. in an era of chip shortage. And also because it would still be bigger than a shared equivalent system make with the same techs... But if that's really a niche that has to be addressed, I suspect it would mostly be a matter for Intel to create new small and slower SKUs ("slower" compared to their desktops insanities) -- they even kind of have that already, but yes the physical miniaturization aspect is not handled yet -- that does not really depends that much on the cores, though. And even in those computers, I'm not sure there would be much demand for very low core counts. The threading of pretty much all workloads tends to increase, nowadays. One last point, after the e.g. Pentium 4 fiasco nobody really left the IPC race. AMD had some difficulties when trying "weird" ideas (part of which were because of their marketing communication), and then again a completely new design from scratch to market takes time. In general there was a pause of performance growth around 2016 for a few years, and that was mostly Intel having process problems and the rest of the industry catching up (and then overtaking them).

oopsyDoodl 5y ago

Intel gets it and is adjusting to be a foundry that builds chips to application spec. For me cloud computing is just where the best pay is. I do not at all see it as the future of computing. One reason is ML will help us realize we write code we don’t need; so much of it is syntax sugar for business specific needs; infra, security… it’ll be realized cloud software is solving unemployment not technical problems of value. That many issues with software back in the day were lower quality networks, and consumer hardware. I mean any phone can abstract metadata from any one users amount of behavior, we do it in a DC because that’s where the jobs are. Chip manufacturing will include ML normalized logic for specific application. LAN IOT will improve and we’ll realize the Metaverse can be implemented with a local client and AI generated art, on a mobile GPUs power in a few years. Middle men like Zuckerberg face the most uncertain future. He failed to diversify as well as Bezos, Newell, and others. IMO, Valve is a serious threat with Steamdeck; an open IOT brain in a kid friendly form factor could be the new cigarette. Even Apple may have to take them seriously. My kids iPads need replacing soon; a flat glass slab with no interactive controls, requiring another $800+ machine to develop on, bloated development tools, fees, and a bunch of cloud logins, are not going to motivate kids to feel creative.

froh 5y ago

IBM Z series silicon (z architecture and it's predecessors s390,...) Is designed with multi tenancy in mind from the get go. Finding a way to escape virtualization let alone partitioning to access confidential competitor data was a no go. And indeed to my understanding spectre, meltdown, rowhammer and similar attacks are not an issue there. https://en.wikipedia.org/wiki/Z/Architecture https://en.wikipedia.org/wiki/Z/Architecture I wonder when more features from the mainframe cross pollinate Intel amd arm CPU architectures.

monocasa 5y ago
Z Series is very much susceptible to meltdown, spectre, and rowhammer. IBM says that it should be fine because Spectre et al need to be running untrusted workloads to work, but they haven't updated their advisories since NetSpectre. : / A lot of the talk of mainframe levels of security is specious at best.
- froh 5y ago
  Wow. Your right, for spectre patches were needed on system z. https://www.suse.com/de-de/support/kb/doc/?id=000019105 https://www.suse.com/de-de/support/kb/doc/?id=000019105 Meltdown didn't affect z nor amd.
  - monocasa 5y ago
    Series Z and POWER up to and including POWER9 are susceptible to meltdown as well. https://www.zdnet.com/article/meltdown-spectre-ibm-preps-firmware-and-os-fixes-for-vulnerable-power-cpus/ https://www.zdnet.com/article/meltdown-spectre-ibm-preps-fir...
    - froh 5y ago
      Ok. debian is even more explicit than suse above regarding "no meltdown on Z": https://wiki.debian.org/DebianSecurity/SpectreMeltdown#System_z_.28s390x.29 https://wiki.debian.org/DebianSecurity/SpectreMeltdown#Syste...
    - 5y ago

short12 5y ago

AMD seems to be doing just fine. With a roadmap for the future. They will be just fine

deleted 5y ago

[deleted]

Arrath 5y ago

> This will be a massive opportunity for ARM & SoC manufacturers in the coming years, as its far better positioned to offer, for example, a single rack appliance with 64 individual 2-core mini-computers at a price-point competitive with a 128 core x86 rack, as one computer. I'm curious about the eventual end-game of security in this space. Take the 64 individual processors in your example, give each one their own independent memory bus to their own ram chip, isolate them from each other as much as possible. What else can be done, if a malicious process on processor Z has to go all the way to disk to try to get back at data working on processor J, is that as maximally secure as it can be without being in a completely separate chassis with only network access to the other device?

015a 5y ago
I think what you describe is a likely end-state, and what large cloud providers will move to. The problem right now is that a setup like this isn't cheap; but its only expensive because economics of scale aren't behind it; that will change if demand for more isolated VMs increases. Essentially, a board with an array of "mini computers", 1-4 cores bussed to their own physically and logically isolated memory pool. Storage is oftentimes already networked in public cloud, and seemingly less susceptible to these kinds of attacks, so probably little change is necessary there. Its also likely we'll see vendors produce more "card computers", like the raspberry pi, but oriented at a server environment. At massive scale like what AWS runs at, these are less compelling, but they do have advantages; the biggest being, maintenance is a cinch, and the blast radius on one failing is isolated to just the workload on that card. I imagine these will be more interesting for current VPS providers like DigitalOcean, who also want to offer dedicated hosts with smaller core/memory counts. Even RPis today are super compelling; a $50 multicore computer that's easy to manufacture and replace, with density high enough to fit 100+ inside a 4U? Just need a bit more core perf and ARM adoption (though its easy to see Intel also hoping on this train with their long-term investment in pro/consumer NUCs). Writing is on the wall. The tipping point will be an industry thought leader saying, in effect, "you should be using dedicated hosts, because at this point physics is our enemy and we're not winning, by the way here's a new dedicated host instance type that's perfectly suited for horizontally scaled workloads, its 20% more expensive than virtual hosts of the same size, byeeee".

FpUser 5y ago

>"as its far better positioned to offer, for example, a single rack appliance with 64 individual 2-core mini-computers at a price-point competitive with a 128 core x86 rack," I have server application capable of utilizing many threads and thousands requests/s. You think I will deploy it on tiny 2 core CPU? No thank you, it currently runs on powerful dedicated server from Hetzner where I control everything. >"AMD and Intel need to adjust, or face extinction .... If they don't evolve, AWS will for them..." Sounds like pontification / FUD.

tadbit 5y ago
> Sounds like pontification / FUD. Sounds like you didn't fully grasp what the grandparent was writing about. >> Eventually, it will be obvious that running shared workloads on a single piece of physical hardware has fundamentally unremediatable security implications > I have server application capable of utilizing many threads and thousands requests/s. You think I will deploy it on tiny 2 core CPU? No thank you, it currently runs on powerful dedicated server from Hetzner where I control everything. Your use case isn't covered here, you're neither a cloud nor VPS customer. There will always be individuals and companies looking for dedicated hosting solutions, or just hosting it themselves. However, for the rest of the world that wants to run their stuff in the cloud that's where Amazon's and other companies investments in ARM come into play. That's where we'll see disruption, the extinction the grandparent was talking about.