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]

Date:	Fri, 6 Nov 2015 07:55:50 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Stephen Smalley <sds@...ho.nsa.gov>,
	Matt Fleming <matt.fleming@...el.com>
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


* 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/