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] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yz1vF7B0FLvLVvE0@nvidia.com>
Date:   Wed, 5 Oct 2022 08:48:39 -0300
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Niklas Schnelle <schnelle@...ux.ibm.com>
Cc:     Matthew Rosato <mjrosato@...ux.ibm.com>,
        Pierre Morel <pmorel@...ux.ibm.com>, iommu@...ts.linux.dev,
        linux-s390@...r.kernel.org, borntraeger@...ux.ibm.com,
        hca@...ux.ibm.com, gor@...ux.ibm.com,
        gerald.schaefer@...ux.ibm.com, agordeev@...ux.ibm.com,
        svens@...ux.ibm.com, joro@...tes.org, will@...nel.org,
        robin.murphy@....com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 1/5] iommu/s390: Fix duplicate domain attachments

On Wed, Oct 05, 2022 at 09:58:58AM +0200, Niklas Schnelle wrote:

> A failed aperture test leaving the IOAT registered would indeed be bad.
> I guess I focused too much on the failure scenarios at the state after
> these patches where this can't happen. I think this would leave us in a
> bad state because zpci_register_ioat() succeeded with the domain's DMA
> table but we won't have attached leading to the wrong decisions in
> recovery paths (see below).

Domain attach should either completely move to the new domain and
succeed, or it should leave everything as is and fail.

So it looks OK to me.

> Recovery (via zpci_hot_reset_device()) should then be able to deal with
> these situations as long as zdev->dma_table matches the IOAT
> registration state.

If you are doing reset the s390 driver should keep track of what
domain is supposed to be attached and fix it when the reset is
completed. In this case it should not fail attach here for the
mandatory success domain types.

The core code does not reasonably handle failures from this routine,
it must be avoided if you want it to be robust.

Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ