[<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