linux-kernel - Re: [PATCH v4 06/14] virt: gunyah: Add sysfs nodes

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Yz0i7VNc4oK58yh9@kroah.com>
Date:   Wed, 5 Oct 2022 08:23:41 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Elliot Berman <quic_eberman@...cinc.com>
Cc:     Bjorn Andersson <quic_bjorande@...cinc.com>,
        Murali Nalajala <quic_mnalajal@...cinc.com>,
        Trilok Soni <quic_tsoni@...cinc.com>,
        Srivatsa Vaddagiri <quic_svaddagi@...cinc.com>,
        Carl van Schaik <quic_cvanscha@...cinc.com>,
        Andy Gross <agross@...nel.org>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Jassi Brar <jassisinghbrar@...il.com>,
        linux-arm-kernel@...ts.infradead.org,
        Mark Rutland <mark.rutland@....com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Sudeep Holla <sudeep.holla@....com>,
        Marc Zyngier <maz@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Jonathan Corbet <corbet@....net>,
        Will Deacon <will@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Arnd Bergmann <arnd@...db.de>, devicetree@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 06/14] virt: gunyah: Add sysfs nodes

On Tue, Oct 04, 2022 at 04:50:51PM -0700, Elliot Berman wrote:
> 
> 
> On 9/30/2022 5:09 AM, Greg Kroah-Hartman wrote:
> > On Wed, Sep 28, 2022 at 12:56:25PM -0700, Elliot Berman wrote:
> > > Add /sys/hypervisor support when detecting that Linux is running in a
> > > Gunyah environment. Export the version of Gunyah which is reported via
> > > the hyp_identify hypercall.
> > > 
> > > Signed-off-by: Elliot Berman <quic_eberman@...cinc.com>
> > > ---
> > >   .../ABI/testing/sysfs-hypervisor-gunyah       | 15 ++++
> > >   MAINTAINERS                                   |  1 +
> > >   drivers/virt/Makefile                         |  1 +
> > >   drivers/virt/gunyah/Makefile                  |  2 +
> > >   drivers/virt/gunyah/sysfs.c                   | 71 +++++++++++++++++++
> > >   5 files changed, 90 insertions(+)
> > >   create mode 100644 Documentation/ABI/testing/sysfs-hypervisor-gunyah
> > >   create mode 100644 drivers/virt/gunyah/Makefile
> > >   create mode 100644 drivers/virt/gunyah/sysfs.c
> > > 
> > > diff --git a/Documentation/ABI/testing/sysfs-hypervisor-gunyah b/Documentation/ABI/testing/sysfs-hypervisor-gunyah
> > > new file mode 100644
> > > index 000000000000..7d74e74e9edd
> > > --- /dev/null
> > > +++ b/Documentation/ABI/testing/sysfs-hypervisor-gunyah
> > > @@ -0,0 +1,15 @@
> > > +What:		/sys/hypervisor/gunyah/api
> > > +Date:		October 2022
> > > +KernelVersion:	6.1
> > > +Contact:	linux-arm-msm@...r.kernel.org
> > > +Description:	If running under Gunyah:
> > > +		The Gunyah API version.
> > 
> > What does this version mean?  What format is it in?
> > 
> 
> The version is incremented on backwards-incompatible API changes. It's an
> integer: I've updated the description to mention it's an integer. FYI -- we
> are still currently at "1" and not aiming to increment this number. I'd like
> to get it reported in sysfs in case the version is incremented later.

If you change it in the future to be backwards incompatible, then you
have to change your kernel code anyway and userspace still has to keep
working the same so it would use a totally different interface.

So why is this even needed at all?

> > > +
> > > +What:		/sys/hypervisor/gunyah/variant
> > > +Date:		October 2022
> > > +KernelVersion:	6.1
> > > +Contact:	linux-arm-msm@...r.kernel.org
> > > +Description:	If running under Gunyah:
> > > +		Reports the build variant of Gunyah:
> > > +		The open source build of Gunyah will report "81".
> > > +		The Qualcomm build of Gunyah will report "72".
> > 
> > So there are only 2 versions variants?  What happens when you get a
> > third?  And why the odd numbers?
> > 
> 
> The kernel isn't parsing the reported build variant and is passing the
> reported value up to the sysfs node. If a new third variant comes along, its
> build variant number would be reported. Would it be preferred to instead
> link to Gunyah's definitions for the build variant?

Just document what these random numbers mean please and what userspace
is to do with them.  If nothing, and this is just information, who would
use that information?  And if no one, why report it at all? 

thanks,

greg k-h