gpg: Signature made Tue Jan 18 09:18:06 2022 UTC
gpg: using DSA key 0E4236CB52951E14536066222099B64CBF15490B
gpg: Good signature from "Andy Smith <andy@strugglers.net>" [unknown]
gpg: aka "Andrew James Smith <andy@strugglers.net>" [unknown]
gpg: aka "Andy Smith (UKUUG) <andy.smith@ukuug.org>" [unknown]
gpg: aka "Andy Smith (BitFolk Ltd.) <andy@bitfolk.com>" [unknown]
gpg: aka "Andy Smith (Linux User Groups UK) <andy@lug.org.uk>" [unknown]
gpg: aka "Andy Smith (Cernio Technology Cooperative) <andy.smith@cernio.com>" [unknown]
Hi,
The below happened earlier today. 123 of you have had your configs
changed to use pvshim, which will take effect from your next boot.
If you are still on 32-bit PV this doesn't avoid many of the issues
for you with that, it just avoids the issues for us of you doing
that. In particular, you won't be able to upgrade your Linux kernel
past v5.9.
If planning to continue upgrading a 32-bit VM in place you will need
to switch to PVH mode before you get to a kernel version that
doesn't work in PV mode any more. In particular for Debian users
that means before rebooting in to Debian 11 (bullseye).
Or reinstall¹ in place into 64-bit PVH mode, or ask for a new account
for migration² and do a new install into that.
Cheers,
Andy
¹
https://tools.bitfolk.com/wiki/Using_the_self-serve_net_installer
²
https://tools.bitfolk.com/wiki/Migrating_to_a_new_VPS
On Sat, Dec 18, 2021 at 03:24:13PM +0000, Andy Smith wrote:
> Hi,
>
> TL;DR: The ~30% of you still running 32-bit PV guests are going to
> have your config changed in a month. We've tested that on many
> different configurations and haven't had a problem yet but it's
> always possible something could go wrong, and if so you'll only find
> out at the next boot. If affected we recommend you instead make the
> change yourself at a time convenient to you.
>
> This email is only relevant to you if you're still running in 32-bit
> PV mode. Most customers run 64-bit. If you type "uname -m" in your
> VM then it will say "amd64" for 64-bit and "i686" for 32-bit. It
> also says it on the summary page of:
>
> https://panel.bitfolk.com/account/
>
> You can stop reading if you're already running as 64-bit, or in PVH
> mode.
>
> We haven't got a simple way to check if you are PVH mode because the
> intention is that eventually will be a detail you don't have to care
> about (all VMs will be PVH and that has been the default for over a
> year now). You can for now log in to the Xen Shell and type
> "virtmode" and it will tell you. So if that says "PVH" you can also
> stop reading.
>
> For several years now we have been trying to encourage customers
> running 32-bit PV mode guests to switch to 64-bit and / or PVH mode.
>
> There are many reasons for this but the most pressing one is that
> it's not possible to fully protect 32-bit PV guests against the
> various already known speculation attacks (nor probably new ones
> that will be discovered).
>
> About 30% of the customer base still runs 32-bit PV mode guests even
> though the default has been 64-bit since about 2012. We are clearly
> not going to be able to force everyone to switch in a timely manner
> so we have been testing a different way of running legacy 32-bit PV
> mode guests.
>
> That testing has gone well - there haven't been any issues - so
> we're going to convert all remaining 32-bit PV mode guests to that
> configuration on Tuesday 18 January 2022.
>
> Since it's not possible to test every permutation of installed guest
> though, we can't rule out there being a problem, and that problem
> will only manifest at your next boot.
>
> If you'd like to make the config change ahead of time here is how:
>
> 1. Log in to your Xen Shell.
>
> More info: https://tools.bitfolk.com/wiki/Xen_Shell
>
> 2. Make sure the version in the "help" command is at least this:
>
> xen-shell> help
>
> xen-shell v1.48bitfolk66
>
> The Xen Shell stays running after you disconnect so it is
> possible to be running an older version. If it is older, "exit"
> out of every window until it logs you out, then log in again.
>
> 3. Use the "arch" and "virtmode" commands to confirm that you are
> currently running in 32-bit PV mode:
>
> xen-shell> arch
>
> Your current install architecture is: i686
>
> xen-shell> virtmode
>
> Your current virtualisation mode is: PV
>
> 4. Use the "arch i686" command to force a switch to i686 (32-bit)
> architecture again. This will update your config to use pvshim.
>
> 5. Use the "shutdown" command to shut your guest down.
>
> 6. Use the "boot" command to boot it again.
>
> It should boot pretty much the same as before. If it does not, then
> you will likely not be able to get it to boot again yourself and
> will need to put in a support ticket.
>
> This change will be made for all remaining 32-bit PV mode guests on
> Tuesday 18 January, without further testing, as that would involve
> forcible reboot.
>
> If you do want to take some action about this here are some things
> you could do, in order of best choices to worst choices:
>
> a) Ask for a new "migration VPS" which would be an empty account
> that you can do a new install into (which would be 64-bit PVH as
> that's the default):
>
> https://tools.bitfolk.com/wiki/Migrating_to_a_new_VPS
>
> b) Upgrade your kernel past 4.19.0 and make sure you're running
> grub-pc (not legacy Grub) as bootloader, with a
> /boot/grub/grub.cfg file, then switch to PVH mode.
>
> c) If running at least Debian 7 (wheezy) or comparable age Ubuntu
> you can install an amd64 (64-bit) kernel even while everything
> else is 32-bit. That turns your VM into a 64-bit PV guest. Follow
> these CrossGrading instructions only as far as installing and
> booting into the new kernel:
>
> https://wiki.debian.org/CrossGrading
>
> d) Do nothing and let us switch you to using pvshim. Your guest is
> still insecure and running with reduced performance compared to
> 64-bit but this only then affects you.
>
> Cheers,
> Andy
>
> --
> https://bitfolk.com/ -- No-nonsense VPS hosting
