linux-kernel - Re: [PATCH 5/7] x86/mm/init: remove freed kernel image areas from alias mapping

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]

Date:   Mon, 6 Aug 2018 08:17:59 -0700
From:   Dave Hansen <dave.hansen@...ux.intel.com>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Kees Cook <keescook@...gle.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Juergen Gross <jgross@...e.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Hugh Dickins <hughd@...gle.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Borislav Petkov <bp@...en8.de>, Andi Kleen <ak@...ux.intel.com>
Subject: Re: [PATCH 5/7] x86/mm/init: remove freed kernel image areas from
 alias mapping

On 08/04/2018 02:38 PM, Andy Lutomirski wrote:
> On Thu, Aug 2, 2018 at 3:58 PM, Dave Hansen <dave.hansen@...ux.intel.com> wrote:
>> This otherwise unused alias mapping of the holes will, by default
>> keep the Global bit, be mapped out to userspace, and be
>> vulnerable to Meltdown.
>>
>> Remove the alias mapping of these pages entirely.  This is likely
>> to fracture the 2M page mapping the kernel image near these areas,
>> but this should affect a minority of the area.
...
> 
> I like this patch, and I tend to think we should (eventually) enable
> it regardless of PTI.  Cleaning up the memory map is generally a good
> thing.
> 
> Also, just to make sure I fully understand: the kernel text is aliased
> in both the direct map and the high map, right?

Yes.  I don't think the double mapping was because of anything that we
really intentionally designed, though.  I think it was just easiest to
leave it in place and it didn't hurt anything.

> This means that we should be able to make the high kernel mapping
> have proper RO permissions very early without breaking text_poke() at
> the minor cost of needing to force a serializing instruction at the
> end of each big block of text pokes.  I think this would be
> worthwhile, although I suspect we'll uncover *tons* of bugs in the
> process.

Yeah, this could easily happen much earlier.