linux-kernel - RE: [PATCH v1 1/1] platform/mellanox: Add bootctl driver for Mellanox BlueField 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: <DB6PR05MB3223132246F702D41F7399ECA1910@DB6PR05MB3223.eurprd05.prod.outlook.com>
Date:   Thu, 31 Jan 2019 16:53:27 +0000
From:   Liming Sun <lsun@...lanox.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
CC:     Andy Shevchenko <andy@...radead.org>,
        Darren Hart <dvhart@...radead.org>,
        Vadim Pasternak <vadimp@...lanox.com>,
        David Woods <dwoods@...lanox.com>,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v1 1/1] platform/mellanox: Add bootctl driver for Mellanox
 BlueField Soc

Thanks!  v2 has been posted trying to solve all the comments. Please also see response inline.

Regards,
Liming

> -----Original Message-----
> From: Andy Shevchenko <andy.shevchenko@...il.com>
> Sent: Wednesday, January 30, 2019 4:17 PM
> To: Liming Sun <lsun@...lanox.com>
> Cc: Andy Shevchenko <andy@...radead.org>; Darren Hart <dvhart@...radead.org>; Vadim Pasternak <vadimp@...lanox.com>; David
> Woods <dwoods@...lanox.com>; Platform Driver <platform-driver-x86@...r.kernel.org>; Linux Kernel Mailing List <linux-
> kernel@...r.kernel.org>
> Subject: Re: [PATCH v1 1/1] platform/mellanox: Add bootctl driver for Mellanox BlueField Soc
> 
> On Wed, Jan 30, 2019 at 10:47 PM Liming Sun <lsun@...lanox.com> wrote:
> 
> > > First of all, is it a real watchdog with a driver? I think watchdog in
> > > that case should be set up through standard watchdog facilities.
> >
> > This is not a watchdog driver itself. Instead, it provides interface to
> > user-space and use ARM SMC calls to ATF to configure registers and
> > watchdog. I'll update the commit message in v2 to clarify it.
> 
> Hmm... For example Intel MID platforms have SCU (system controller
> unit) that provides a watchdog facility. In the kernel we have a
> watchdog driver for that.
> Can't you do similar for your case?

The process might be different than what's done on the BlueField SoC.

After the boot-partition swapping, the ARM watchdog is not started
right away. It is started during next rebooting by the ATF BL1 code 
(which is the Boot ROM code than couldn't change). The Boot-ROM 
checks some register value which is preserved during rebooting, and 
knows that a boot-partition swapping is in process, thus enable the 
watchdog timer if configured. At this time, no UEFI or Linux is running, 
just the boot ROM code at the very beginning.

I'll add the sequence of such use case in the commit message of v2.

> 
> > > > +       if (mlxbf_bootctl_smc_call1(MLXBF_BOOTCTL_SET_POST_RESET_WDOG,
> > > > +                                   watchdog) < 0)
> > > > +               return -EINVAL;
> > >
> > > If that call returns an error it shouldn't be shadowed here.
> >
> > Not sure I understand this comment correctly or not.
> > This function is defined by DRIVER_ATTR_RW(), which appears to expect
> > ssize_t or an error code as return value according to other examples I saw.
> 
> What is returned by mlx...call1() should be propagated to the actual caller.
> Same comment for all similar cases.

Make sense! Thanks for the explanation. Updated it in v2.

> 
> > > > +       lc_state &= (MLXBF_BOOTCTL_SB_MODE_TEST_MASK |
> > > > +                    MLXBF_BOOTCTL_SB_MODE_SECURE_MASK);
> > >
> > > Better to split like
> > >
> > > xxx =
> > >  (A | B);
> >
> > It seems hard to do "(A | B);" within 80 characters plus the indents.
> 
> Repeating myself, it's still better than your variant for readability.

Done. Managed to shorten the variable name a little bit.
Updated it in v2.

> 
> > > > +       if (res.a0 != 0x89c036b4 || res.a1 != 0x11e6e7d7 ||
> > > > +           res.a2 != 0x1a009787 || res.a3 != 0xc4bf00ca)
> > >
> > > What is this?!
> > >
> > > Can you use UUID API?
> >
> > Yes, it is UUID comparison. The SMC call returns four 'unsigned long' from ATF
> > to represent the UUID. There seems no existing APIs in uapi/linux/uuid.h to
> > compare such special format. How about replacing it with comment and MACROs
> > instead of the hardcoded values to make it more readable?
> 
> Should be no magic numbers involved inside the function at the end.
> Use descriptive definitions and I still recommend to give a look at
> UUID API how it can be utilized here.
> (hint: Thunderbolt hw is operating with integers, though driver uses
> UUID API at the end)
> 

Updated in v2. Now it should look better :)

> --
> With Best Regards,
> Andy Shevchenko