Fwd: How to change page permission from inside the kernel?

[Ahmed Soliman]

---------- Forwarded message ----------
From: Ahmed Soliman <ahmedsoliman0x666 at gmail.com>
Date: 6 July 2018 at 23:56
Subject: Re: How to change page permission from inside the kernel?
To: Valdis Kletnieks <valdis.kletnieks at vt.edu>


>> 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.