linux-kernel - Re: [PATCH] pstore/ram: Improve backward compatibility with older Chromebooks

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: <CAD=FV=UKTDFwq3PSdpPmShRcOtZaH1mU=2H-ynoG4VooV=rKVQ@mail.gmail.com>
Date:   Tue, 7 May 2019 09:25:32 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Brian Norris <briannorris@...omium.org>
Cc:     Kees Cook <keescook@...omium.org>,
        Anton Vorontsov <anton@...msg.org>,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
        Julius Werner <jwerner@...omium.org>,
        Guenter Roeck <groeck@...omium.org>,
        Matthias Kaehlcke <mka@...omium.org>,
        Colin Cross <ccross@...roid.com>,
        Tony Luck <tony.luck@...el.com>,
        Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] pstore/ram: Improve backward compatibility with older Chromebooks

Hi,

On Mon, May 6, 2019 at 2:40 PM Brian Norris <briannorris@...omium.org> wrote:
>
> On Fri, May 3, 2019 at 10:48 AM Douglas Anderson <dianders@...omium.org> wrote:
> > When you try to run an upstream kernel on an old ARM-based Chromebook
> > you'll find that console-ramoops doesn't work.
>
> Ooh, nice! I still get annoyed by old depthcharge firmware. It's
> almost as if we should have gotten an upstream binding approved before
> baking it into firmware...
>
> > --- a/fs/pstore/ram.c
> > +++ b/fs/pstore/ram.c
>
> > @@ -703,6 +704,23 @@ static int ramoops_parse_dt(struct platform_device *pdev,
> >
> >  #undef parse_size
> >
> > +       /*
> > +        * Some old Chromebooks relied on the kernel setting the console_size
> > +        * and pmsg_size to the record size since that's what the downstream
> > +        * kernel did.  These same Chromebooks had "ramoops" straight under
> > +        * the root node which isn't according to the upstream bindings.
>
> The last part of the sentence technically isn't true -- the original
> bindings (notably, with no DT maintainer Reviewed-by) didn't specify
> where such a node should be found:
>
> 35da60941e44 pstore/ram: add Device Tree bindings
>
> so child-of-root used to be a valid location. But anyway, this code is
> just part of a heuristic for "old DT" (where later bindings clarified
> this), so it still seems valid.

I agree that it was unclear in the past, but it is true that being
under the root node is not according to the _current_ upstream
bindings, right?  ;-)


> >  Let's
> > +        * make those old Chromebooks work by detecting this and mimicing the
>
> s/mimicing/mimicking/

Kees: if you want me to spin with this typo fix then please let me
know.  Otherwise I'll assume it's less work for you to just fix it
yourself when applying.

-Doug