linux-kernel - Re: [PATCH][RFC] PCI: Add "pci=blacklist_dev=" parameter to blacklist specific devices

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: <CANTgghm_ZC29PF3m-7u74RWU0LiKOcodf-CqhSzsQPdu05qrJg@mail.gmail.com>
Date:   Tue, 28 Jan 2020 17:32:07 -0800
From:   Dan Williams <dan.j.williams.korg@...il.com>
To:     Bjorn Helgaas <helgaas@...nel.org>
Cc:     Chen Yu <yu.c.chen@...el.com>, linux-pci@...r.kernel.org,
        Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, Len Brown <lenb@...nel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>
Subject: Re: [PATCH][RFC] PCI: Add "pci=blacklist_dev=" parameter to blacklist
 specific devices

On Fri, Jan 24, 2020 at 1:01 PM Bjorn Helgaas <helgaas@...nel.org> wrote:
>
> On Fri, Jan 24, 2020 at 10:42:48PM +0800, Chen Yu wrote:
> > It was found that on some platforms the bogus pci device might bring
> > troubles to the system. For example, on a MacBookPro the system could
> > not be power off or suspended due to internal pci resource confliction
> > between bogus pci device and [io 0x1804]. Another case is that, once
> > resumed from hibernation on a VM, the pci config space of a pci device
> > is corrupt.
> >
> > To narrow down and benefit future debugging for such kind of issues,
> > introduce the command line blacklist_dev=<vendor:device_id>> to blacklist
> > such pci devices thus they will not be scanned thus not visible after
> > bootup. For example,
> >
> >  pci.blacklist_dev=8086:293e
> >
> > forbid the audio device to be exposed to the OS.
>
> I'm not really a fan of this.  I'd rather see some details about what
> the problem is so we can actually fix it.
>
> Ignoring the device doesn't mean the device is removed or even
> inactive.  It may still be consuming address space that we need to
> avoid.
>
> Can you point us to bug reports about the issues you mentioned?

I'm not sure which issues Chen Yu is referring to, but a proposal like
has come up before [1], and didn't go anywhere.

I think this is useful to people doing new / pre-release hardware
bring up, but it's unlikely that such hardware makes it into a
production to make this feature useful upstream. Hardware bring-up
efforts can just use local hacks to workaround problems, if broken
hardware actually makes it into production it needs precise quirks to
be developed/applied.

[1]: http://lore.kernel.org/r/1506544822-2632-2-git-send-email-jonathan.derrick@intel.com