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

[valdis.kletnieks at vt.edu]

On Sat, 07 Jul 2018 01:31:45 +0200, Ahmed Soliman said:

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

Did you actually *check* that this will happen, or will KVM just say "Oh,
the VM changed their mapping" and go with the new mapping?

In other words, *prove* that they won't make it to the TLB - and while
you're at it, deal with the case where the TLB isn't the source of the
mapping (which is the case on every single TLB miss, where it has to
go consult the page tables for the mapping.  And given Intel chipset's
over-exuberant approach to speculative execution and pipelining, there's
a good chance that the instant the proper mapping is found from the page
tables, it's used to make the actual memory reference, while the TLB gets
updated after the fact.  Plus, a lot of that happens in hardware, without
KVM getting a chance to inspect things.

(I don't actually know how the TLB works - but the point is you'll have to go
reading the Intel and AMD processor manuals to get that part right...)

While you're reading it, look for the implications of the "load/store bypassing
cache" instructions - can you force a surprise by storing directly to main memory
for a page table entry that is in L3 cache on the other socket?  (Note that the
kernel has memory barriers all over the place to avoid such surprises - but
examine the converse, where malware intentionally doesn't use a barrier so
there's inconsistency between cache, memory, and registers)

I take it you assuming more special-case checking which will require patches
to the KVM side (at a minimum, the KVM needs to keep a list of pages that
should not be changed, and check that at every required point?

Bonus points for properly handling the case where KVM pages an ROE page
out of real memory, and then pages it back into a different page frame (unless
you want to claim it works like mlock() - at which point you need to consider
the implications of a guest permanently mlock()ing up to 16M or 32M or even more).

You might want to stop and ask yourself why the people who did all the W^X
code for the kernel didn't extend it another step and add your ROE scheme.. ;)




-------------- 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/79016ee9/attachment.sig>