linux-kernel - Re: [PATCH 4.4 00/37] 4.4.110-stable review

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: <CALCETrW3hfkeUAPzFhGdE56vn23Q462h2reMaT=3ftbNGeSb3Q@mail.gmail.com>
Date:   Fri, 5 Jan 2018 10:15:00 -0800
From:   Andy Lutomirski <luto@...nel.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Pavel Tatashin <pasha.tatashin@...cle.com>,
        Hugh Dickins <hughd@...gle.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Thomas Voegtle <tv@...96.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Guenter Roeck <linux@...ck-us.net>,
        Shuah Khan <shuahkh@....samsung.com>, patches@...nelci.org,
        Ben Hutchings <ben.hutchings@...ethink.co.uk>,
        lkft-triage@...ts.linaro.org, stable <stable@...r.kernel.org>
Subject: Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Fri, Jan 5, 2018 at 9:52 AM, Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
> On Fri, Jan 05, 2018 at 12:48:54PM -0500, Pavel Tatashin wrote:
>> Boots successfully with "noefi" kernel parameter :)
>
> Thanks, that will help me narrow it down.  I'll dig through more patches
> when I get home tonight...

I wish you luck.  The 4.4 series is "KAISER", not "KPTI", and the
relevant code is spread all over the place and is generally garbage.
See, for example, the turd called kaiser_set_shadow_pgd().  I would
not be terribly surprised if that particular turd is biting here.

An alternative theory is that something is screwy in the EFI code.  I
don't see anything directly wrong, but it's certainly a bit sketchy.
The newer kernels carefully avoid using PCID 0 for real work to avoid
corruption due to EFI and similar things.  The "KAISER" code has no
such mitigation.  Fortunately, it seems to use PCID=0 for kernel and
PCID=nonzero for user, so the obvious problem isn't present, but
something could still be wrong.

Pavel, can you send your /proc/cpuinfo on a noefi boot?  (Just the
first CPU worth is fine.)

FWIW, I said before that I have very little desire to help debug
"KAISER".  I stand by that.