From: Dave Hansen <dave.hansen@linux.intel.com>
To: Kees Cook <keescook@chromium.org>,
Catalin Marinas <catalin.marinas@arm.com>
Cc: Jann Horn <jann@thejh.net>,
"ksummit-discuss@lists.linuxfoundation.org"
<ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [TOPIC] kernel hardening / self-protection / whatever
Date: Thu, 4 Aug 2016 07:17:10 -0700 [thread overview]
Message-ID: <57A34E66.1040608@linux.intel.com> (raw)
In-Reply-To: <CAGXu5jL085S-feY_uy68tCMZwOHcg5QPzyE0eXiJviqCwau90g@mail.gmail.com>
On 08/03/2016 10:32 PM, Kees Cook wrote:
>> > BTW, while not a kernel security feature, I've been asked in the past to enable
>> > execute-only (no read) permissions on arm64 (e.g. mmap(PROT_EXEC)).
>> > I have a simple patch for this, though I'm not 100% sure about user ABI implications.
>> > So far I'm not aware of any user application using PROT_EXEC only and also
>> > expecting PROT_READ.
> x86 is working on this too, and IIRC, they uncovered some "fun" ELF
> corner cases. I've added Dave for some more background...
I haven't been able to find anything in the wild that actually uses
PROT_EXEC by itself. The corner cases I hit were because I took a
PROT_READ|PROT_EXEC mapping and munged it to really be PROT_EXEC only as
an experiment. It blew up pretty spectacularly because of
non-page-aligned ELF sections creating pages that really do contain
instructions _and_ read-only data.
The exec-only support got in 4.6 and does work under qemu today if
anyone wants to give it a try.
next prev parent reply other threads:[~2016-08-04 14:17 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-11 4:28 [Ksummit-discuss] [TOPIC] kernel hardening / self-protection / whatever Andy Lutomirski
2016-07-11 13:05 ` Rafael J. Wysocki
2016-07-11 16:30 ` Eric W. Biederman
2016-07-11 17:57 ` Kees Cook
2016-07-12 16:40 ` Eric W. Biederman
2016-07-21 15:54 ` Mark Rutland
2016-07-11 17:33 ` Jann Horn
2016-07-19 15:40 ` Eric W. Biederman
2016-07-20 2:14 ` Andy Lutomirski
2016-07-20 2:14 ` Eric W. Biederman
2016-07-20 6:42 ` Herbert Xu
2016-07-21 17:03 ` Eric W. Biederman
2016-07-11 17:53 ` Kees Cook
2016-07-11 18:07 ` Josh Triplett
2016-07-11 18:59 ` Kees Cook
2016-07-31 9:55 ` Paul Burton
2016-07-31 22:04 ` Kees Cook
2016-08-01 10:47 ` Mark Rutland
2016-08-01 19:42 ` Kees Cook
2016-08-03 22:53 ` Catalin Marinas
2016-08-04 5:32 ` Kees Cook
2016-08-04 5:45 ` Andy Lutomirski
2016-08-04 5:54 ` Kees Cook
2016-08-05 0:12 ` Andy Lutomirski
2016-09-08 23:54 ` Kees Cook
2016-09-09 0:42 ` Andy Lutomirski
2016-08-04 14:17 ` Dave Hansen [this message]
2016-08-04 22:29 ` Catalin Marinas
2016-08-01 9:34 ` [Ksummit-discuss] [nominations] " Mark Rutland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57A34E66.1040608@linux.intel.com \
--to=dave.hansen@linux.intel.com \
--cc=catalin.marinas@arm.com \
--cc=jann@thejh.net \
--cc=keescook@chromium.org \
--cc=ksummit-discuss@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.