Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200716223627.253936-1-daniel.gutson@eclypsium.com>
 <20200717062841.GA3238569@kroah.com> <CAK8P3a1yy7YyeJH5k40yAXb23y9siBnfuqixb76t3BK9Xh=uXQ@mail.gmail.com>
 <CAFmMkTFLm9mw5-8Dj_7rhP2KBcLUoJ1WcQCJv5_k+QRsmJPxjg@mail.gmail.com>
In-Reply-To: <CAFmMkTFLm9mw5-8Dj_7rhP2KBcLUoJ1WcQCJv5_k+QRsmJPxjg@mail.gmail.com>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Fri, 17 Jul 2020 17:02:22 +0200
Message-ID: <CAK8P3a2Y0vy5WaPvVBQDqBb67pyZ0yPdYhEKA9=rgb80k5JyDQ@mail.gmail.com>
Subject: Re: [PATCH] [PATCH] Firmware security information in SYSFS
To:     Daniel Gutson <daniel@eclypsium.com>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Derek Kiernan <derek.kiernan@xilinx.com>,
        Tudor Ambarus <tudor.ambarus@microchip.com>,
        Miquel Raynal <miquel.raynal@bootlin.com>,
        Richard Weinberger <richard@nod.at>,
        Vignesh Raghavendra <vigneshr@ti.com>,
        Mika Westerberg <mika.westerberg@linux.intel.com>,
        Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Richard Hughes <hughsient@gmail.com>,
        Alex Bazhaniuk <alex@eclypsium.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Jul 17, 2020 at 4:46 PM Daniel Gutson <daniel@eclypsium.com> wrote:
> On Fri, Jul 17, 2020 at 11:41 AM Arnd Bergmann <arnd@arndb.de> wrote:
> >
>> > Also, this really is a _SPECIFIC_ type of firmware that supports these
>> > features, right?  Why not call that out too?  This is not generic by any
>> > means.
>>
>> As I suggested in my previous review, I wouldn't worry too much about
>> the user interface at the start, but instead first work out how the hardware
>> support fits in with the existing drivers and once that looks fine decide
>> on how to export it to user space.
>>
>> I agree the  /sys/kernel/firmware-security/bioswe sounds like the wrong
>> place, but I'm not sure if adding any other new directory in sysfs is
>> much better. I think the most promising would be to have it on the
>> sysfs directory for the device it refers to,
>
>
> My idea is to have all the firmware security information together in the same place; this information comes from many devices.
> This initial patch involves the SPI Controller, and I don't want to add more stuff until there
> is a consensus.
> So, do you have a suggestion where to put this information?
> /sys/devices/system/firmware-security?
> /sys/firmware/security?
> other?

I think it needs to be more specific than this. On a many machines
there may be a dozens of things described as "firmware" of some
sort, and even more things that relate to "security". You may also have
to consider the problem that there may be multiple devices that
want to register to this interface to export similar bits of information.

In the two drivers you have changed, there is a device node, so
the natural concept would be to either have attributes in that node,
or a child device under it with a fixed set of attributes, which can
then be referenced as a class device like

/sys/class/${NAME}/${NAME0} ->
../../devices/ci0000:00/0000:00:01.1/0000:01:00.2/${NAME}
/sys/devices/ci0000:00/0000:00:01.1/0000:01:00.2/${NAME}/${ATTRIBUTE}

This is easy to implement, and easy to access from user space,
if this works for you, the hardest part may be to decide on what to call it ;-)

     Arnd