On Fri, 06 Jul 2018 23:59:30 +0200, Ahmed Soliman said:
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.
So in essence, you're willing to *permanently* remove pages from the usable set in the guest? (Usable as in "able to write to it"). What happens after you've been up for 3 weeks and you're running out of usable pages? How does this interact with ballooning? 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) Bonus points for explaining the hypervisor/guest interface needed to make this work.
Can you give an actual example of a case where *all* of the following are true? 1) It's a page that's safe to make R/O out from under the code that uses that page. 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...) 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).
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....
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
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. 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.
other than these described above, I can't think of a way to manipulate a ROE protected page without a reboot.
You missed the point - your protection can be bypassed without manipulating a ROE page.