---------- Forwarded message ---------- From: Ahmed Soliman <ahmedsoliman0x666@xxxxxxxxx> Date: 6 July 2018 at 23:56 Subject: Re: How to change page permission from inside the kernel? To: Valdis Kletnieks <valdis.kletnieks@xxxxxx> >> Implementing some kernel protection against subset of rootkits that >> manipulates kernel static data (memory pages as well as their >> mappings) by having them enforced by hypervisor which is KVM in our > > Can you give an actual example of a case where *all* of the following are true? > I think there is a little bit confusion between the current R/O protection and what are we doing. so I will need to make some distinctions than I will answer all the questions. First here is a bunch of accronyms that I will use for convenience (pulled out KVM mmu.txt) pfn host page frame number hpa host physical address hva host virtual address gfn guest frame number gpa guest physical address gva guest virtual address To aviod confusion I will refer to the thing we are doing as ROE (read only enforcement) and it is alittle bit different from typical R/O protection in 2 aspects: - R/O is enforced by hardware but ROE is enforced by Hypervisor(still using Hardware protection but with hypervisor on top of it) - R/O can be enabled and disabled by the kernel at its own will but ROE can be enabled by the guest kernel and once enabled the hypervisor will make sure it never gets disabled again, so if even if the kernel decided to modify a paged that has ROE, it can't without a reboot. Here is a very simple description of how ROE is supposed to works (I am missing out some tiny details like remapping pages): The kernel passes a gva of a page to its hypervisor. The hypervisor converts gva to hva then places R/O on that page note that is 2 levels of paging we have the host page table with the appropriate R/O protection (including guest's own ROE requests) and the guest page table its own R/O protections that the guest can modify. There is another part that isn't designed yet to handle DMAs and registers with static content > 1) It's a page that's safe to make R/O out from under the code that uses that page. Yes because the guest kernel and hypervisor will coordinate together which pages of the _guest kernel_ memory should have this protections. of course the userspace process running the hypervisor (let it be qemu or any other software) do own the page and can do whatever it wishes with it. > 2) It's a kernel static data that's R/W (Hint: stuff known to be R/O is already set to R/O > at boot or module load time, so if it's R/W it probably *needs* to be that...) I think this question is from the confusion between R/W and ROE what we are simply going to do is that have every R/O page that will never be R/W again to also be ROE if the kernel is compiled with the right options (we will add that too) to be a kvm guest. > 3) the rootkit *is* able to screw with kernel pages, but somehow *is not* able to > disable your protection (remember, all it takes is one NOP or BRANCH opcode in > the right place). I can't think of a way to do it. having a rootkit being able to manipulate kernel pages can only be done though one of these ways none of which is considered a real threat (except for the DMA part thats why we are stil learning about current DMA memory protections and limitations): - VMM escape where it can then modify the paging protections in the host allocated memory that was assigned to the guest. - 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. - DMA and we are planning to do similar protection for DMA memory but still design in progress. other than these described above, I can't think of a way to manipulate a ROE protected page without a reboot. _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
