> What happens after you've been up for 3 weeks and you're running out of > usable pages? That can't happen, it is my mistake missing some details, this is for only protecting Kernel Pages, Pages that are hold code or static data that is created once and assumed to be there for ever, like kernel code section as well as any static data. However this isn't to be used on any user space memory (from the guest's perspective) process because processes start and end. > How does this interact with ballooning? I haven't thought about this _yet_. Ballooning is complex, I can start simple and expand later to support all of the current KVM features, Also I am not even sure if ballooning is considered related or not because If Kernel pages can be part of the Balloon then I would that when they are copied they are copied with the right permissions and this is done completely independent of gva and gpa. > What ways can malware in the guest use this to DoS or otherwise break > the kernel? (Setting the page that contains the 'struct proc' for PID 1 would > be amusing, and I'm sure there's plenty of amusement with race conditions to > make other kernel threads fail when they encounter a page they were expecting > to be R/W) I should state that hypercalls are done only from kernel mode (I am not sure about KVM but t is the case in Xen and if KVM allows user mode hypercall we can check for this specific one to be created from kernel mode it is easy) In this case, worrying about a if kernel code can Dos the kernel via ROE is relatively meaningless because there are already many other ways to break the system once one have kernel mode access. However If you mean that this way guest kernel can break host kernel, then this is a different story, it will not be possible because of kvm MMU is designed to make guest not being able to access memory that host never allocated to it. So we are replacing some way to hide a rootkit in a kernel by a way to crash the kernel (given that there are many ways to do both). I think in most cases it would be rather better if the guest OS crashes (thus indicating that something is wrong) rather than have a rootkit working silently. > Well actually, what I was looking for was a description of the rootkit that you're > defending against - where it lives, what kernel data it attacks, and so on.... What about some real example? I just found this one from google https://github.com/nurupo/rootkit/blob/master/rootkit.c While I aggree that the rootkit will make its way into the kernel but it _will not_ be able to achieve all of its functionalities. anything that uses "_asm_hook_patch" function should fail because the system call tables is protected. I am not sure if ROE will prevent other parts of this rootkit from working or not but here is one :). But I am pretty sure that there are other static data that can be abused by rootkits inside the kernel that should rather be protected. > If you're unable to explain the threat you're trying to guard against, > you're going to be unable to guard against it properly. Well I kinda had one, but you never asked for it. We assume that the attacker is running in kernel mode and his goal is to alter static data/ code section in the kernel for whatever reason with out a reboot. if reboot is needed well it can be trivially done by replacing the whole kernel with a new one including any malicious code and then faulting the running kernel thus forcing a reboot or even. Also attacks that involve dynamic data (except for the page table) is out of scope including attacks that involve any block device. We plan to handle memory either that is accessed either via CPU or DMA as well as privileged registers that are set once and never modify again. We haven't agreed on how an unauthorized write to ROE protected memory would be handled but worst case it can lead to crashing the guest OS, Crashing the Host OS is considered a big breach and it shouldn't be possible. Although this thing isn't really part of threat model but it is kinda of a motto that crash is better than rootkit. because once it happens we will know it is there and the indecent can be thoroughly inspected. > Hint: Your protection is trivially bypassed by simply *replacing* the > protected page. The attacker snarfs up a R/W 4K page, copies the > protected page to the new page, injects whatever malware bits they > find amusing, and change the virtual memory pointer tables so this > new page frame is referenced by the virtual address of the old page. > If the hypervisor even notices the swap, all it will probably do is make > the new page R/O - but that matters not because it's already compromised. I think I did explain how we handled this: >>- Screwing the page table itself which is not static data. but parts >>of the details I am missing is that hypervisor will keep track of all >>guest page number, guest frame number of all ROE protected pages and >>make sure that it is never the wrong mapping when updating the TLB. > You missed the point - your protection can be bypassed without manipulating > a ROE page. Changing the virtual memory pointer table is ok but again these memory mappings will never make it to the TLB and will be caught during by KVM MMU because it will explicitly check both gva and gpa when resolving a gva so perhaps this will put the guest kernel in some inconsistent state (again crashing the guest is considered much much better than a rootkit running in silence). _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
