On Tue, Jul 19 2022, Peter Collingbourne <pcc@xxxxxxxxxx> wrote: > On Tue, Jul 19, 2022 at 7:50 AM Cornelia Huck <cohuck@xxxxxxxxxx> wrote: >> >> On Fri, Jul 08 2022, Peter Collingbourne <pcc@xxxxxxxxxx> wrote: >> >> > Hi, >> > >> > This patch series contains a proposed extension to pKVM that allows MTE >> > to be exposed to the protected guests. It is based on the base pKVM >> > series previously sent to the list [1] and later rebased to 5.19-rc3 >> > and uploaded to [2]. >> > >> > This series takes precautions against host compromise of the guests >> > via direct access to their tag storage, by preventing the host from >> > accessing the tag storage via stage 2 page tables. The device tree >> > must describe the physical memory address of the tag storage, if any, >> > and the memory nodes must declare that the tag storage location is >> > described. Otherwise, the MTE feature is disabled in protected guests. >> > >> > Now that we can easily do so, we also prevent the host from accessing >> > any unmapped reserved-memory regions without a driver, as the host >> > has no business accessing that memory. >> > >> > A proposed extension to the devicetree specification is available at >> > [3], a patched version of QEMU that produces the required device tree >> > nodes is available at [4] and a patched version of the crosvm hypervisor >> > that enables MTE is available at [5]. >> >> I'm unsure how this is supposed to work with QEMU + KVM, as your QEMU >> patch adds mte-alloc properties to regions that are exposed as a >> separate address space (which will not work with KVM). Is the magic in >> that new shared section? > > Hi Cornelia, > > The intent is that the mte-alloc property may be set on memory whose > allocation tag storage is not directly accessible via physical memory, > since in this case there is no need for the hypervisor to do anything > to protect allocation tag storage before exposing MTE to guests. In > the case of QEMU + KVM, I would expect the emulated system to not > expose the allocation tag storage directly, in which case it would be > able to set mte-alloc on all memory nodes without further action, > exactly as my patch implements for TCG. With the interface as > proposed, QEMU would need to reject the mte-shared-alloc option when > KVM is enabled, as there is currently no mechanism for KVM-accelerated > virtualized tag storage. Ok, that makes sense. > > Note that these properties are only relevant for guest kernels running > under an emulated EL2 in which pKVM could conceivably run, which means > that the host would need to implement FEAT_NV2. As far as I know there > is currently no support for NV2 neither in QEMU TCG nor in the Linux > kernel, and I'm unaware of any available hardware that supports both > NV2 and MTE, so it'll be a while before any of this becomes relevant. Nod. I'm mostly interested because I wanted to figure out how this feature might interact with enabling MTE for QEMU+KVM. I'll keep it in mind. Thanks!
