Do you still keep your OpenVZ vps in 2026?

Comments

• _cece Member

  June 10

  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
• totally_not_banned Member

  June 10 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.
• forest Member

  June 10

  @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.
• totally_not_banned Member

  June 10 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?
• backtogeek Member, Host Rep

  June 10

  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 🕊️✌️
• forest Member

  June 10 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.
• totally_not_banned Member

  June 10 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.
• OscarCipriano Member, Patron Provider

  8:24PM

  @bustersg said:
  i have 1 expiring in june, not sure if to renew for another year.
  it has stable uptime, 156 days, with good provider fast response and is a $7 deal with IPv4 but OpenVZ is kinda of dead these days.
  e.g., Docker tech is way better than OpenVZ.

  As a hosting provider, I have warned all my clients and shut it down due to a lack of security.

  No other words needed