* Ahmed Abd El Mawgood <ahmedsoliman0x666@xxxxxxxxx> 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