linux-kernel - Re: [PATCH] serial: sh-sci: Make sure status register SCxSR is read in correct sequence

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: <CAMuHMdXmfQ0x7mCZ-E7OPQFv2z-=mFDT20hJ2_JKax=OePB8eA@mail.gmail.com>
Date:   Wed, 1 Apr 2020 14:43:31 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...renesas.com>
Cc:     Kazuhiro Fujita <kazuhiro.fujita.jg@...esas.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>,
        "open list:SERIAL DRIVERS" <linux-serial@...r.kernel.org>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        Prabhakar <prabhakar.csengg@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Hao Bui <hao.bui.yg@...esas.com>,
        KAZUMI HARADA <kazumi.harada.rh@...esas.com>,
        Sasha Levin <sashal@...nel.org>,
        Chris Brandt <Chris.Brandt@...esas.com>,
        Magnus Damm <magnus.damm@...il.com>
Subject: Re: [PATCH] serial: sh-sci: Make sure status register SCxSR is read
 in correct sequence

Hi Prabhakar,

On Tue, Mar 31, 2020 at 5:58 PM Prabhakar Mahadev Lad
<prabhakar.mahadev-lad.rj@...renesas.com> wrote:
> > -----Original Message-----
> > From: Geert Uytterhoeven <geert@...ux-m68k.org>
> > On Fri, Mar 27, 2020 at 7:17 PM Kazuhiro Fujita
> > <kazuhiro.fujita.jg@...esas.com> wrote:
> > > For SCIF and HSCIF interfaces the SCxSR register holds the status of
> > > data that is to be read next from SCxRDR register, But where as for
> > > SCIFA and SCIFB interfaces SCxSR register holds status of data that is
> > > previously read from SCxRDR register.
> > >
> > > This patch makes sure the status register is read depending on the port
> > > types so that errors are caught accordingly.
> > >
> > > Cc: <stable@...r.kernel.org>
> > > Signed-off-by: Kazuhiro Fujita <kazuhiro.fujita.jg@...esas.com>
> > > Signed-off-by: Hao Bui <hao.bui.yg@...esas.com>
> > > Signed-off-by: KAZUMI HARADA <kazumi.harada.rh@...esas.com>
> > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>

> > Nevertheless, this patch will need some testing on various hardware.
> > Do you have a test case to verify the broken/fixed behavior?
> >
> Agreed, its been tested on RZ/G2x & RZ/G1x  by doing a loopback test, configure one interface as CS8 mode(8-bits data, No parity) and other as CS7 mode (7-bits data, 1-bit Parity) and parity errors should be detected.

This can easily be tested on the console.  Basic testing can even be
done with an unmodified kernel, as there is already a "parity error"
notice message in the driver.

Enable even parity on the console:

$ stty evenp

(use "oddp" for odd parity, and invert all below)

Typing e.g. a single "p" should trigger a parity error.
Typing "o" shouldn't.
Without this patch, no parity error is detected on SCIF.

Likewise, pasting a sequence of "p" characters should trigger a lot of
parity errors, "o" shouldn't.
Without this patch, parity errors are detected on SCIF, except for the
first character.

For more advanced testing, make the following change to the driver:

- dev_notice(port->dev, "parity error\n");
+ dev_notice(port->dev, "parity error for char 0x%02x hweight %u\n",
c, hweight8(c));

Pasting an alternating sequence of "p" and "o" characters should trigger
parity errors for the "p" characters.
Without this patch, they are triggered for the "o" characters instead.

With this patch, the issues above are fixed on SCIF.
This has been verified on:
  1. SCIF on R-Car Gen 2,
  2. SCIF on R-Car Gen3
  3. SCIF on RZ/A1H,
  4. SCIF on RZ/A2M.

However, I also tried this on HSCIF on R-Car Gen3, where I cannot
trigger parity errors at all.
Parabhakar: have you tried HSCIF on RZ/G1 and RZ/G2? Can you trigger
parity errors on HSCIF?

This has been regression-tested on:
  1. SCIFA on SH-Mobile AG5, R-Mobile A1, and R-Mobile APE6.

I haven't tested it yet on:
  1. SCIFB on SH/R-Mobile (needs wiring up),
  2. SCIFA, SCIFB, and HSCIF on R-Car Gen2 (needs wiring up),
  3. (H)SCIF on R-Car Gen1 (remote boards unaccessible at the moment),
  4. SuperH (only remote Migo-R available, but unaccessible).

I can test 1 and 2 (and perhaps 3 and 4) later, if needed.
Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds