lkml.org 
[lkml]   [2018]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH V7 0/10] KVM: X86: Introducing ROE Protection Kernel Hardening
Hello,

> Given that writes to these areas should be exceptional occurrences,

No not in the case of partially protected page.

> I don't understand why this path needs to be optimized. To me it seems, a straight-
> forward userspace implementation with no additional code in the kernel achieves
> the same feature. Can you elaborate?

The performance hit I was talking about was when dealing with page with
mixed content, given that page is partially read only and partially writable.
The way this is handled is by emulating the writes from inside kvm, now if this
was done from host's userspace, then every write operating (a size of at most
1 cpu word I guess ?) will require switching from guest to kvm and then to host
userspace, which is major performance hit. I originally made it for protecting
guest's page table part that shouldn't be remapped ever. Since the page table
gets modified a lot, emulating the writes from host user space instead
of the kernel
would add an unnecessary overhead. Also it doesn't sound right to me
to place the
protection inside the page table when it can be placed inside the
virtualization EPT.

But aside from that, I think I was wrong about hinting that it is
simple when done from
user space, handling cases like THP and huge pages (which I did not support yet)
doesn't seam to be easy when done from user space and when doing Registers
ROE has some arch specific details. That's why I think it is better to
continue doing
it from KVM kernel module.

thanks,
Ahmed

\
 
 \ /
  Last update: 2018-12-13 17:02    [W:0.164 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site