[GTALUG] python sweetness — The mysterious case of the Linux Page Table

[Russell]

On January 4, 2018 12:08:16 AM EST, Dhaval Giani <dhaval.giani at gmail.com> wrote:
>Russell
>
>On Wed, Jan 3, 2018 at 11:59 PM Russell Reiter <rreiter91 at gmail.com>
>wrote:
>
>>
>>
>> On January 3, 2018 10:56:30 PM EST, Dhaval Giani
><dhaval.giani at gmail.com>
>> wrote:
>> >
>>
>https://googleprojectzero.blogspot.ca/2018/01/reading-privileged-memory-with-side.html
>> >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