linux-kernel - Re: [GIT PULL] x86/mm changes for v4.4

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: <20151106074424.GA17053@gmail.com>
Date:	Fri, 6 Nov 2015 08:44:24 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Stephen Smalley <sds@...ho.nsa.gov>,
	Matt Fleming <matt@...eblueprint.co.uk>
Cc:	Dave Jones <davej@...emonkey.org.uk>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>, Borislav Petkov <bp@...en8.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andy Lutomirski <luto@...nel.org>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Kees Cook <keescook@...omium.org>
Subject: Re: [GIT PULL] x86/mm changes for v4.4


(resent with Matt's email address fixed.)

* Ingo Molnar <mingo@...nel.org> wrote:

> 
> * Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> 
> > On Wed, Nov 4, 2015 at 6:17 PM, Dave Jones <davej@...emonkey.org.uk> wrote:
> > > On Wed, Nov 04, 2015 at 05:31:59PM -0800, Linus Torvalds wrote:
> > >  >
> > >  > I don't have that later debug output at all. Presumably some config difference.
> > >
> > > CONFIG_X86_PTDUMP_CORE iirc.
> > 
> > No, I have that. I suspect CONFIG_EFI_PGT_DUMP instead.
> > 
> > Anyway, as it stands now, I think the CONFIG_DEBUG_WX option should
> > not default to 'y' unless it is made more useful if it actually
> > triggers. Ingo?
> 
> Yeah, agreed absolutely.
> 
> So this is a bit sad because RWX pages are a real problem in practice, especially 
> since the EFI addresses are well predictable, but generating a warning without 
> being able to fix it quickly is counterproductive as well, as it only annoys 
> people and makes them turn off the option. (Which we could do as well to begin 
> with, without the annoyance factor...)
> 
> So the plan would be:
> 
>  1) Make it default-n.
> 
>  2) We should try to further improve the messages to make it easier to determine
>     what's wrong. We _do_ try to output symbolic information in the warning, to 
>     make it easier to find buggy mappings, but these are not standard kernel
>     mappings. So I think we need an e820 mappings based semi-symbolic printout of
>     bad addresses - maybe even correlate it with the MMIO resource tree.
> 
>  3) We should fix the EFI permission problem without relying on the firmware: it 
>     appears we could just mark everything R-X optimistically, and if a write fault 
>     happens (it's pretty rare in fact, only triggers when we write to an EFI 
>     variable and so), we can mark the faulting page RW- on the fly, because it 
>     appears that writable EFI sections, while not enumerated very well in 'old' 
>     firmware, are still supposed to be page granular. (Even 'new' firmware I 
>     wouldn't automatically trust to get the enumeration right...)
> 
>     If that 'supposed to be' turns out to be 'not true' (not unheard of in
>     firmware land), then plan B would be to mark pages that generate write faults 
>     RWX as well, to not break functionality. (This 'mark it RWX' is not something 
>     that exploits would have easy access to, and we could also generate a warning
>     [after the EFI call has finished] if it ever triggers.)
> 
>     Admittedly this approach might not be without its own complications, but it 
>     looks reasonably simple (I don't think we need per EFI call page tables, 
>     etc.), and does not assume much about the firmware being able to enumerate its 
>     permissions properly. Were we to merge EFI support today I'd have insisted on 
>     trying such an approach from day 1 on.
> 
> Thanks,
> 
> 	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/