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

[valdis.kletnieks at vt.edu]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180706/68713872/attachment-0001.sig>