linux-kernel - Re: [PATCH v3] usb: core: verify devicetree nodes for USB 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] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 17 May 2019 13:15:24 +0200
From:   Marek Szyprowski <m.szyprowski@...sung.com>
To:     Måns Rullgård <mans@...sr.com>
Cc:     Peter Chen <peter.chen@....com>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "linux-samsung-soc@...r.kernel.org" 
        <linux-samsung-soc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        Markus Reichl <m.reichl@...etechno.de>,
        Krzysztof Kozlowski <krzk@...nel.org>
Subject: Re: [PATCH v3] usb: core: verify devicetree nodes for USB devices

Hi Måns

On 2019-05-13 12:06, Måns Rullgård wrote:
> Marek Szyprowski <m.szyprowski@...sung.com> writes:
>
>> Hi Peter,
>>
>> On 2019-05-13 11:23, Peter Chen wrote:
>>>> On 2019-05-13 11:00, Peter Chen wrote:
>>>>>> On 2019-05-10 05:10, Peter Chen wrote:
>>>>>>>> Marek Szyprowski <m.szyprowski@...sung.com> writes:
>>>>>>>>> Commit 69bec7259853 ("USB: core: let USB device know device node")
>>>>>>>>> added support for attaching devicetree node for USB devices. The
>>>>>>>>> mentioned commit however identifies the given USB device node only
>>>>>>>>> by the
>>>>>> 'reg'
>>>>>>>>> property in the host controller children nodes. The USB device
>>>>>>>>> node however also has to have a 'compatible' property as described
>>>>>>>>> in Documentation/devicetree/bindings/usb/usb-device.txt. Lack for
>>>>>>>>> the 'compatible' property check might result in assigning a
>>>>>>>>> devicetree node, which is not intended to be the proper node for the given
>>>> USB device.
>>>>>>>>> This is important especially when USB host controller has
>>>>>>>>> child-nodes for other purposes. For example, Exynos EHCI and OHCI
>>>>>>>>> drivers already define child-nodes for each physical root hub port
>>>>>>>>> and assigns respective PHY controller and parameters for them.
>>>>>>>>> Those binding predates support for USB devicetree nodes.
>>>>>>>>>
>>>>>>>>> Checking for the proper compatibility string allows to mitigate
>>>>>>>>> the conflict between USB device devicetree nodes and the bindings
>>>>>>>>> for USB controllers with child nodes. It also fixes the
>>>>>>>>> side-effect of the other commits, like 01fdf179f4b0 ("usb: core:
>>>>>>>>> skip interfaces disabled in devicetree"), which incorrectly
>>>>>>>>> disables some devices on Exynos based boards.
>>>>>>> Hi Marek,
>>>>>>>
>>>>>>> The purpose of your patch is do not set of_node for device under USB
>>>>>>> controller,
>>>>>> right?
>>>>>>
>>>>>> Right.
>>>>>>
>>>>> Do you mind doing it at function exynos_ehci_get_phy of ehci-exynos.c?
>>>> I don't mind fixing it in ehci-exynos, but frankly so far I have no
>>>> idea how to do it.  The problem is that newly created USB devices
>>>> get of-node pointer pointing to a node which if not intended for
>>>> them. How this can be fixed in ehci-exynos?
>>>>
>>>    
>>> Can't be workaround by setting of_node as NULL for EHCI controller or
>>> for PHY node at exynos_ehci_get_phy?
>> Ah, such workaround? I will check, but this will need to be done with
>> care, because have a side effect for other subsystems like regulators or
>> clocks.
>>
>> BTW, What's wrong with proper, full verification of USB device nodes?
> Your approach so far doesn't address the actual problem of a conflict
> between the generic USB DT bindings and those for the Exynos host
> controller.  If you fix that, the validation issue goes away.

Well, the issue caused by the Exynos binding conflict will go away, but 
there still will be a chance that wrong node might be assigned to the 
USB device, especially if partially incorrect data will be stored in the 
device tree. For example, it may happen that on some boards the 
different USB chip is mounted, which require different parameters. The 
code only relies on the reg property and device number, while the 
bindings define compatible string with proper exact vendor/product ids.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland