linux-kernel - Re: [PATCH v2 2/7] bus: Introduce firewall controller framework

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]

Message-ID: <409eb745-aab2-86a7-bd3a-9e8e05bed057@st.com>
Date:   Sat, 15 Feb 2020 12:41:07 +0000
From:   Benjamin GAIGNARD <benjamin.gaignard@...com>
To:     Greg KH <gregkh@...uxfoundation.org>,
        Linus Walleij <linus.walleij@...aro.org>
CC:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Grant Likely <grant.likely@....com>,
        "robh@...nel.org" <robh@...nel.org>,
        Loic PALLARDY <loic.pallardy@...com>,
        "arnd@...db.de" <arnd@...db.de>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "system-dt@...ts.openampproject.org" 
        <system-dt@...ts.openampproject.org>,
        "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "lkml@...ux.net" <lkml@...ux.net>,
        "linux-imx@....com" <linux-imx@....com>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        "sudeep.holla@....com" <sudeep.holla@....com>,
        "fabio.estevam@....com" <fabio.estevam@....com>,
        "stefano.stabellini@...inx.com" <stefano.stabellini@...inx.com>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v2 2/7] bus: Introduce firewall controller framework


On 2/14/20 10:40 PM, Greg KH wrote:
> On Fri, Feb 14, 2020 at 05:05:07PM +0100, Linus Walleij wrote:
>> On Fri, Jan 31, 2020 at 10:06 AM Greg KH <gregkh@...uxfoundation.org> wrote:
>>
>>> Why do people want to abuse the platform bus so much?  If a device is on
>>> a bus that can have such a controller, then it is on a real bus, use it!
>> I'm not saying it is a good thing, but the reason why it is (ab)used so
>> much can be found in:
>> drivers/of/platform.c
>>
>> TL;DR: struct platform_device is the Device McDeviceFace and
>> platform bus the Bus McBusFace used by the device tree parser since
>> it is slightly to completely unaware of what devices it is actually
>> spawning.
> <snip>
>
> Yeah, great explaination, and I understand.  DT stuff really is ok to be
> on a platform bus, as that's what almost all of them are.
>
> But, when you try to start messing around with things like this
> "firewall" says it is doing, it's then obvious that this really isn't a
> DT like thing, but rather you do have a bus involved with a controller
> so that should be used instead.

Ok but how put in place a new bus while keeping the devices on platform
bus to avoid changing all the drivers ?

>
> Or just filter away the DT stuff so that the kernel never even sees
> those devices, which might just be simplest :)

yes but we lost the possibility to change the firewall configuration at
run time. I do expect to be able to describe in the DT firewall configuration
and to use them at run time. That could allow, for example, to handover
a HW block to the coprocessor when the main core is going to be suspended
to save power.

Benjamin

>
> thanks,
>
> greg k-h