Does anyone know what about VMs?
Should VMs/Guest OSes also be patched or it is enough to patch Hypervisor/Host OS only?

AFAIK this is a virtualisation issue known since june 2017.

What I understand it is a software issue which breaks certain barriers. So I suppose if understood so far correctly, as it is very complicated gibberish, you need to patch anything in question.

I assume when you host an insecure kernel inside, it should be able to read everything also.

I can not use the kernel 4.14 branch as it breaks certain USB functionality which I do need. I stick to an unpatched 4.9.x kernel. AFAIK only 4.14 will get a backport so far.

I'm quite sure, that this topic will get many posts and webpages from specialists soon which will cover any related questions in a reasonable time. I may suggest to wait a few days and search for that question online. Like blogs, guides and such

The seriousness of the impact will probably depend on the type of virtualisation: https://xenbits.xen.org/xsa/advisory-254.html

Not really looked into the response from other VMs/hypervisors.

The seriousness of this is not to be downplayed or "poo pooed"... it really doesn't help when every major security related bug gets a stupid domain name, brand name and logo...

this blog from Jul2017 appears to be almost identical to Meltdown/Spectre. not that hacking (looking for) kernel side channels is anything new, but appears to be pre-cursor if the work was continuing.

i dont have the low level expertise to compare, but doesnt this look like Meltdown-Spectre work?

see https://cyber.wtf/2017/07/28/negativ...rom-user-mode/

are these guys the sources of the findings? appears they were suspicious of the issue back in 2016.
https://cyber.wtf/

as for hyper v's, patching the host should fix the issue for all VM's. a VM still has a wedge provided by VM host to be able to handle the virtual mem of VM to host kernel mem space. the issue presents itself between host and cpu, not VM and cpu. a VM needs to step into host when trying to read kernel mem space. this is my understanding of it.

Certainly related, though my "low level of expertise" also means it takes quite some processing to understand even 10% of it. It's been brought up already this week in the big thread on this subject at the FreeBSD forums.

i read through the BSD forums.
and i get how the paging & exploits work, just not at the paper level those wtf guys are writing.

i find the whole embargo thing a big ball of BS. and apparently RH was writing fixes (somewhat) into patches that were covering other CVE's in 2017.

for me, its like heartbleed, a dark 0day, which means unable to detect the exploit unless "you" already knew what to look for. perhaps just another tool in the swiss army knife toolbox of the NSA and the like. i dont think any logs from say 2015 until mid-dec 2017 would show evidence of this vuln being exploited, unless folks were capturing CPU/mem operations down into log files. if you could find such it would prove to be a true dark 0day.

In almost every instance you need to patch any and all VM's.

I can only think of a few ways that may not need it. However, if you or your vm were to change and you didn't patch it, you could be left vulnerable.

If your motherboard company were to issue a cpu firmware solution then it may solve VM's issue.

My opinion would be that almost any patch for a physical machine should also be applied to a virtual machine.

why?
if a hyperV "wedge" handles all memory functions between guest and host, if you fix the wedge you should technically be able to handle any bad guest mem calls. presumably the kernel mem mappings have to be somewhere in host, perhaps even a logical mapping in host, but in all cases the guest has to step into host?

I don't see any logical reason one would refuse to update any system.

Part of the issue is how a processor works. As to how closely a VM connects to a physical processor is the question as to how secure it it.


I'd update all VM's despite some web site claiming that a few VM's are immune to this problem.

Anyone is free to do as they think is best. Not sure what one would gain by leaving the updates out.

Not trying to argue really, just saying I don't get the question of is it safe.

Possible/advisable with type 1 hypervisor (bare bones) but not with type 2.
for type 2 one would have host that lets guest see and modify microcode (kernel modification? which brings more complications) and vm software that would take advantage of these changes.

one reason might be performance. if the patch to host remediates the issues on all guests, then maybe (maybe) you do not get additional negative impact by putting some non-useful patch on guest VM.

how could a guest use such exploit code if the host itself does not allow such down to the hardware?