On January 4, 2018 12:08:16 AM EST, Dhaval Giani <dhaval.giani@gmail.com> wrote:
Russell
On Wed, Jan 3, 2018 at 11:59 PM Russell Reiter <rreiter91@gmail.com> wrote:
On January 3, 2018 10:56:30 PM EST, Dhaval Giani
<dhaval.giani@gmail.com>
wrote:
https://googleprojectzero.blogspot.ca/2018/01/reading-privileged-memory-with...
gives the gory details
At this point, I cannot stress on how important it is to update your systems as soon as your distribution ships them. I am hoping this remains to be a once in a lifetime event.
I admire your optimism. To me it looks like this is a kind of example of feeping creaturisim in hypervisor's; not necessarily an easy patch.
I am unsure what you are implying. This is a hardware issue which has been fixed in software. There are
There currently are patches which address a number of security issues. No software fixes yet tho. A fix implies a final solution has been implemented and the problem is no longer an issue. Clearly not the case here. exploits out already that I am seeing able
to run through your web browser. This is serious stuff. Also unsure what this has to do with hypervisors apart from them also needing to mitigate this exploit.
Semantically, a hypervisor is the kernel supervisor of the OS. So it is a core computational element in need of basic patching. (in this case) I think you are confusing a "virtual" hypervisor with a native "bare metal" hypervisor. They have the appearance of being the same thing ... only they are different.
The idea of the necessity of some sort of kernel isolation has been
around
for quite a while. In part as a response to the ease with which userland interpreters can polute kernelspace.
https://lwn.net/Articles/39283/
I've read that some of the proposed solutions could add as much as a 30% operational overhead. Not much of an issue for average home users but for enterprise this could be a real game changer.
The 30% overhead is for a pathological case. A 5-10%
overhead is more
likely. And do you honestly think that upstream is not going to work on getting that overhead down?
For a problem like this one and given it's scope and complexity, it is premature to downplay the core and it's overhead issue. This is not like in the movies where the producer says, it's not a problem, we can fix it in POST. This is a preproduction issue with the actors. If you want to get all biological about pathology. The pathology of this problem is far from well understood. Finding the proper namespace is important. At Linus's request KAISER has been dropped. However fuckwit (Forcefully Unmap Complete Kernel With Interrupt Trampolines, ) has not been adopted, by most people anyway. https://lkml.org/lkml/2017/12/4/709
Dhaval
-- Russell