[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151001111718.GA25333@gmail.com>
Date:	Thu, 1 Oct 2015 13:17:18 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Dave Hansen <dave@...1.net>
Cc:	x86@...nel.org, linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Andy Lutomirski <luto@...nel.org>,
	Borislav Petkov <bp@...en8.de>, Kees Cook <keescook@...gle.com>
Subject: Re: [PATCH 26/26] x86, pkeys: Documentation
* Dave Hansen <dave@...1.net> wrote:
> > If yes then this could be a significant security feature / usecase for pkeys: 
> > executable sections of shared libraries and binaries could be mapped with pkey 
> > access disabled. If I read the Intel documentation correctly then that should 
> > be possible.
> 
> Agreed.  I've even heard from some researchers who are interested in this:
> 
> https://www.infsec.cs.uni-saarland.de/wp-content/uploads/sites/2/2014/10/nuernberger2014ccs_disclosure.pdf
So could we try to add an (opt-in) kernel option that enables this transparently 
and automatically for all PROT_EXEC && !PROT_WRITE mappings, without any 
user-space changes and syscalls necessary?
Beyond the security improvement, this would enable this hardware feature on most 
x86 Linux distros automatically, on supported hardware, which is good for testing.
Assuming it boots up fine on a typical distro, i.e. assuming that there are no 
surprises where PROT_READ && PROT_EXEC sections are accessed as data.
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/
Powered by blists - more mailing lists
 
