linux-kernel - Re: [PATCH V3 2/2] Xen/PCIback: Implement PCI flr/slot/bus reset with 'reset' SysFS attribute

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 for Android: free password hash cracker in your pocket

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

Date:   Mon, 18 Dec 2017 00:36:18 -0700
From:   "Jan Beulich" <JBeulich@...e.com>
To:     "Govinda Tatti" <Govinda.Tatti@...cle.COM>
Cc:     <roger.pau@...rix.com>, <bhelgaas@...gle.com>,
        <xen-devel@...ts.xenproject.org>, <boris.ostrovsky@...cle.COM>,
        <konrad.wilk@...cle.COM>, "Juergen Gross" <jgross@...e.com>,
        <linux-kernel@...r.kernel.org>, <linux-pci@...r.kernel.org>
Subject: Re: [PATCH V3 2/2] Xen/PCIback: Implement PCI flr/slot/bus
 reset with 'reset' SysFS attribute

>>> On 15.12.17 at 20:52, <Govinda.Tatti@...cle.COM> wrote:
>>>> +static int pcistub_device_reset(struct pci_dev *dev)
>>>> +{
>>>> +	struct xen_pcibk_dev_data *dev_data;
>>>> +	bool slot = false, bus = false;
>>>> +	struct pcistub_args arg = {};
>>>> +
>>>> +	if (!dev)
>>>> +		return -EINVAL;
>>>> +
>>>> +	dev_dbg(&dev->dev, "[%s]\n", __func__);
>>>> +
>>>> +	/* First check and try FLR */
>>>> +	if (pcie_has_flr(dev)) {
>>>> +		dev_dbg(&dev->dev, "resetting %s device using FLR\n",
>>>> +			pci_name(dev));
>>>> +		pcie_flr(dev);
>>> The lack of error check here puzzled me, but I see the function
>>> indeed returns void right now. I think the prereq patch should
>>> change this along with exporting the function - you really don't
>>> want the device to be handed to a guest when the FLR timed
>>> out.
>> We will change pcie_flr() to return error code. I will make this change
>> in the next version of this patch.
> I exchanged some emails with Bjorn/Christoph and it looks like Christoph
> as some planto restructure pcie flr specific functions but I don't know
> the exact time-frame. For now,I am planning to use existing pcie_flr()
> after checking FLR capability. We will switchto revised pcie_flr() once
> it is available.
> 
> I hope you are fine with this approach. Please let me know. Thanks.

I've seen that other discussion. I don't think the change here
should be done prior to the error reporting being put in place,
for security reasons. But in the end it'll be Konrad as the
maintainer to judge.

Or wait, looks like there's some confusion in ./MAINTAINERS:
Konrad is listed as maintainer for "XEN PCI SUBSYSTEM", but the
list of files doesn't include pciback. So it would instead be Boris
or Jürgen to give you a final word.

Jan