linux-kernel - Re: "bad pmd" errors + oops with KPTI on 4.14.11 after loading X.509 certs

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: <CALCETrW8NxLd4v_U_g8JyW5XdVXWhM_MZOUn05J8VTuWOwkj-A@mail.gmail.com>
Date:   Wed, 3 Jan 2018 20:45:52 -0800
From:   Andy Lutomirski <luto@...nel.org>
To:     Benjamin Gilbert <benjamin.gilbert@...eos.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>,
        linux-mm@...ck.org, stable <stable@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>,
        Andy Lutomirski <luto@...nel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: "bad pmd" errors + oops with KPTI on 4.14.11 after loading X.509 certs

On Wed, Jan 3, 2018 at 8:35 PM, Benjamin Gilbert
<benjamin.gilbert@...eos.com> wrote:
> On Wed, Jan 03, 2018 at 04:37:53PM -0800, Andy Lutomirski wrote:
>> Maybe try rebuilding a bad kernel with free_ldt_pgtables() modified
>> to do nothing, and the read /sys/kernel/debug/page_tables/current (or
>> current_kernel, or whatever it's called).  The problem may be obvious.
>
> current_kernel attached.  I have not seen any crashes with
> free_ldt_pgtables() stubbed out.

I haven't reproduced it, but I think I see what's wrong.  KASLR sets
vaddr_end to a totally bogus value.  It should be no larger than
LDT_BASE_ADDR.  I suspect that your vmemmap is getting randomized into
the LDT range.  If it weren't for that, it could just as easily land
in the cpu_entry_area range.  This will need fixing in all versions
that aren't still called KAISER.

Our memory map code is utter shite.  This kind of bug should not be
possible without a giant warning at boot that something is screwed up.