All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: jeffxu@chromium.org, luto@kernel.org, jorgelo@chromium.org,
	keescook@chromium.org, groeck@chromium.org, jannh@google.com,
	sroettger@google.com
Cc: akpm@linux-foundation.org, jeffxu@google.com,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	linux-mm@kvack.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH 1/6] PKEY: Introduce PKEY_ENFORCE_API flag
Date: Tue, 16 May 2023 16:14:47 -0700	[thread overview]
Message-ID: <6cb7df56-0479-30be-5389-b4b819572deb@intel.com> (raw)
In-Reply-To: <20230515130553.2311248-2-jeffxu@chromium.org>

On 5/15/23 06:05, jeffxu@chromium.org wrote:
> --- a/arch/x86/mm/pkeys.c
> +++ b/arch/x86/mm/pkeys.c
> @@ -20,7 +20,7 @@ int __execute_only_pkey(struct mm_struct *mm)
>  	/* Do we need to assign a pkey for mm's execute-only maps? */
>  	if (execute_only_pkey == -1) {
>  		/* Go allocate one to use, which might fail */
> -		execute_only_pkey = mm_pkey_alloc(mm);
> +		execute_only_pkey = mm_pkey_alloc(mm, 0);
>  		if (execute_only_pkey < 0)
>  			return -1;
>  		need_to_set_mm_pkey = true;

In your threat model, what mechanism prevents the attacker from
modifying executable mappings?

I was trying to figure out if the implicit execute-only pkey should have
the PKEY_ENFORCE_API bit set.  I think that in particular would probably
cause some kind of ABI breakage, but it still reminded me that I have an
incomplete picture of the threat model.

  reply	other threads:[~2023-05-16 23:14 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-15 13:05 [PATCH 0/6] Memory Mapping (VMA) protection using PKU - set 1 jeffxu
2023-05-15 13:05 ` [PATCH 1/6] PKEY: Introduce PKEY_ENFORCE_API flag jeffxu
2023-05-16 23:14   ` Dave Hansen [this message]
2023-05-16 23:55     ` Jeff Xu
2023-05-17 11:07     ` Stephen Röttger
2023-05-15 13:05 ` [PATCH 2/6] PKEY: Add arch_check_pkey_enforce_api() jeffxu
2023-05-18 21:43   ` Dave Hansen
2023-05-18 22:51     ` Jeff Xu
2023-05-19  0:00       ` Dave Hansen
2023-05-19 11:22         ` Stephen Röttger
2023-05-15 13:05 ` [PATCH 3/6] PKEY: Apply PKEY_ENFORCE_API to mprotect jeffxu
2023-05-16 20:07   ` Kees Cook
2023-05-16 22:23     ` Jeff Xu
2023-05-16 23:18   ` Dave Hansen
2023-05-16 23:36     ` Jeff Xu
2023-05-17  4:50       ` Jeff Xu
2023-05-15 13:05 ` [PATCH 4/6] PKEY:selftest pkey_enforce_api for mprotect jeffxu
2023-05-15 13:05 ` [PATCH 5/6] KEY: Apply PKEY_ENFORCE_API to munmap jeffxu
2023-05-16 20:06   ` Kees Cook
2023-05-16 22:24     ` Jeff Xu
2023-05-16 23:23   ` Dave Hansen
2023-05-17  0:08     ` Jeff Xu
2023-05-15 13:05 ` [PATCH 6/6] PKEY:selftest pkey_enforce_api for munmap jeffxu
2023-05-15 14:28 ` [PATCH 0/6] Memory Mapping (VMA) protection using PKU - set 1 Dave Hansen
2023-05-15 15:03   ` Stephen Röttger
2023-05-16  7:06   ` Stephen Röttger
2023-05-16 22:41     ` Dave Hansen
2023-05-17 10:51       ` Stephen Röttger
2023-05-17 15:07         ` Dave Hansen
2023-05-17 15:21           ` Jeff Xu
2023-05-17 15:29             ` Dave Hansen
2023-05-17 23:48               ` Jeff Xu
2023-05-18 15:37                 ` Dave Hansen
2023-05-18 20:20                   ` Jeff Xu
2023-05-18 21:04                     ` Dave Hansen
2023-05-19 11:13                       ` Stephen Röttger
2023-05-24 20:15                       ` Jeff Xu
2023-06-01  1:39                       ` Jeff Xu
2023-06-01 16:16                         ` Dave Hansen
2023-05-31 23:02                   ` Jeff Xu
2023-05-16 20:08 ` Kees Cook
2023-05-16 22:17   ` Jeff Xu
2023-05-16 22:30     ` Dave Hansen
2023-05-16 23:39       ` Jeff Xu
2023-05-17 10:49   ` Stephen Röttger

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=6cb7df56-0479-30be-5389-b4b819572deb@intel.com \
    --to=dave.hansen@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=groeck@chromium.org \
    --cc=jannh@google.com \
    --cc=jeffxu@chromium.org \
    --cc=jeffxu@google.com \
    --cc=jorgelo@chromium.org \
    --cc=keescook@chromium.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=sroettger@google.com \
    /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.