Hello,
> > 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?
I was doing some benchmarking to figure out the overhead introduce
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
> achie
Hello,
> Do you have patches that enable usage of ROE in the kernel?
> Alternatively you can write testcases in tools/testing/selftests/kvm to
> test how guests should use it.
As for now ROE isn't integrated yet into the kernel, I did have some
tests I will
have them in selftests/kvm in the next
Hello Igor,
> This is very interesting, because it seems a very good match to the work
> I'm doing, for supporting the creation of more targets for protection:
>
> https://www.openwall.com/lists/kernel-hardening/2018/10/23/3
>
> In my case the protection would extend also to write-rate type of data
On Mon, 29 Oct 2018 at 18:42, Sean Christopherson
wrote:
>
> On Fri, Oct 26, 2018 at 05:12:19PM +0200, Ahmed Abd El Mawgood wrote:
> > Following up with my previous threads on KVM assisted Anti rootkit
> > protections.
>
> All of the changelogs in this series need to be rewritten to adhere to
> Do
On Mon, 29 Oct 2018 at 08:46, Ingo Molnar wrote:
>
>
> * Ahmed Abd El Mawgood wrote:
>
> > This is the 5th version which is 4th version with minor fixes. ROE is a
> > hypercall that enables host operating system to restrict guest's access to
> > its
> > own memory. This will provide a hardening
