LinuxQuestions.org
Latest LQ Deal: Linux Power User Bundle
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Reply
  Search this Thread
Old 01-04-2018, 08:23 PM   #1
czezz
Member
 
Registered: Nov 2004
Distribution: Slackware/Solaris
Posts: 764

Rep: Reputation: 39
Meltdown, Spectre vs Virtual Machine (Guest OS)


Does anyone know what about VMs?
Should VMs/Guest OSes also be patched or it is enough to patch Hypervisor/Host OS only?
 
Old 01-05-2018, 12:32 AM   #2
_roman_
Member
 
Registered: Dec 2017
Location: _Austro_Bavaria_
Distribution: gentoo / linux mint
Posts: 433

Rep: Reputation: 28
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

Last edited by _roman_; 01-05-2018 at 12:34 AM.
 
Old 01-05-2018, 07:53 AM   #3
cynwulf
Senior Member
 
Registered: Apr 2005
Posts: 2,157
Blog Entries: 5

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

Quote:
Xen guests may be able to infer the contents of arbitrary host memory,
including memory assigned to other guests.
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...
 
Old 01-05-2018, 02:04 PM   #4
Linux_Kidd
Member
 
Registered: Jan 2006
Location: USA
Posts: 579

Rep: Reputation: 62
microcode guru's

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.

Last edited by Linux_Kidd; 01-05-2018 at 02:18 PM.
 
Old 01-05-2018, 06:13 PM   #5
cynwulf
Senior Member
 
Registered: Apr 2005
Posts: 2,157
Blog Entries: 5

Rep: Reputation: 1212Reputation: 1212Reputation: 1212Reputation: 1212Reputation: 1212Reputation: 1212Reputation: 1212Reputation: 1212Reputation: 1212
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.
 
Old 01-05-2018, 08:43 PM   #6
Linux_Kidd
Member
 
Registered: Jan 2006
Location: USA
Posts: 579

Rep: Reputation: 62
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.
 
Old 01-05-2018, 10:18 PM   #7
jefro
Moderator
 
Registered: Mar 2008
Posts: 18,572

Rep: Reputation: 2781Reputation: 2781Reputation: 2781Reputation: 2781Reputation: 2781Reputation: 2781Reputation: 2781Reputation: 2781Reputation: 2781Reputation: 2781Reputation: 2781
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.

Last edited by jefro; 01-05-2018 at 10:20 PM.
 
Old 01-11-2018, 03:31 PM   #8
Linux_Kidd
Member
 
Registered: Jan 2006
Location: USA
Posts: 579

Rep: Reputation: 62
Quote:
Originally Posted by jefro View Post
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?
 
Old 01-11-2018, 08:14 PM   #9
jefro
Moderator
 
Registered: Mar 2008
Posts: 18,572

Rep: Reputation: 2781Reputation: 2781Reputation: 2781Reputation: 2781Reputation: 2781Reputation: 2781Reputation: 2781Reputation: 2781Reputation: 2781Reputation: 2781Reputation: 2781
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.

Last edited by jefro; 01-11-2018 at 08:16 PM.
 
Old 01-12-2018, 08:41 AM   #10
Aeterna
Member
 
Registered: Aug 2017
Location: Terra Mater
Distribution: VM Host: Slackware-current, VM Guests: Artix, CRUX, FreeBSD, Funtoo, HardenedBSD, OpenIndiana
Posts: 121

Rep: Reputation: Disabled
Quote:
Originally Posted by jefro View Post
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.
 
Old 01-13-2018, 10:20 PM   #11
Linux_Kidd
Member
 
Registered: Jan 2006
Location: USA
Posts: 579

Rep: Reputation: 62
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?
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Vulnerabilities such as Meltdown and Spectre caseyl Linux - Security 7 01-22-2018 10:14 PM
Spectre and Meltdown are massive security flaws that affect almost every PC on Earth. Here’s what you need to know jeremy Linux - News 5 01-08-2018 09:33 AM
LXer: Canonical Will Soon Patch all Supported Ubuntu Releases Against Meltdown/Spectre LXer Syndicated Linux News 0 01-04-2018 04:10 PM
OpenBSD devs worked on Meltdown/Spectre fixes eleven years ago YesItsMe *BSD 2 01-04-2018 10:56 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 03:06 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration