linux-kernel - Re: [PATCH 2/2] firmware: smccc: Add ARCH_SOC

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: <20200522165422.GA18810@bogus>
Date:   Fri, 22 May 2020 17:54:22 +0100
From:   Sudeep Holla <sudeep.holla@....com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Will Deacon <will@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        harb@...erecomputing.com, Jose.Marinho@....com,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Sudeep Holla <sudeep.holla@....com>,
        Francois Ozog <francois.ozog@...aro.org>
Subject: Re: [PATCH 2/2] firmware: smccc: Add ARCH_SOC_ID support

(+ Jose (SMCCC Spec author))

On Fri, May 22, 2020 at 04:46:12PM +0200, Arnd Bergmann wrote:
> On Fri, May 22, 2020 at 2:50 PM Sudeep Holla <sudeep.holla@....com> wrote:
> > +
> > +       soc_id_rev = res.a0;
> > +
> > +       soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
> > +       if (!soc_dev_attr)
> > +               return -ENOMEM;
> > +
> > +       sprintf(soc_id_str, "0x%04x", IMP_DEF_SOC_ID(soc_id_version));
> > +       sprintf(soc_id_rev_str, "0x%08x", soc_id_rev);
> > +       sprintf(soc_id_jep106_id_str, "0x%02x%02x",
> > +               JEP106_BANK_CONT_CODE(soc_id_version),
> > +               JEP106_ID_CODE(soc_id_version));
> > +
> > +       soc_dev_attr->soc_id = soc_id_str;
> > +       soc_dev_attr->revision = soc_id_rev_str;
> > +       soc_dev_attr->jep106_id = soc_id_jep106_id_str;
>
> Ok, let me try to understand how this maps the 64-bit ID into the
> six strings in user space:
>
> For a chip that identifies as
>
> JEP106_BANK_CONT_CODE = 12
> JEP106_ID_CODE = 34
> IMP_DEF_SOC_ID = 5678
> soc_id_rev = 9abcdef0
>
> the normal sysfs attributes contain these strings:
>
> machine = ""
> family = ""
> revision = "0x9abcdef0
> serial_number = ""
> soc_id = "0x5678"
>
> and the new attribute is
>
> jep106_identification_code = "0x1234"
>
> This still looks like a rather poorly designed interface to me, with a
> number of downsides:
>
> - Nothing in those strings identifies the numbers as using jep106
>   numbers rather than some something else that might use strings
>   with hexadecimal numbers.
>

Not sure if I understand your concerns completely here.

Anyways I wanted to clarify that the jep106 encoding is applicable only
for manufacturer's id and not for SoC ID or revision. Not sure if that
changes anything about your concerns.

> - I think we should have something unique in "family" just because
>   existing scripts can use that as the primary indentifier
>

I agree with your idea of combining attributes, not sure exactly which
ones yet.

> - It seems odd that there is no way to read the serial number through
>   the same interface and publish it the usual way.

Valid concern and I will pass this to interface authors.

>   Francois Ozog
>   recently asked for a generic way to find out a serial number for
>   inventory management, and this would be the obvious place to have it.

Agreed, but not sure what author(s) have to say. I have cc-ed one of them.

>   It can of course be added later when the next revision of the spec
>   is there, it just seems like a surprising omission.
>

Yes, definitely. Good to get feedback.

> How about making the contents:
>
> machine = "" /* could be a future addition, but board specific */
> family = "jep106:1234"

But this just indicates manufacturer id and nothing related to SoC family.
If it is jep106:043b, all it indicates is Arm Ltd and assigning it to
family doesn't sound right to me.

I had requests for both of the above during the design of interface but
I was told vendors were happy with the interface. I will let the authors
speak about that.

> revision = "0x9abcdef0
> serial_number = "0xfedcba987654321" /* to be implemented later */

Sure.

> soc_id = "jep106:1234:5678" /* duplicates family but makes it unique*/

Not sure again.
>
> That would work without any new properties, dropping the other patch,
> and be easier to use for identification from user space.
>

OK, I agree on ease part. But for me, we don't have any property in the
list to indicate the vendor/manufacturer's name. I don't see issue adding
one, name can be fixed as jep106_identification_code is too specific.

How about manufacturer with the value in the format "jep106:1234" if
it is not normal string but jep106 encoding.

--
Regards,
Sudeep