linux-kernel - Re: [PATCH] [PATCH] Firmware security information in SYSFS

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>] [day] [month] [year] [list]

Message-ID: <CAK8P3a2Y0vy5WaPvVBQDqBb67pyZ0yPdYhEKA9=rgb80k5JyDQ@mail.gmail.com>
Date:   Fri, 17 Jul 2020 17:02:22 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Daniel Gutson <daniel@...ypsium.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Derek Kiernan <derek.kiernan@...inx.com>,
        Tudor Ambarus <tudor.ambarus@...rochip.com>,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        Richard Weinberger <richard@....at>,
        Vignesh Raghavendra <vigneshr@...com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Richard Hughes <hughsient@...il.com>,
        Alex Bazhaniuk <alex@...ypsium.com>
Subject: Re: [PATCH] [PATCH] Firmware security information in SYSFS

On Fri, Jul 17, 2020 at 4:46 PM Daniel Gutson <daniel@...ypsium.com> wrote:
> On Fri, Jul 17, 2020 at 11:41 AM Arnd Bergmann <arnd@...db.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