[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
