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:   Wed, 29 Jan 2020 10:52:40 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Benjamin GAIGNARD <benjamin.gaignard@...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>,
        "broonie@...nel.org" <broonie@...nel.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 Wed, Jan 29, 2020 at 10:42:39AM +0100, Linus Walleij wrote:
> On Tue, Jan 28, 2020 at 9:30 PM Benjamin GAIGNARD
> <benjamin.gaignard@...com> wrote:
> > On 1/28/20 5:57 PM, Greg KH wrote:
> > > On Tue, Jan 28, 2020 at 04:41:29PM +0000, Benjamin GAIGNARD wrote:
> > >> On 1/28/20 4:52 PM, Greg KH wrote:
> 
> > >>> So put this in the bus-specific code that controls the bus that these
> > >>> devices live on.  Why put it in the driver core when this is only on one
> > >>> "bus" (i.e. the catch-all-and-a-bag-of-chips platform bus)?
> 
> > >> It is really similar to what pin controller does, configuring an
> > >> hardware block given DT information.
> 
> > > Great, then use that instead :)
> 
> > I think that Linus W. will complain if I do that :)
> 
> So the similarity would be something like the way that pin control
> states are configured in the device tree and the pin control
> handles are taken before probe in drivers/base/pinctrl.c embedding
> a hook into dd.c.
> 
> Not that it in any way controls any hardware even remotely
> similar to pin control. Pin control is an electronic thing,
> this firewalling is about bus access.
> 
> IIUC this framework wants to discover at kernel boot time
> whether certain devices are accessible to it or not by inspecting
> the state of the firewalling hardware and then avoid probing
> those that are inaccessible.
> 
> It needs the same deep hooks into dd.c to achieve this
> I believe.

It just needs to be part of the bus logic for the specific bus that this
"firewall" is on.  Just like we do the same thing for USB or thunderbolt
devices.  Put this in the bus-specific code please.

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ