Re: [bitfolk] Reboots will be required for security patching…

Top Page
Author: Andy Smith
Date:  
To: announce
Subject: Re: [bitfolk] Reboots will be required for security patching, most likely 29/30/31 October

Reply to this message
gpg: Signature made Thu Oct 31 03:29:16 2019 UTC
gpg: using DSA key 2099B64CBF15490B
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]
Hello,

This maintenance has now been completed without incident.

The security issues that were fixed will come out of embargo after
12:00Z today, so you can find details about them here after that
time:

    https://xenbits.xen.org/xsa/


In addition, all CPU firmware was updated to the latest available
and SMT (hyperthreading) was disabled to better protect you against
existing and future CPU side channel attacks.

We may be able to revisit that decision when Xen's "Core Scheduling"
feature is available:

    https://www.youtube.com/watch?v=qLWc2QvsU0A
    https://www.slideshare.net/xen_com_mgr/xpdds19-core-scheduling-in-xen-jrgen-gro-suse


This would mean that all the vCPUs you see in your VM would not
share a core with other VMs, as a lot of the side channel attacks
involve fetching data out of resources that are shared by all
threads on the same CPU core.

I am not sure we will ever get to the stage where that is safe,
however. For example, processes within your VM may still be able to
use that to get data from shared resources and leak across security
domains.

Disabling SMT has raised apparent CPU usage to a level which is
slightly alarming but not, I think, actually detrimental. You can
see that here:

    https://bitfolk.com/techspec.html


where it is very obvious where the disabling of SMT happened for
each server (except "limoncello" and "talisker" which always had it
disabled)

I am not entirely sure that the old stats were valid. They assume
that every CPU thread could provide the same amount of compute
power, even when half of them are on the same core as the other
half. If a server showed as 40% loaded before, was it really, or was
there in reality a lower cap to what could possibly be used?

Anyway, there are two largely unused servers and I'm going to
rebalance heaviest users onto them to reduce overall CPU load.

Cheers,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce@???
https://lists.bitfolk.com/mailman/listinfo/announce