linux-kernel - Re: [PATCH v1 1/2] PCI: PM: Avoid leaving devices in D0-uninitialized in pci_power

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: <YlAt5he5B1SlORMh@lahna>
Date:   Fri, 8 Apr 2022 15:43:18 +0300
From:   Mika Westerberg <mika.westerberg@...ux.intel.com>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Linux PCI <linux-pci@...r.kernel.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Bjorn Helgaas <helgaas@...nel.org>
Subject: Re: [PATCH v1 1/2] PCI: PM: Avoid leaving devices in
 D0-uninitialized in pci_power_up()

Hi Rafael,

On Thu, Apr 07, 2022 at 09:01:59PM +0200, Rafael J. Wysocki wrote:
> On Tue, Apr 5, 2022 at 1:45 PM Mika Westerberg
> <mika.westerberg@...ux.intel.com> wrote:
> >
> > On Mon, Apr 04, 2022 at 05:41:13PM +0200, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> > >
> > > In theory, pci_power_up() may leave a device in D0-uninitialized
> > > during a transition from D3cold to D0.
> > >
> > > Say, a PCIe device depending on some ACPI power resources is put into
> > > D3cold, so the power resources in question are all turned off.  Then,
> > > pci_power_up() is called to put it into D0.
> > >
> > > It first calls pci_platform_power_transition() which invokes
> > > platform_pci_set_power_state() to turn on the ACPI power resources
> > > depended on by the device and, if that is successful, it calls
> > > pci_update_current_state() to update the current_state field of
> > > the PCI device object.  If the device's configuration space is
> > > accessible at this point, which is the case if
> > > platform_pci_set_power_state() leaves it in D0-uninitialized (and
> > > there's nothing to prevent it from doing so), current_state will be
> > > set to PCI_D0 and the pci_raw_set_power_state() called subsequently
> > > will notice that the device is in D0 already and do nothing.
> > > However, that is not correct, because it may be still necessary to
> > > restore the device's BARs at this point.
> > >
> > > To address this issue, set current_state temporarily to PCI_D3hot
> > > in the cases in which pci_raw_set_power_state() may need to do more
> > > than just changing the power state of the device.
> > >
> > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> >
> > Reviewed-by: Mika Westerberg <mika.westerberg@...ux.intel.com>
> 
> Thanks, but on second thought, I'm not sure if this is the best way to
> address the issue.
> 
> Basically, pci_power_up() is called in two places, in
> pci_set_power_state() (for the transitions to D0) and in
> pci_pm_default_resume_early().  In the latter case,
> pci_restore_state() is called right after it and that covers BARs
> restoration, so nothing more needs to be done in that case.

I see.

> This means that pci_set_power_state() is the only place needing to
> restore the BARs when going into D0 from D3hot or deeper and it is
> better to move BARs restoration directly into it.  I'll update the
> series accordingly and resend.

Okay sounds good.

> I also think that the mandatory delay is not needed at all when
> pci_raw_set_power_state() is called for transitions D3cold -> D0,
> because in that case either the device has been powered up via
> platform_pci_set_power_state(), or via the bridge resume which takes
> the delay into account.

I agree.