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  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]
Date:   Tue, 23 Oct 2018 18:26:49 +0200
From:   Anatolij Gustschin <agust@...x.de>
To:     Andreas Puhm <puhm@...gano.at>
Cc:     Moritz Fischer <mdf@...nel.org>, Alan Tull <atull@...nel.org>,
        "linux-fpga@...r.kernel.org" <linux-fpga@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] fpga: altera_cvp: restrict registration to CvP enabled
 devices

Hi Andreas,

On Mon, 22 Oct 2018 13:15:34 +0000
Andreas Puhm puhm@...gano.at wrote:
...
>Full description:
>The altera_cvp probe function only checks, 
>if the Altera/Intel PCI device configuration space contains a vendor
>specific entry (VSEC Capability Header 0x000b) at offset 0x200.
> But the probe function does not verify, if the PCI device (and further
>the FPGA), for which it has been called, actually supports the Configure-
>via-Protocol feature.
>
>The PCI device (FPGA) can explicitly disable the Configur-via-Protocol
>(CvP) feature by setting the CVP_EN bit, index 20 of CVP_STATUS register,
>to '0'.
>As the altera_cvp probe function does not check this it registers the
>device in any way.

The CvP docs says that on some FPGAs (e.g. Arria 10) the assertion of CVP
status can take up to 500ms. However it is not clear whether this delay
might be required after peripheral image configuration and after PCIe
link activation. The diagram describing configuration sequence suggests
that CVP_EN should be polled until it is asserted. I can imaging the
situation that this bit is still not asserted when the device is being
probed. Maybe we should better defer device probing if CVP_EN bit is
cleared? When deferred probing fails again and sufficient period for
CVP_EN bit assertion elapsed, then stop deferred probing and return
-ENODEV?

Thanks,

Anatolij

Powered by blists - more mailing lists