Date: Mon, 29 Oct 2018 07:46:40 +0100 From: Ingo Molnar <mingo@...nel.org> To: Ahmed Abd El Mawgood <ahmedsoliman0x666@...il.com> Cc: Paolo Bonzini <pbonzini@...hat.com>, rkrcmar@...hat.com, Jonathan Corbet <corbet@....net>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, hpa@...or.com, x86@...nel.org, kvm@...r.kernel.org, linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, ovich00@...il.com, kernel-hardening@...ts.openwall.com, nigel.edwards@....com, Boris Lukashev <blukashev@...pervictus.com>, Hossam Hassan <7ossam9063@...il.com>, Ahmed Lotfy <A7med.lotfey@...il.com> Subject: Re: [PATCH V5 0/5] KVM: X86: Introducing ROE Protection Kernel Hardening * Ahmed Abd El Mawgood <ahmedsoliman0x666@...il.com> 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 mechanism that can be used to stop > rootkits from manipulating kernel static data structures and code. Once a memory > region is protected the guest kernel can't even request undoing the protection. > > Memory protected by ROE should be non-swapable because even if the ROE protected > page got swapped out, It won't be possible to write anything in its place. > > ROE hypercall should be capable of either protecting a whole memory frame or > parts of it. With these two, it should be possible for guest kernel to protect > its memory and all the page table entries for that memory inside the page table. > I am still not sure whether this should be part of ROE job or the guest's job. > > > The reason why it would be better to implement this from inside kvm: instead of > (host) user space is the need to access SPTEs to modify the permissions, while > mprotect() from user space can work in theory. It will become a big performance > hit to vmexit and switch to user space mode on each fault, on the other hand, > having the permission handled by EPT should make some remarkable performance > gain. > > Our model assumes that an attacker got full root access to a running guest and > his goal is to manipulate kernel code/data (hook syscalls, overwrite IDT ..etc). > > There is future work in progress to also put some sort of protection on the page > table register CR3 and other critical registers that can be intercepted by KVM. > This way it won't be possible for an attacker to manipulate any part of the > guests page table. BTW., transparent detection and trapping of attacks would also be nice: if ROE is active and something running on the guest still attempts to change the pagetables, the guest should be frozen and a syslog warning on the hypervisor side should be printed? Also, the feature should probably be 'default y' to help spread it on the distro side. It's opt-in functionality from the guest side anyway, so there's no real cost on the host side other than some minor resident memory. Thanks, Ingo
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.