On Fri, Nov 12, 2021 at 1:38 PM Dave Hansen <dave.hansen@xxxxxxxxx> wrote: > > On 11/12/21 1:30 PM, Marc Orr wrote: > > In this proposal, consider a guest driver instructing a device to DMA > > write a 1 GB memory buffer. A well-behaved guest driver will ensure > > that the entire 1 GB is marked shared. But what about a malicious or > > buggy guest? Let's assume a bad guest driver instructs the device to > > write guest private memory. > > > > So now, the virtual device, which might be implemented as some host > > side process, needs to (1) check and lock all 4k constituent RMP > > entries (so they're not converted to private while the DMA write is > > taking palce), (2) write the 1 GB buffer, and (3) unlock all 4 k > > constituent RMP entries? If I'm understanding this correctly, then the > > synchronization will be prohibitively expensive. > > Are you taking about a 1GB *mapping* here? As in, something us using a > 1GB page table entry to map the 1GB memory buffer? That was the only > case where I knew we needed coordination between neighbor RMP entries > and host memory accesses. > > That 1GB problem _should_ be impossible. I thought we settled on > disabling hugetlbfs and fracturing the whole of the direct map down to 4k. No. I was trying to give an example where a host-side process is virtualizing a DMA write over a large buffer that consists of a lot of 4k or 2MB RMP entries. I picked 1 GB as an arbitrary example.
