linux-kernel - Re: [PATCH 4/5] driver core: inhibit automatic driver binding on reserved 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]

Message-ID: <YXbTLYzHadphE5ZN@heinlein>
Date:   Mon, 25 Oct 2021 10:54:21 -0500
From:   Patrick Williams <patrick@...cx.xyz>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Frank Rowand <frowand.list@...il.com>,
        Zev Weiss <zev@...ilderbeest.net>, kvm@...r.kernel.org,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Kirti Wankhede <kwankhede@...dia.com>,
        Jeremy Kerr <jk@...econstruct.com.au>,
        Rajat Jain <rajatja@...gle.com>,
        Jianxiong Gao <jxgao@...gle.com>,
        Dave Jiang <dave.jiang@...el.com>,
        Saravana Kannan <saravanak@...gle.com>,
        Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
        openbmc@...ts.ozlabs.org, devicetree@...r.kernel.org,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        Alex Williamson <alex.williamson@...hat.com>,
        Rob Herring <robh+dt@...nel.org>,
        Bhaskar Chowdhury <unixbhaskar@...il.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andrew Jeffery <andrew@...id.au>,
        Cornelia Huck <cohuck@...hat.com>,
        linux-kernel@...r.kernel.org, Vinod Koul <vkoul@...nel.org>,
        dmaengine@...r.kernel.org
Subject: Re: [PATCH 4/5] driver core: inhibit automatic driver binding on
 reserved devices

On Mon, Oct 25, 2021 at 04:09:59PM +0200, Greg Kroah-Hartman wrote:
> On Mon, Oct 25, 2021 at 09:02:40AM -0500, Patrick Williams wrote:
> > On Mon, Oct 25, 2021 at 03:34:05PM +0200, Greg Kroah-Hartman wrote:
> > > On Mon, Oct 25, 2021 at 08:20:05AM -0500, Patrick Williams wrote:
> > > I think "it" is "something needs to be the moderator between the two
> > > operating systems".  What is the external entity that handles the
> > > switching between the two?
> > 
> > Ah, ok.
> > 
> > Those usually end up being system / device specific.  In the case of the BIOS
> > flash, most designs I've seen use a SPI mux between the BMC and the host
> > processor or IO hub (PCH on Xeons).  The BMC has a GPIO to control the mux.
> > 
> > As far as state, the BMC on start-up will go through a set of discovery code to
> > figure out where it left the system prior to getting reset.  That involves
> > looking at the power subsystem and usually doing some kind of query to the host
> > to see if it is alive.  These queries are mostly system / host-processor design
> > specific.  I've seen anything from an IPMI/IPMB message alert from the BMC to
> > the BIOS to ask "are you alive" to reading host processor state over JTAG to
> > figure out if the processors are "making progress".
> 
> But which processor is "in control" here over the hardware?  

The BMC.  It owns the GPIO that controls the SPI mux.  

But, the BMC is responsible for doing all operations in a way that doesn't mess
up the running host processor(s).  Pulling away the SPI flash containing the
BIOS code at an incorrect time might do that.

> What method
> is used to pass the device from one CPU to another from a logical point
> of view?  

The state of the server as a whole is determined and maintained by the BMC.  I'm
simplifying here a bit but the operation "turn on the host processors" implies
"the host processors will access the BIOS" so the BMC must ensure "SPI mux is
switched towards the host" before "turn on the host processors".

> Sounds like it is another driver that needs to handle all of
> this, so why not have that be the one that adds/removes the devices
> under control here?

If what you're describing is moving all of the state control logic into the
kernel, I don't think that is feasible.  For some systems it would mean moving
yet another entire IPMI stack into the kernel tree.  On others it might be
somewhat simpler, but it is still a good amount of code.  We could probably
write up more details on the scope of this.

If what you're describing is a small driver, similar to the board support
drivers that were used before the device tree, that instantiates subordinate
devices it doesn't seem like an unreasonable alternative to DT overlays to me
(for whatever my limited kernel contribution experience counts for).

-- 
Patrick Williams

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)