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: <b06c24705caddf2f1e97237fd6aa3523@agner.ch>
Date:   Thu, 15 Nov 2018 16:00:32 +0100
From:   Stefan Agner <stefan@...er.ch>
To:     Trent Piepho <tpiepho@...inj.com>
Cc:     jingoohan1@...il.com, l.stach@...gutronix.de,
        gustavo.pimentel@...opsys.com, linux-kernel@...r.kernel.org,
        linux-pci@...r.kernel.org, bhelgaas@...gle.com
Subject: Re: [PATCH] PCI: dwc: Limit config space size for i.MX6

On 14.11.2018 20:44, Trent Piepho wrote:
> On Wed, 2018-11-14 at 16:49 +0100, Stefan Agner wrote:
>> On 19.10.2018 13:13, Stefan Agner wrote:
>> > Reading the full 4k config space through sysfs leads to an
>> > external abort. Testing on a platform showed that the upper
>> > limit is 512. Limit config space to 512.
>>
>> Any comment on this patch?
>>
>> Since other devices use similar quirks, I guess the fix can't be far
>> off?
>>
>> Maybe restricting to the PCI device ID used in i.MX 6 only is too
>> restrictive, but I guess better restrictive for now?
> 
> To trigger this bug I should read the sysfs "config" file for the PCI
> bridge device?
> 
> Tested on imx7, no problems.
> 
> # hexdump -C
> /sys/devices/platform/soc/30800000.aips-bus/33800000.pcie/pci0000:00/0000:00:00.0/config
>                                                                       
>
> [stuff]
> 00000130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
> |................|
> *                                                                     
>
> 00000400  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff 
> |................|
> *                                                                     
>
> 00000700  76 00 63 01 ff ff ff ff  04 00 00 07 00 f0 f0 1b 
> |v.c.............|
> [more stuff]
> 
> The bridge on imx7d is 16c3:abcd, same as patch I believe.  I do have a
> pci-e device connected, unlike the original bug.  Maybe that is
> related?  Or maybe this problem is fixed in imx7d?

The i.MX 7D seems to have a different register set...

I don't think it is related to whether a PCIe device is connected or
not.

The fact that i.MX 7D has the same device id and does not suffer the
problem actually shows that the approach this patch takes is not
ideal...

Will send a patch limiting register access on a per driver/compatible
string level.

--
Stefan

> 
>> >
>> >  #define PCI_VENDOR_ID_SYNOPSYS		0x16c3
>> > +#define PCI_DEVICE_ID_SYNOPSYS_IMX6	0xabcd
>> >
>> >  #define PCI_VENDOR_ID_VITESSE		0x1725
>> >  #define PCI_DEVICE_ID_VITESSE_VSC7174	0x7174

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ