gpg: Signature made Tue May 22 09:19:42 2018 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]
Hi,
TL;DR version: We're not patching and rebooting for this because
it's best fixed in your guests. If you had bare metal you'd have no
choice and would be doing that anyway.
Long version:
There is a Xen Security Advisory today which is yet more fallout
from the same class of CPU security issues as "Spectre" and
"Meltdown":
<https://xenbits.xen.org/xsa/advisory-263.html>
Usually there is a 2 week embargo on these things but as I
understand it there is no embargo this time because the discoverers
did not agree to one.
This issue is a hardware / design flaw which affects almost every
CPU in the world (all Intel, many AMD, some ARM). The potential
impact is unprivileged processes being able to read arbitrary
memory.
The Xen developers do not believe that it is possible for this to go
between guests nor between guest and hypervisor, so this restricts
the issue to processes within your guest.
As this also affects bare metal and almost every other configuration
of Linux, it will be addressed in software by your operating system
vendors by means of package update.
Some of the software fixes require updated firmware, and these
firmware updates have already been applied so that is ready for you
when you need it.
The patches supplied by Xen for this XSA do allow us to fix the
issue at a higher level in the hypervisor, thus not requiring any
changes in your VPSes, but at a cost of having to schedule another
round of reboots.
At this stage I am not inclined to enforce a reboot for this; I
think it's best fixed in the guests.
In the near future we will deploy one new host that has this bug
addressed at the hypervisor level and anyone who for whatever reason
cannot update their VPS can have it moved to that host.
This could be subject to change if there are further discoveries
about this particular bug, and I also doubt we have heard the last
of security bugs in this class. There could well be another XSA
along soon that requires reboot, in which case we may end up turning
this mitigation on as well at that time.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
