Christophe de Dinechin <dinechin@xxxxxxxxxx> writes: >> On 5 Feb 2020, at 17:06, Stefan Hajnoczi <stefanha@xxxxxxxxx> wrote: >> >> Hi Vitaly, >> I just watched your FOSDEM talk on CPU vulnerabilities in public clouds: >> https://mirror.cyberbits.eu/fosdem/2020/H.1309/vai_pubic_clouds_and_vulnerable_cpus.webm >> >> If I understand correctly the situation for cloud users is: >> 1. The cloud provider takes care of hypervisor and CPU microcode fixes >> but the instance may still be vulnerable to inter-process or guest >> kernel attacks. >> 2. /sys/devices/system/cpu/vulnerabilities lists vulnerabilities that >> the guest kernel knows about. This might be outdated if new >> vulnerabilities have been discovered since the kernel was installed. >> False negatives are possible where your slides show the guest kernel >> thinks there is no mitigation but you suspect the cloud provider has a >> fix in place. >> 3. Cloud users still need to learn about every vulnerability to >> understand whether inter-process or guest kernel attacks are possible. >> >> Overall this seems to leave cloud users in a bad situation. They >> still need to become experts in each vulnerability and don't have >> reliable information on their protection status. >> >> Users with deep pockets will pay someone to do the work for them. For >> many users the answer will probably be to apply guest OS updates and >> hope for the best? :( >> >> It would be nice if /sys/devices/system/cpu/vulnerabilities was at >> least accurate... Do you have any thoughts on improving the situation >> for users? > > I understand your concern, and it’s a great point. > > However, /sys is about the local system, so I’m not overly shocked > that it does not know about what is outside the system :-) > > What could be nice, though, is if /sys/…/vulnerabilities exposed > a list of CVEs that have been taken into account at the time > the kernel was built. > > # cat /sys/devices/system/cpu/vulnerabilities/CVE_list > 2017-5715 > 2017-5753 > 2017-5754 > 2018-3615 > 2018-3620 > 2018-3646 > 2018-12207 > 2018-12130 > 2018-12126 > 2018-12127 > 2019-11091 > 2018-3639 > 2019-11135 > > That way, you would know at least what you are measuring against. > The implementation is quite easy, see experiment here: > > https://github.com/c3d/linux/commits/cpu-bugs-cve-list > > Do you think that would have any value? > In a way, yes. The list basically tells you 'your kernel *knows* about these CVEs as it was released after their release dates' but there is still some uncertainty for the user: OK, a CVE exists but is my CPU actually vulnerable? It may happen that when CVE releases we think that some CPUs (or a particular arch) are not vulnerable but we change our mind later. Also, all vulnerabilities are different as the severity depends a lot on the workload. The actions one need to undertake differ (update microcode, disable SMT, pin tasks to certain cores/threads, ...). The bottom line is I don't see an easy path for users. They either trust the source of their bits (e.g. distro), the infrastructure (hardware/virtual/cloud) and the default settings as being 'secure enough' or they have to study the details... -- Vitaly
