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.. ;)
Attachment:
pgpAxzGJtDqTC.pgp
Description: PGP signature
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
