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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 14 Oct 2015 17:18:07 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Matt Fleming <matt@...eblueprint.co.uk>
Cc:	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>,
	Andy Lutomirski <luto@...nel.org>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Brian Gerst <brgerst@...il.com>, linux-efi@...r.kernel.org,
	Ard Biesheuvel <ard.biesheuvel@...aro.org>
Subject: Re: [PATCH v2] x86/mm: warn on W+x mappings


* Matt Fleming <matt@...eblueprint.co.uk> wrote:

> On Mon, 12 Oct, at 04:17:54PM, 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.
>  
> Right, we could do that, but then we wouldn't be able to support
> creation/updating variables at runtime, such as when you install a
> distribution for the first time, or want to boot a new kernel filename
> directly from the firmware without a boot loader (and need to modify
> the BootXXXX variables).

Do we know the precise position and address range of these variables?

We could map them writable (but not executable), and the rest executable (but not 
writable).

That raises the question whether the same physical page ever mixes variables and 
actual code - but the hope would be that it's suffiently page granular for this to 
work.

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/