linux-kernel - Re: [PATCH 1/1] vfio/type1: Respect IOMMU reserved regions in vfio_test_domain

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <d2e13511df130c3d4824a78ed0aa24c49e7137e5.camel@linux.ibm.com>
Date:   Wed, 04 Jan 2023 14:08:42 +0100
From:   Niklas Schnelle <schnelle@...ux.ibm.com>
To:     Jason Gunthorpe <jgg@...pe.ca>
Cc:     Alex Williamson <alex.williamson@...hat.com>,
        Cornelia Huck <cohuck@...hat.com>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-s390@...r.kernel.org,
        Matthew Rosato <mjrosato@...ux.ibm.com>,
        Pierre Morel <pmorel@...ux.ibm.com>,
        Christian Bornträger 
        <borntraeger@...ux.ibm.com>
Subject: Re: [PATCH 1/1] vfio/type1: Respect IOMMU reserved regions in
 vfio_test_domain_fgsp()

On Wed, 2023-01-04 at 08:16 -0400, Jason Gunthorpe wrote:
> On Wed, Jan 04, 2023 at 10:52:55AM +0100, Niklas Schnelle wrote:
> 
> > The problem manifests only with ISM devices which are a special s390
> > virtual PCI device that is implemented in the machine hypervisor. This
> > device is used for high speed cross-LPAR (Logical Partition)
> > communication, basically it allows two LPARs that previously exchanged
> > an authentication token to memcpy between their partitioned memory
> > using the virtual device. For copying a receiving LPAR will IOMMU map a
> > region of memory for the ISM device that it will allow DMAing into
> > (memcpy by the hypervisor). All other regions remain unmapped and thus
> > inaccessible. In preparation the device  emulation in the machine
> > hypervisor intercepts the IOTLB flush and looks at the IOMMU
> > translation tables performing e.g. size and alignment checks I presume,
> > one of these checks against the start/end DMA boundaries. This check
> > fails which leads to the virtual ISM device being put into an error
> > state. Being in an error state it then fails to be initialized by the
> > guest driver later on.
> 
> You could rephrase this as saying that the S390 map operation doesn't
> check for bounds so mapping in a reserved region doesn't fail, but
> errors the HW.
> 
> Which seems reasonable to me
> 
> Jason

Kind of yes, before the recent IOMMU changes the IOMMU code did check
on map failing early but now handles the limits via reserved regions.
The IOMMU hardware would only check the limits once an actual DMA uses
them but of course no DMA will be triggered for this test mapping. For
this specific virtual device though there is an extra check as part of
an intercepted IOTLB flush (RPCIT instruction in S390).