Date: Fri, 20 Jul 2018 00:59:43 +0200 From: Jann Horn <jannh@...gle.com> To: ahmedsoliman0x666@...il.com Cc: kvm@...r.kernel.org, Kernel Hardening <kernel-hardening@...ts.openwall.com>, virtualization@...ts.linux-foundation.org, linux-doc@...r.kernel.org, "the arch/x86 maintainers" <x86@...nel.org>, Paolo Bonzini <pbonzini@...hat.com>, Radim Krčmář <rkrcmar@...hat.com>, Jonathan Corbet <corbet@....net>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, "H . Peter Anvin" <hpa@...or.com>, Kees Cook <keescook@...omium.org>, Ard Biesheuvel <ard.biesheuvel@...aro.org>, david@...hat.com, Boris Lukashev <blukashev@...pervictus.com>, david.vrabel@...anix.com, nigel.edwards@....com, riel@...riel.com Subject: Re: [PATCH 3/3] [RFC V3] KVM: X86: Adding skeleton for Memory ROE On Thu, Jul 19, 2018 at 11:40 PM Ahmed Abd El Mawgood <ahmedsoliman0x666@...il.com> wrote: > This patch introduces a hypercall implemented for X86 that can assist > against subset of kernel rootkits, it works by place readonly protection in > shadow PTE. The end result protection is also kept in a bitmap for each > kvm_memory_slot and is used as reference when updating SPTEs. The whole > goal is to protect the guest kernel static data from modification if > attacker is running from guest ring 0, for this reason there is no > hypercall to revert effect of Memory ROE hypercall. This patch doesn't > implement integrity check on guest TLB so obvious attack on the current > implementation will involve guest virtual address -> guest physical > address remapping, but there are plans to fix that. Why are you implementing this in the kernel, instead of doing it in host userspace?
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ