All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
New CPU security flaws found.. Still think AMDs Encrypted Virtual Memory isn't worth it?
Another day, another security flaw found on Intel processors. No word if AMD is vulnerable to these but they appear to be bare metal vulnerabilities.
It's not too difficult to lock down access from a virtual system from the bare metal host OS with additional passwords. However it is incredibly difficult to secure the data in a VM from the ram. AMD has developed a solution and incorporated it into the new AMD EPYC processors called SEV..
I've said it before and I'll say it again
AS A VIRTUAL SYSTEM CUSTOMER I WOULD PAY EXTRA FOR SOLUTIONS WITH AMD SEV ENABLED!
Not only is AMD EPYC cheaper but provides ability to run more ram (2TB), allows for NVME raid onboard, has more PCIe lanes available and has more secure encryption protocols for memory built in.
Providers need to get their head out of the sand and accept that Intel has dropped the ball! Every day there is another bare metal security flaw affecting Intel and yet Intel still doesn't have an encrypted memory solution for VMs like AMD's SEV on EPYC.
I'm tired of excuses for why providers here don't want to use AMD.. We consumers deserve secure solutions and without even willing to offer a single system with encrypted VM memory your essentially saying you don't care about our security.
So I'll say it again. I won't be buying anymore VPSs without encrypted memory solutions enabled. As a community we need take this seriously because it's obvious hosts don't care at all!
Comments
Doing anything high security on a multi-tenant VPS node is asking for trouble whether or not it has SEV. If you're doing something serious, use a dedi or single tenant node.
So with the vast majority of hosts only offering Intel dedicated boxes I suppose that protects us from these bare metal vulnerabilities how?
I suppose our only option is to build an AMD EPYC server. Setup memory encryption. Create and lock down VPSs then send it off to be colocated?
That's the only option for secure VPS in your mind Willie? Seems like a void that could be filled if providers took this more seriously...
And then AMD vulnerabilities come out? What then.
You claim it's an Intel sponsored hit job, duh.
Francisco
You feel better knowing that even if there is a bare metal vulnerability your VPS is protected via memory encryption, hard drive encryption, and additional security preventing unauthorized access to the data. It's one thing to gain remote access to a system, it's another to gain access to additionally protected virtual systems.
But you have to demand these things. Hosts don't want to put in the extra effort if no one cares...
That happened recently actually and it was found to be a hit job by a for profit company looking to make money on selling information on the release date to short investors. The "vulnerabilities" ended up being nothing short of obvious issues that would happen with literally any system. (you had to have prior bare metal access as in a current admin..)
For the record I'm not saying AMD is immune from any issues, I'm saying the ability to encrypt memory and stored data is a good step in protecting consumer data and VPSs from unauthorized access as a result of these new vulnerabilities that keep popping up.
So why aren't providers taking this seriously enough to offer it to their customers? Perhaps its because no one is asking for it. So we should speak up and make it known that we value security and providers that value our security.
Most hardware and software of whatever provenance has flaws.
Could some be dangerous ? Yes. Do any of them crumble the world as the demented anti-open source hype over HeartBleed suggested would happen ? Probably not.
Hmm, is it a war? AMD rent a lot of talent engineers and found Intel's bug and maybe, the Intel turn is the next?
More information released. Seems the flaw allows for access to non encrypted memory data on Intel CPUs
https://www.zdnet.com/article/ex-intel-security-expert-this-new-spectre-attack-can-even-reveal-firmware-secrets/
But let's not take this seriously and demand change. Let's instead allow the multi billion dollar corporation that was aware of the flaw and continued to sell flawed chips without recall to just walk away with a patch that degrades performance and makes customers need new CPUs
That's not the point I'm making. The point I'm making is that as consumers in the virtual system space we are dependent on the providers to secure the host system. We should request more security when options are available instead allowing them do whatever they want because it's easier.
I trust my system admins but I know they aren't doing more than they have to unless they are told to... We should request change in the current environment to protect ourselves and our data.
One challenge is how they’d prove it.
I can see people just copy/pasting claims from a competitor’s web site.
If you're willing to write a check then I'm 100% sure they'd be happy to make the switch.
Isnt everything hackable?
I'm sure hobbyists would love for providers to change hardware every time there's a new scare. Production customers aren't as often easily moved. Plan your reactions as carefully as your provider should, thoroughly. Knee jerk reactions rarely actually put anyone in a better place.
That's my 2c at least. I've had enough experience with making knee jerk reactions in production that would've been just fine for my blog or my VPN, but cost my customers downtime and they didn't give two shits about the reason.
I have a pile of cancellations and chargebacks from taking VestaCP offline to protect customer data, that should tell you a lot.
You will need to wait some more.
Enterprise adoption takes 2 generations - EPYC on Zen base is now in test and certification (VMWare, HyperV and so are extremely important), first servers for early adpoters are shipping in useful qty only now.
Zen2 will be far more spread then as the cpu arch is the same so the testing methodology can be just adopted and higher adoption will start.
Intel does not have this problems by the market share but it was visible on the last useful Opterons. Zen is just too far from Bulldozer/Anything to drop-in adopt for crucial things (see eg. the Linux bugs in some).
It would be interesting how that compares with the potential fines you would have gotten had the known flaw been exploited and customer data leaked.
Feels like a catch 22 , screwed if you do screwed if you don't
Fuck no, taking it offline was the only course of action at that point. Keeping it offline would be my "plan for the future", but it's not up to me I suppose.
Then you might as well stop coming back to LET as most vendors here are using older hardware kits to be able to afford the lower prices. No provider here is going to spend thousands on new kit just to come and sell that hardware here on LET, there would be no realistic ROI on such an investment. Especially not at $7. This is the wrong issue for this community to take on as no provider here is going to afford this, except for maybe the large corporate sellers, which really are not the reason we are here. We are here to support the small companies and start-ups that are trying their best to enter the industry. None of them are going to afford brand new AMD kit, that would destroy their profit margin before then even began.
Additionally, I agree fully with what others have said above, you shouldn't be running something which you would have this concern for on a VPS and instead should get your own dedicated server. There is no way to actually confirm your data is secure in a virtual server, anyways, regardless of the ram issue. Even if you use something like LUKS encryption to encrypt your drive image and think this secure, you are wrong, it is rather easy to dump the VMs memory, get the encryption key and then gain access to the data. While there is more overhead to it, it is much more likely to happen than trying to exploit these Intel 'memory' exploits being reported unless you are an Intel engineer or genius level programmer who understands how to manipulate memory and understands the drivers and how they work.
If you are concerned about your data then you shouldn't be placing it on a virtual server and should using your own server. By own server, I mean one you purchased your self and colo, cause how can you be sure there isn't extraneous hardware in the servers you rent/lease allowing backdoor access to your data? You can't. My point is, you need to adjust the way you think about storing your data and where you are storing it instead of worrying about if someone is going to figure out how to use one of these Intel exploits and gain access to your virtual server.
my 2 cents.
Cheers!
Tell that to companies that use AWS and Azure to host PHI information. They even pass certifications and regulations.
No idea about Azure but AWS offers single tenant and (more recently) bare metal servers and that's what you should use for very sensitive info. Significant amounts of PHI should probably be included in that. Regular PII (that means stuff like email addresses) aren't likely to be the target of serious SPECTRE attacks.
Browser exploits should have taught us by now that trying to sandbox hostile code is a lost cause. Maybe multi-tenant virtualization is the same way. Or maybe we should go to POWER9-style CPUs where there's a large number of hardware threads per CPU core (like 16 instead of 2), that can be dedicated to VMs and that have their own branch prediction buffers etc. That might still leave gaps but it sounds like it could help.
It should, but nobody does that. Companies assume that by using Azure or AWS they are secure. Plus there is really no requirement there saying "for PHI only bare metal".
Sadly.
And that's the thing with taking shortcuts to save money, whether to profit or to benefit your Customers with lower prices - it tends to bite you...
Providers bring on new nodes regularly. AMD EPYC hardware is currently per core more affordable than Intel setups. When you factor in the built in NVME support without a need for an "unlock key" like on Intel or lower electricity cost of a single socket 16core EPYC vs same cost 2x socket 8core Intel's you end up with a wise choose. The added value to consumers from memory encryption is just a bonus from a financial standpoint.
Incorrect. Many providers here build new servers for vps solutions. Not all providers here are using Intel Xeon servers from 2009.... Your assumption is incorrect and frankly insulting the many to notch providers here.
This is literally what AMDs EPYC's SEV solution prevents from happening.. Watch the video I posted...
I have a multi tiered approach. But that doesn't mean I don't value security of my data stored on a VPS. Many users here run services on a VPS where the data isn't super sensitive but that doesn't mean they don't value their security.
Right?! Lol
You don't have to have super sensitive data to mean you value the security of the hosted data. AMD EPYC and SEV aren't super expensive hardware. Infact it's cheaper than an equivalent per core Intel solution. EPYC has already proven to be extremely stable virtualization platform. Those not considering it for their new node are only doing themselves and their customers an injustice.
@jarland is incorrect. This isn't a knew jerk reaction. This is your customer base letting you know we value our security and would appreciate you considering solutions like AMD EPYC s SEV for future upgrades of your nodes or expansions. I'm not saying take down your existing servers and replace them with EPYC and enable SEV. I'm saying consider a solution with secure virtual memory encryption like AMDs SEV for future upgrades. I'm also saying that consumers might even pay extra for such security even though the system would be cheaper than an equivalent Intel solution just so we can secure our data better..
After all LET is meant to be discussion platform between nimble and knowledgeable providers and a user base willing to try out new providers and services. So let's talk.
Oh give it a break, this is LET and taking shortcuts to save money is precisely what this place is about. It's no different than placing bets in the stock market. Eliminating the possibility of getting bitten is not part of the goal. You only want the odds to be in your favor and if you can do that, then it's a good bet.
If your priority is avoiding getting bitten, you can buy government bonds and host your stuff at AWS, but you get lower returns that way. Here at LET we're about saving money even when it means taking chances. As long as we do it with our eyes open, that's a great thing. People who run critical services on low end servers are crazy or deluded. But most of us have enough sense to not do that.
Yeah, but business is no charity and risk costs as proved above. Chargebacks cost (and can have long-term consequences - namely rates and even closed merchant accounts). Lost Customers cost. Doing the business in a responsible manner is what one owes to their Customers, wouldn't you agree?
LET or not, it's not about ending up disappointing your Customers halfway through their paid for term, is it?
Or atleast have redundancy in place/backups along with enough research into a provider. The deals I've gotten on my services here are spectacular. But I also don't have all my eggs in one basket. That's important IMO
1% of us, the last of us, LET version.
Also a good strategy .
I don't see that at the moment, for comparable total performance. E.g. comparing a Hetzner AX160 (Epyc 7401P, 24 cores) with an older 20 core Intel E5 server that's comparable (Intel usually has better single core speed). The E5 may have cost more when it was new, but you're comparing a new Epyc server to an already-depreciated E5 that still works fine. From an LET cheapskate perspective as much as I like Epyc, it isn't really here yet, unless SEV is a defining feature.
1) it seems to me that Spectre was tail risk, not easily predicted and even if it put some low end providers and customers in a difficult spot, it's small potatoes compared to something like the 2008 financial meltdown which was caused by much bigger and stupider risks.
2) In the VestaCP example, regardless of how much the host is paying or charging, it's not obvious what you can expect them to do except take it offline til the smoke clears. Maybe some hacky manual or semi-manual order processing can be put in place until Vesta is restored.
I mostly see LET's user base as people trying to run non-critical applications on minimal funds. E.g. the driving application for dedis on LET has usually been personal media servers. If one of those goes offline for a few evenings, its users might be temporarily annoyed, but nobody gets injured or goes broke. My own Hetzner dedi has occasional network interruptions and slowdowns (actual server uptime has been great) and it's sometimes a hassle. Would I pay more money to avoid that? Maybe a little, but nowhere near what high-availability hosting would cost. I just accept the hassle as part of the tradeoff of a cheap server.
My point is one shouldn't have used it in the first place. No solid community maintaining the code like, for example, SSH is maintained, nor a suable entity responsible for patching it like cPanel. Whatever was saved by not paying for cPanel is likely already burned in chargeback costs, refunds, lost customers and more importantly reputation. Unsatisfied Customer takes another 10 Customers away.
I'm not having a go at anyone, I'm merely saying that cost-cutting has to be responsible and thus there's a difference between cheap and sustainable and cheap and unsustainable. You can call it nagging, but that's how it is. It's not about complaining that someone can do it cheaper. This comes from the experience of running the business.
... and in 6 months an exploit will be found that hooks into SEV, granting you full access to memory before it's encrypted.
Shit happens, exploits happen - I'm not going to refit dozens of servers due to two x86 exploits.