On Thu, Feb 13, 2020 at 03:48:16PM +0100, Christian Borntraeger wrote: > > > On 11.02.20 12:26, Will Deacon wrote: > > On Mon, Feb 10, 2020 at 06:27:04PM +0100, Christian Borntraeger wrote: > >> CC Marc Zyngier for KVM on ARM. Marc, see below. Will there be any > >> use for this on KVM/ARM in the future? > > > > I can't speak for Marc, but I can say that we're interested in something > > like this for potentially isolating VMs from a KVM host in Android. > > However, we've currently been working on the assumption that the memory > > removed from the host won't usually be touched by the host (i.e. no > > KSM or swapping out), so all we'd probably want at the moment is to be > > able to return an error back from arch_make_page_accessible(). Its return > > code is ignored in this patch :/ > > I think there are two ways at the moment. One is to keep the memory away from > Linux, e.g. by using the memory as device driver memory like kmalloc. This is > kind of what Power does. And I understand you as you want to follow that model > and do not want to use paging, file backing or so. Correct. > Our approach tries to fully integrate into the existing Linux LRU methods. > > Back to your approach. What happens when a malicious QEMU would start direct I/O > on such isolated memory? Is that what you meant by adding error checking in these > hooks. For the gup.c code returning an error seems straightforward. Yes, it would be nice if the host could avoid even trying to access the page if it's inaccessible and so returning an error from arch_make_page_accessible() would be a good way to achieve that. If the access goes ahead anyway, then the hypervisor will have to handle the fault and effectively ignore the host access (writes will be lost, reads will return poison). > I have no idea what to do in writeback. When somebody managed to trigger writeback > on such a page, it already seems too late. For now, we could just have a BUG_ON(). Will
