All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@linux.intel.com>
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org,
	Dave Hansen <dave.hansen@linux.intel.com>,
	tglx@linutronix.de, linuxram@us.ibm.com, sandipan@linux.ibm.com,
	akpm@linux-foundation.org, fweimer@redhat.com,
	desnesn@linux.vnet.ibm.com, mingo@kernel.org,
	bauerman@linux.ibm.com, aneesh.kumar@linux.ibm.com,
	mpe@ellerman.id.au, mhocko@kernel.org, msuchanek@suse.de,
	shuah@kernel.org, x86@kernel.org
Subject: [PATCH 3/4] selftests/vm/pkeys: Refill shadow register after implicit kernel write
Date: Fri, 11 Jun 2021 09:42:00 -0700	[thread overview]
Message-ID: <20210611164200.EF76AB73@viggo.jf.intel.com> (raw)
In-Reply-To: <20210611164153.91B76FB8@viggo.jf.intel.com>


From: Dave Hansen <dave.hansen@linux.intel.com>

The pkey test code keeps a "shadow" of the pkey register around.  This
ensures that any bugs which might write to the register can be caught
more quickly.

Generally, userspace has a good idea when the kernel is going to write
to the register.  For instance, alloc_pkey() is passed a permission
mask.  The caller of alloc_pkey() can update the shadow based on the
return value and the mask.

But, the kernel can also modify the pkey register in a more sneaky
way.  For mprotect(PROT_EXEC) mappings, the kernel will allocate a
pkey and write the pkey register to create an execute-only mapping.
The kernel never tells userspace what key it uses for this.

This can cause the test to fail with messages like:

	protection_keys_64.2: pkey-helpers.h:132: _read_pkey_reg: Assertion `pkey_reg == shadow_pkey_reg' failed.

because the shadow was not updated with the new kernel-set value.

Forcibly update the shadow value immediately after an mprotect().

Fixes: 6af17cf89e99 ("x86/pkeys/selftests: Add PROT_EXEC test")
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Ram Pai <linuxram@us.ibm.com>
Cc: Sandipan Das <sandipan@linux.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Florian Weimer <fweimer@redhat.com>
Cc: "Desnes A. Nunes do Rosario" <desnesn@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Michal Suchanek <msuchanek@suse.de>
Cc: Shuah Khan <shuah@kernel.org>
Cc: x86@kernel.org
---

 b/tools/testing/selftests/vm/protection_keys.c |    7 +++++++
 1 file changed, 7 insertions(+)

diff -puN tools/testing/selftests/vm/protection_keys.c~selftests_vm_pkeys_Refill_shadow_register_after_implict_kernel_write-1 tools/testing/selftests/vm/protection_keys.c
--- a/tools/testing/selftests/vm/protection_keys.c~selftests_vm_pkeys_Refill_shadow_register_after_implict_kernel_write-1	2021-06-11 09:41:33.508468061 -0700
+++ b/tools/testing/selftests/vm/protection_keys.c	2021-06-11 09:41:33.517468061 -0700
@@ -1448,6 +1448,13 @@ void test_implicit_mprotect_exec_only_me
 	ret = mprotect(p1, PAGE_SIZE, PROT_EXEC);
 	pkey_assert(!ret);
 
+	/*
+	 * Reset the shadow, assuming that the above mprotect()
+	 * correctly changed PKRU, but to an unknown value since
+	 * the actual alllocated pkey is unknown.
+	 */
+	shadow_pkey_reg = __read_pkey_reg();
+
 	dprintf2("pkey_reg: %016llx\n", read_pkey_reg());
 
 	/* Make sure this is an *instruction* fault */
_

WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <dave.hansen@linux.intel.com>
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org,Dave Hansen
	<dave.hansen@linux.intel.com>,tglx@linutronix.de,linuxram@us.ibm.com,sandipan@linux.ibm.com,akpm@linux-foundation.org,fweimer@redhat.com,desnesn@linux.vnet.ibm.com,mingo@kernel.org,bauerman@linux.ibm.com,aneesh.kumar@linux.ibm.com,mpe@ellerman.id.au,mhocko@kernel.org,msuchanek@suse.de,shuah@kernel.org,x86@kernel.org
Subject: [PATCH 3/4] selftests/vm/pkeys: Refill shadow register after implicit kernel write
Date: Fri, 11 Jun 2021 09:42:00 -0700	[thread overview]
Message-ID: <20210611164200.EF76AB73@viggo.jf.intel.com> (raw)
In-Reply-To: <20210611164153.91B76FB8@viggo.jf.intel.com>


From: Dave Hansen <dave.hansen@linux.intel.com>

The pkey test code keeps a "shadow" of the pkey register around.  This
ensures that any bugs which might write to the register can be caught
more quickly.

Generally, userspace has a good idea when the kernel is going to write
to the register.  For instance, alloc_pkey() is passed a permission
mask.  The caller of alloc_pkey() can update the shadow based on the
return value and the mask.

But, the kernel can also modify the pkey register in a more sneaky
way.  For mprotect(PROT_EXEC) mappings, the kernel will allocate a
pkey and write the pkey register to create an execute-only mapping.
The kernel never tells userspace what key it uses for this.

This can cause the test to fail with messages like:

	protection_keys_64.2: pkey-helpers.h:132: _read_pkey_reg: Assertion `pkey_reg == shadow_pkey_reg' failed.

because the shadow was not updated with the new kernel-set value.

Forcibly update the shadow value immediately after an mprotect().

Fixes: 6af17cf89e99 ("x86/pkeys/selftests: Add PROT_EXEC test")
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Ram Pai <linuxram@us.ibm.com>
Cc: Sandipan Das <sandipan@linux.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Florian Weimer <fweimer@redhat.com>
Cc: "Desnes A. Nunes do Rosario" <desnesn@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Michal Suchanek <msuchanek@suse.de>
Cc: Shuah Khan <shuah@kernel.org>
Cc: x86@kernel.org
---

 b/tools/testing/selftests/vm/protection_keys.c |    7 +++++++
 1 file changed, 7 insertions(+)

diff -puN tools/testing/selftests/vm/protection_keys.c~selftests_vm_pkeys_Refill_shadow_register_after_implict_kernel_write-1 tools/testing/selftests/vm/protection_keys.c
--- a/tools/testing/selftests/vm/protection_keys.c~selftests_vm_pkeys_Refill_shadow_register_after_implict_kernel_write-1	2021-06-11 09:41:33.508468061 -0700
+++ b/tools/testing/selftests/vm/protection_keys.c	2021-06-11 09:41:33.517468061 -0700
@@ -1448,6 +1448,13 @@ void test_implicit_mprotect_exec_only_me
 	ret = mprotect(p1, PAGE_SIZE, PROT_EXEC);
 	pkey_assert(!ret);
 
+	/*
+	 * Reset the shadow, assuming that the above mprotect()
+	 * correctly changed PKRU, but to an unknown value since
+	 * the actual alllocated pkey is unknown.
+	 */
+	shadow_pkey_reg = __read_pkey_reg();
+
 	dprintf2("pkey_reg: %016llx\n", read_pkey_reg());
 
 	/* Make sure this is an *instruction* fault */
_


  parent reply	other threads:[~2021-06-11 16:42 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-11 16:41 [PATCH 0/4] selftests/vm/pkeys: Bug fixes and a new test Dave Hansen
2021-06-11 16:41 ` Dave Hansen
2021-06-11 16:41 ` [PATCH 1/4] selftests/vm/pkeys: Fix alloc_random_pkey() to make it really, really random Dave Hansen
2021-06-11 16:41   ` Dave Hansen
2021-06-11 16:41 ` [PATCH 2/4] selftests/vm/pkeys: Handle negative sys_pkey_alloc() return code Dave Hansen
2021-06-11 16:41   ` Dave Hansen
2021-06-11 16:42 ` Dave Hansen [this message]
2021-06-11 16:42   ` [PATCH 3/4] selftests/vm/pkeys: Refill shadow register after implicit kernel write Dave Hansen
2021-06-11 16:42 ` [PATCH 4/4] selftests/vm/pkeys: Exercise x86 XSAVE init state Dave Hansen
2021-06-11 16:42   ` Dave Hansen
2021-06-13  8:54 ` [PATCH 0/4] selftests/vm/pkeys: Bug fixes and a new test Aneesh Kumar K.V

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=20210611164200.EF76AB73@viggo.jf.intel.com \
    --to=dave.hansen@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=bauerman@linux.ibm.com \
    --cc=desnesn@linux.vnet.ibm.com \
    --cc=fweimer@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxram@us.ibm.com \
    --cc=mhocko@kernel.org \
    --cc=mingo@kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=msuchanek@suse.de \
    --cc=sandipan@linux.ibm.com \
    --cc=shuah@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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.