Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<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

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.