linux-kernel - Re: [PATCH v2] x86/mm: warn on W+x mappings

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: <20151021094357.GB12155@gmail.com>
Date:	Wed, 21 Oct 2015 11:43:57 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Josh Triplett <josh@...htriplett.org>
Cc:	Matt Fleming <matt@...eblueprint.co.uk>,
	Borislav Petkov <bp@...en8.de>,
	Stephen Smalley <sds@...ho.nsa.gov>, x86@...nel.org,
	linux-kernel@...r.kernel.org, keescook@...omium.org,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH v2] x86/mm: warn on W+x mappings


* Josh Triplett <josh@...htriplett.org> wrote:

> On Wed, Oct 14, 2015 at 05:19:40PM +0200, Ingo Molnar wrote:
> > 
> > * Josh Triplett <josh@...htriplett.org> wrote:
> > 
> > > On Mon, Oct 12, 2015 at 04:17:54PM +0200, Ingo Molnar wrote:
> > > > * Matt Fleming <matt@...eblueprint.co.uk> wrote:
> > > > > On Mon, 12 Oct, at 02:49:36PM, Ingo Molnar wrote:
> > > > > > So why not unmap them after bootup? Is there any reason to call into EFI code 
> > > > > > while the system is up and running?
> > > > > 
> > > > > That's where the runtime services code lives. So if you want things like EFI 
> > > > > variables (used by the distro installer, among other things) you need to map the 
> > > > > runtime regions.
> > > > 
> > > > So EFI variables could be queried during bootup and saved on the Linux side.
> > > 
> > > That wouldn't support writing to EFI variables.  Or using the EFI
> > > capsule update system to update firmware.
> > 
> > Well, if we know the location of those pages then we could map those 'rw-' - while 
> > the rest would be mapped 'r-x'.
> 
> We have no way to do so in the absence of the additional code/data
> separation information provided by more recent firmware.

But we could map those out via transparent page faults dynamically, as those 
accesses happen. It should be maximally compatible AFAICS, even without the new 
EFI extensions - and at no time would there be vulnerable 'rwx' mappings in the 
kernel page tables.

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/