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: <20200629225932.5036-1-daniel.gutson@eclypsium.com> <20200630085641.GD637809@kroah.com>
In-Reply-To: <20200630085641.GD637809@kroah.com>
From:   Richard Hughes <hughsient@gmail.com>
Date:   Tue, 30 Jun 2020 14:57:11 +0100
Message-ID: <CAD2FfiHHb=yA6MRsw2rPyJinthhFPNH2k6sLbthxcYVVaX5Mig@mail.gmail.com>
Subject: Re: [PATCH] SPI LPC information kernel module
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc:     Daniel Gutson <daniel.gutson@eclypsium.com>,
        Derek Kiernan <derek.kiernan@xilinx.com>,
        Arnd Bergmann <arnd@arndb.de>,
        Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Alex Bazhaniuk <alex@eclypsium.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, 30 Jun 2020 at 09:56, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> Again, which makes it seem like securityfs is not the thing for this, as
> it describes the hardware, not a security model which is what securityfs
> has been for in the past, right?

It describes the hardware platform. From a fwupd perspective I don't
mind if the BC attributes are read from securityfs, sysfs or even read
from an offset in a file from /proc... I guess sysfs makes sense if
securityfs is defined for things like the LSM or lockdown status,
although I also thought sysfs was for devices *in* the platform, not
the platform itself. I guess exposing the platform registers in sysfs
is no more weird than exposing things like the mei device and rfkill.

Richard