linux-kernel - Re: [PATCH] i2c: piix4: Avoid race conditions with IMC

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: <CAHp75VdnoW84sQh-vf57NSC6_tXGqvb_36KCPpi-XFbktWiKfw@mail.gmail.com>
Date:   Wed, 11 Jan 2017 03:49:21 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Ricardo Ribalda Delgado <ricardo.ribalda@...il.com>
Cc:     Jean Delvare <jdelvare@...e.com>, Wolfram Sang <wsa@...-dreams.de>,
        linux-i2c@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] i2c: piix4: Avoid race conditions with IMC

On Tue, Jan 10, 2017 at 2:16 PM, Ricardo Ribalda Delgado
<ricardo.ribalda@...il.com> wrote:
> On AMD's SB800 and upwards, the SMBus is shared with the Integrated
> Micro Controller (IMC).
>
> The platform provides a hardware semaphore to avoid race conditions
> among them. (Check page 288 of the SB800-Series Southbridges Register
> Reference Guide http://support.amd.com/TechDocs/45482.pdf)

It would be nice to understand what kind of devices are accessing and to where.

Hans seems discovered one pretty nice issue on Intel
BayTrail/CherryTrail platforms where I2C semaphore is used to prevent
simultaneous access to P-Unit, but we have two paths there which are
not synchronized (yet). It brings a set of interesting (and
unfortunately "famous") bugs.

>
> Without this patch, many access to the SMBus end with an invalid
> transaction or even with the bus stalled.
>

> Credit-to: Alexandre Desnoyers <alex@...c.com>

Never saw before. Did he suggested the solution or what?

> --- a/drivers/i2c/busses/i2c-piix4.c
> +++ b/drivers/i2c/busses/i2c-piix4.c
> @@ -585,9 +585,28 @@ static s32 piix4_access_sb800(struct i2c_adapter *adap, u16 addr,
>                  u8 command, int size, union i2c_smbus_data *data)
>  {
>         struct i2c_piix4_adapdata *adapdata = i2c_get_adapdata(adap);
> +       unsigned short piix4_smba = adapdata->smba;
>         u8 smba_en_lo;
>         u8 port;
>         int retval;
> +       int timeout = 0;
> +       int smbslvcnt;

Keep them just after your another added variable.

> +       /* Request the SMBUS semaphore, avoid conflicts with the IMC */
> +       smbslvcnt  = inb_p(SMBSLVCNT);

> +       while (++timeout < MAX_TIMEOUT) {

Usual pattern is countdown.

do {
...
} while (--timeout);

> +               outb_p(smbslvcnt | 0x10, SMBSLVCNT);
> +
> +               /* Check the semaphore status */
> +               smbslvcnt  = inb_p(SMBSLVCNT);
> +               if (smbslvcnt & 0x10)
> +                       break;
> +
> +               usleep_range(1000, 2000);
> +       }

> +       /* SMBus is still owned by the IMC, we give up */
> +       if (timeout == MAX_TIMEOUT)
> +               return -EBUSY;

Would caller do it again? Perhaps -EAGAIN?

Since the returned value is not -ETIMEDOUT, I suppose the name of
counter variable is a bit confusing. Basically it's amount of attempts
with some gap between them. Though, it's up to you and maintainer.

> +       /* Release the semaphore */
> +       outb_p(smbslvcnt | 0x20, SMBSLVCNT);

-- 
With Best Regards,
Andy Shevchenko