New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
VPS with TEE capabilities
sebastiaandev
Member
in Requests
Hi all,
I was wondering if any provider here offers VPS’es with TDX support? For reference, I know Xeon Scalable 5th gen CPUs have hardware support for TDX.
Thanks in advance,
Sebastiaan
Comments
Is it like intel's version of AMD SEV? (memory encryption and signing)
As far as I understand yes, Intel’s previous confidential computing offer was/is SGX. But this has several constraints on the system calls you can make. TDX allows more flexibility in that regard, similar to AMD SEV.
Haven't seen any provider doing intel TDX. If any provider has capability to enable intel TDX - i'm interested. It seems to be far less polished than AMD SEV and have less support overall.
Would recommend you checking which CPUs support it (pretty sure it's only the latest generations) and bully providers who have such CPUs to enable TDX.
For now, I can tell you more about AMD SEV.
Okay so a few providers enabling AMD SEV:
Ultimately, if you want confidential computing then cloud providers like Oracle, GCP and AWS have it while being far more reliable and expensive than LET hosts.
Thanks @oloke for the mention.
SEV / SEV-ES support will be enabled in Amsterdam this week. Support for New York, Sydney, and Singapore will follow once the new nodes are deployed, with ETA ~ 2-3 weeks
SEV-SNP support:
TDX support:
- ?? crickets ...
No support:
- loclix (source: DM)
- greencloudvps (source: DM)
- incognet.io (only SME and SEV-ES https://lowendtalk.com/discussion/comment/4355400/#Comment_4355400)
Ghosted me:
- alphavps
- hostdodo
Yes, those have SEV-SNP. I didn't know about hostsailor, but i will DM them as well.
Thanks for your research.
I don't think they actually support any kind of memory encryption at present. They had it on their knowledgebase page for a few months, then removed it when I asked about SEV. That says something about incognet in general...
Most likely they don't. A lot of hosts here use just VirtFusion or Virtualizor. Those products do not have any kind of SEV support (nor is it planned afaik). So far, all providers who have SEV support use their own custom solutions.
We "do", but not yet on every hypervisor or in every POP. Can do in WA, for example.
Will likely try to plan some future maintenance window but I don't really want to reboot hypervisors just to enable a feature a few may be interested in. Probably just double check the setup before deployment of new ones into production but it's difficult to run a bunch of hypervisors once the offered feature set differs from one to another, then you have two groups of potential clients for future maintenance or migrations that need accommodated.
@onidel has a great feature that allows the user to toggle on/off the setting from their control panel. That's pretty rad.
I bought a @HostSailor EPIC VPS and requested SEV-SNP to be enabled or to be moved to a node where I could. Customer support told me "Unfortunately none of our nodes support the requested extension."
Maybe other locations can.
TDX is kind of broken if you have physical access to the hardware, what's why "crypto bros" run their validators only in "trusted" cloud like Amazon.
https://tee.fail/
There's a bot on their Twitter which signs your message with the "real" TDX key
https://x.com/TeeDotFail/with_replies
Here's Secret Network reply to the findings:
Aren't Intel TME or AMD TSME the protection against physical attacks with transparent DRAM encryption? TDX and SEV-SNP are a second layer for VM protection but not meant to protect against physical attacks. Why are these researchers conveniently not addressing this?
They first get the hardware unique key from the server once, then they can derive all the other keys, including attestation keys.
https://tee.fail/files/paper.pdf
@Odysseus Sorry to hear about it. Can you please share order number/ticket number here or PM and we will check it to find solution
LMAO
Thanks @ValdikSS . I wasn't aware of this paper. Such great research.
The ability to deal with confidential data is what initially attracted me to this whole memory encryption rabbithole. Putting trust into cloud provider is similar to running without memory encryption at all (depends on how much trust you have exactly and what effort do you expect from potential attacker to be put)
I assume by reputable cloud providers they mean AWS/GCP.
You are right here. At least AMD does not advertise SEV-SNP as something resistant to active DRAM probing/injection attacks:
https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3024.html
https://docs.amd.com/v/u/en-US/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more (page 6)
However, I think it's still important that such attack was presented and executed without use of expensive tooling. Additionally, some people may have wrong assumption that SEV-SNP will protect them even with active hardware probing.
Taken from @onidel 's wiki page:
That makes sense, if the code runs on untrusted hardware, we have no guarantees it remains in tact and not actively analyzed. I wouldn't say it's pointless to use SEV-SNP. It makes memory extraction still much harder than just dumping unencrypted RAM.
I hope this research will help hardware vendors to provide better implementation in future CPU revisions
I had some time to read the paper. Focusing on SEV-SNP.
Constraints used:
1. Host OS access. To disable memory caching for the VM's memory pages on the host kernel and setting breakpoint on memory pages of the VM.
2. Know the exact software that is going to be executed (realistically possible)
3. Know the exact memory address the key is going to be stored (more expensive hardware might not have this limitation)
(1) AMD can disable the SNP memory caching control and not allow breakpoints on SNP memory. This should be possible because SGX already does this according to the paper. That would make a memory profiling attack much harder.
I don't think it needs to be 100% perfect because there is always acoustic cryptographic analysis.
Is it right to say that this could be mitigated if the chip makers used any kind of IND-CPA encryption scheme?
I just skimmed the paper. They do use an IND-CPA scheme (XTS, which is actually CCA), so I'm not sure why they're talking about the famous ECB penguin, since that is impossible in XTS. Since they're talking about deterministic encryption, I'm guessing they're just using a fixed IV.
Acoustic cryptanalysis is generally much, much harder for constant-time implementations. Even differential power analysis is not trivial.
This seems like pulling teeth to find more than a handful of providers supporting SEV-SNP. Add Oplink and FDC as they have told me they support SEV-SNP.
@oplink could you please confirm you support SEV-SNP?
Thanks for the search @CTH .
It appears the 9950x CPU supports it, but its not enabled on the host node > client VMs at this time. I will add this to todo list of things to check on/test
Curious.. What are you using it for?
it's ... confidential
Hi, appreciate your response
Sadly, I don't think 9950x (or any ryzen for that matter) supports SEV.
From what I know, it's only supported on EPYC CPUs:
https://www.amd.com/en/developer/sev.html
SEV-SNP is supported on EPYC Milan and newer.
Confidential computing (guest RAM encryption and attestation in -SNP).
lmao true
ps. @onidel is still the only LET provider who supports SEV-SNP as of January 2026.
btw, found another research paper and attack from a couple days ago conducted on SEV-SNP:
https://stackwarpattack.com/
https://cispa.de/news/2026/stackwarp-final.pdf
Looked briefly into it, seems to only be possible when SMT is enabled (pretty much every host nowadays).
Unrelated to SEV, but another interesting talk on risks of SMT in cloud environments:
https://media.ccc.de/v/39c3-spectre-in-the-real-world-leaking-your-private-data-from-the-cloud-with-cpu-vulnerabilities
SMT makes a huge number of attacks possible inside and outside of cloud environments. It's a security nightmare.
OpenBSD has SMT disabled by default - https://www.openbsd.org/faq/faq10.html#SMT
Useful when running one tenant(also SAAS client) per vm and really only need a single core. "Confidential" in this case being anything the host or host's remote hands don't need to be concerned with.
My asking for SNP support is because OpenBSD now supports it and fits with my threat modeling for acceptable scenarios at POPs where a full dedicated or colocated equipment is a stretch.
Have heard some more "no" responses since I posted. And the expected ghosts.
Same in QubesOS. Really nice to hear this is supported now on OpenBSD as well
On cloud providers it's somewhat hard to justify to disable SMT in processors.
Disabling half of the threads would mean providers have essentially halve their CPU capacity.
I think the mentioned performance hit was around 40%, but it depends on the workload as well.
Even Google and AWS tried to patch the demonstrated vulnerability with hypervisor workarounds, because disabling SMT would cost them too much.
If you want SEV-SNP support, then I can fully recommend @onidel . They are very reliable and allow custom ISO installations so I think OpenBSD would work with no issues.
Only downside is they do not support Monero payment anymore, if that's something you care about.
Thanks oloke.
In my case at least, the provider doesn't need to disable SMT on their hypervisor. I load a custom build OpenBSD WITH SMT. OpenBSD has its own VMM and those sub guests(also OpenBSD and what the client data goes onto) are only one core and SMT disabled.
Yes, Onidel has been very responsive as has VPSBG. I guess these are just early days for support. I would expect this to be default for the future.
I currently do this on Amazon AWS for a few remote locations that supports EPYC(3rd generation onward) and SEV-SNP but hard to swallow their pricing. Google GCP also supports SEV-SNP but 4th and 5th generation EPYC instances require gVNIC adapters to interface with Titanium(offloaded networking and storage). OpenBSD doesn't have support for gVNIC.
It's actually not that bad. Performance hit is between 10 and 20% on most modern systems. I think Intel processors don't gain as much from SMT as AMD processors do (or maybe it's the other way around). It's very rare for the performance benefit to be anywhere near 50% unless you are doing some very particular workloads (e.g. extremely heavy vector arithmetic on one thread and extremely heavy memory ops on its SMT sibling).
I believe both AMD and Intel are planning to slowly deprecate SMT due to the performance benefit decreasing (especially with security mitigations in place) to the point that it's no longer worth the extra silicon and thermal budget required to double the speed of the instruction decoder/dispatcher and associated control flow components.
SMT is really just a hack for when out-of-order execution isn't enough to fill the CPU's increasingly-deep pipelines, but uop dependency resolution is so good these days that that's getting rare.
I think it'd be fair if you purchase 2 dedicated vCPU to request that they get pinned to the same core and for nobody else to be able to use that core.
We recently have setup Virtfusion on Epyc Milan 74F3 nodes, we have made a small hook that automatically enables SEV-SNP if you switch your VM to UEFI mode.
All vms are using 1G locked hugepages. The cheapest instance is just 4 usd/month for 1c/1g/12gb nvme.
Oh damn, I only have a Xeon node with you guys.
Do you think you could possibly whitelist Tor through your website's firewall? Not necessarily to sign up or order, just to be able to view the site and log in for people (like me) who already have an account, since right now it seemsm to do a
-j DROP. If so, I might end up buying another VPS in hopes to get a node with SEV!