Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Shells Virtual Desktop
BMail.ag - Secure Email Service
Server.net
CPLicense.net
VPS Server
Buy VPN
Vultr
VMs for AI
HostDare
ReliableSite White-Label Dedicated Hosting for Resellers
InterServer VPS
BMail.ag - Secure Email Service
Best VPN
High-Performance Bare Metal Server Solutions
Karvl.com
Server Mania Cloud Hosting
DataWagon Hosting
AlphaVPS Hosting
Evoxt.com
Clouvider
VPS Hosting with NVMe
Residential IPs in the US & 4G Mobile Proxies in EU & US with Unlimited Bandwidth
ReliableSite White-Label Dedicated Hosting for Resellers
Rabisu - Hosting Solutions
Shells Virtual Desktop
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.

Do you still keep your OpenVZ vps in 2026?

13»

Comments

  • _cece_cece Member

    well I have one which just is used as a VPN. So I’ll keep it.

    Another question to the providers: how long will they keep it? And any plans for moving those VPS? @EthernetServers

  • edited June 10

    @_cece said:
    And any plans for moving those VPS?

    I figure at some point hosts will just have to bite the bullet and either move to KVM or LXC.

  • forestforest Member

    @totally_not_banned said: Under ideal circumstances that might actually be the case but even then things stop being so easy once your target is a specific peace of logic in an executable whose exact version or binary representation you don't know.

    Perhaps I misunderstood. I thought the goal was just achieving control of the guest from the host by abusing access to the guest's memory, in which case the minimum you need to do is spawn a shell and establish a way to communicate with the shell.

    @totally_not_banned said: Whatever the guest tries to do to verify the presence of those protections can be swapped behind its back (maybe at a massive cost but it still can).

    Remote attestation only works if hardware support is present to protect the guest from the host specifically to prevent anything from being swapped from behind the guest's back. It's sort of like a more efficient and polished version of SGX, but for virtualization.

    Remote attestation is a two-way operation and is most certainly possible to achieve with strong cryptographic guarantees. Its purpose is to limit the TCB to a small piece of hardware.

  • edited June 10

    @forest said:

    @totally_not_banned said: Under ideal circumstances that might actually be the case but even then things stop being so easy once your target is a specific peace of logic in an executable whose exact version or binary representation you don't know.

    Perhaps I misunderstood. I thought the goal was just achieving control of the guest from the host by abusing access to the guest's memory, in which case the minimum you need to do is spawn a shell and establish a way to communicate with the shell.

    Yeah, i guess, kind of.

    @totally_not_banned said: Whatever the guest tries to do to verify the presence of those protections can be swapped behind its back (maybe at a massive cost but it still can).

    Remote attestation only works if hardware support is present to protect the guest from the host specifically to prevent anything from being swapped from behind the guest's back. It's sort of like a more efficient and polished version of SGX, but for virtualization.

    Remote attestation is a two-way operation and is most certainly possible to achieve with strong cryptographic guarantees. Its purpose is to limit the TCB to a small piece of hardware.

    Yes, i realize what it does but i'm kinda curious how it bridges the gap so to say. Cryptographic guarantees are only as good as the integrity of the keys being used and the code running the check. The execution needs to be controlled by TPM right from the start (and it has to do this in a way that without it is impossible to replicate by the host) otherwise the strongest guarantees are worth very little since they are simply going to perform their check based on wrong assumptions - at least when there's a hostile host in the picture.

    "It works because it works" is a little unsatisfying don't you think? ;)

  • backtogeekbacktogeek Member, Host Rep

    I don't think there is an OpenVZ option that is not already very end of life is there?

    Even virtuozzo 7 only has about 6 months left on extended support and in all honesty probably couldn't or wouldn't patch any new critical issues

    As much as I loved OpenVZ (eventually) it feels a bit like running windows xp with a public IP these days, it's not if, it's when it gets compromised.

    It's time.... Let it rest in peace 🕊️✌️

  • forestforest Member
    edited June 10

    @totally_not_banned said: Yes, i realize what it does but i'm kinda curious how it bridges the gap so to say. Cryptographic guarantees are only as good as the integrity of the keys being used and the code running the check. The execution needs to be controlled by TPM right from the start (and it has to do this in a way that without it is impossible to replicate by the host) otherwise the strongest guarantees are worth very little since they are simply going to perform their check based on wrong assumptions - at least when there's a hostile host in the picture.

    It doesn't need to be attested by the TPM at the beginning. So-called late launch measurement (DRTM, on Intel implemented using TXT) can verify code later in the boot process.

    Its security does rely on the hardware being secure and the hardware vendor not letting the private key get leaked.

  • edited June 10

    @forest said:

    @totally_not_banned said: Yes, i realize what it does but i'm kinda curious how it bridges the gap so to say. Cryptographic guarantees are only as good as the integrity of the keys being used and the code running the check. The execution needs to be controlled by TPM right from the start (and it has to do this in a way that without it is impossible to replicate by the host) otherwise the strongest guarantees are worth very little since they are simply going to perform their check based on wrong assumptions - at least when there's a hostile host in the picture.

    It doesn't need to be attested by the TPM at the beginning. So-called late launch measurement (DRTM, on Intel implemented using TXT) can verify code later in the boot process.

    So basically it yet again works because it works. How about we keep it at that. I mean, if you don't control the boot process you also don't control what or if anything gets measured at all but i guess that's a non-issue.

    Its security does rely on the hardware being secure and the hardware vendor not letting the private key get leaked.

    If it doesn't control the whole boot process right from the start there doesn't need to be a leaked key but i've already gone through that before you entered the conversation and it's boring to go over it yet again. Look, i'm more than happy to be proven wrong but this doesn't do anything in that regard. It's just pointless repetition and extremely tiring.

Sign In or Register to comment.