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: <BN9PR11MB5276478406FDC2119A8EBD568C27A@BN9PR11MB5276.namprd11.prod.outlook.com>
Date:   Tue, 27 Jun 2023 08:10:48 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     Jason Gunthorpe <jgg@...dia.com>,
        Robin Murphy <robin.murphy@....com>
CC:     Lu Baolu <baolu.lu@...ux.intel.com>,
        Joerg Roedel <joro@...tes.org>,
        "Will Deacon" <will@...nel.org>,
        Alex Williamson <alex.williamson@...hat.com>,
        Nicolin Chen <nicolinc@...dia.com>,
        "iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 1/2] iommu: Prevent RESV_DIRECT devices from blocking
 domains

> From: Jason Gunthorpe <jgg@...dia.com>
> Sent: Monday, June 19, 2023 11:30 PM
> 
> On Mon, Jun 19, 2023 at 03:20:30PM +0100, Robin Murphy wrote:
> 
> > so if the only time they're used is when the IOMMU driver has
> > already had a catastrophic internal failure such that we decide to
> > declare the device toasted and deliberately put it into an unusable
> > state, blocking its reserved regions doesn't seem like a big deal.
> 
> I think we should discuss then when we get to actually implementing
> the error recovery flow we want. I do like blocking in general for the
> reasons you give, and that was my first plan.. But if the BIOS will
> crash or something if we don't do the reserved region maps that isn't
> so good either. IDK would like to hear from the people using this BIOS
> feature.
> 

The only devices with RMRR which I'm aware of on Intel platforms are
GPU and USB. However they are all RESV_DIRECT_RELAXABLE type.

Here is one reference from the Xen hypervisor. It has a concept called
quarantine domain (similar to blocking domain) when a device is
de-assigned w/o an owner. The quarantine domain has no mappings
except the ones identity-mapped for RMRR types. I'm not sure whether
they observed real examples of RMRR devices which are not GPU/USB.

I guess the reason of not going fully identity or fully blocked is from
the same worry that the BIOS may go insane while Xen still wants to
quarantine the device as much as possible.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ