| Message ID | 1528937115-10132-11-git-send-email-linuxram@us.ibm.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
On 06/13/2018 05:45 PM, Ram Pai wrote: > When a key is freed, the key is no more effective. > Clear the bits corresponding to the pkey in the shadow > register. Otherwise it will carry some spurious bits > which can trigger false-positive asserts. ...--- a/tools/testing/selftests/vm/protection_keys.c > +++ b/tools/testing/selftests/vm/protection_keys.c > @@ -556,6 +556,9 @@ int alloc_pkey(void) > int sys_pkey_free(unsigned long pkey) > { > int ret = syscall(SYS_pkey_free, pkey); > + > + if (!ret) > + shadow_pkey_reg &= clear_pkey_flags(pkey, PKEY_DISABLE_ACCESS); > dprintf1("%s(pkey=%ld) syscall ret: %d\n", __func__, pkey, ret); > return ret; > } This would be great code for an actual application. But, I'm not immediately convinced we want sane, kind behavior in our selftest. x86 doesn't clear the hardware register at pkey_free, so wouldn't this cause the shadow and the hardware register to diverge? -- To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jun 20, 2018 at 07:49:31AM -0700, Dave Hansen wrote: > On 06/13/2018 05:45 PM, Ram Pai wrote: > > When a key is freed, the key is no more effective. > > Clear the bits corresponding to the pkey in the shadow > > register. Otherwise it will carry some spurious bits > > which can trigger false-positive asserts. > ...--- a/tools/testing/selftests/vm/protection_keys.c > > +++ b/tools/testing/selftests/vm/protection_keys.c > > @@ -556,6 +556,9 @@ int alloc_pkey(void) > > int sys_pkey_free(unsigned long pkey) > > { > > int ret = syscall(SYS_pkey_free, pkey); > > + > > + if (!ret) > > + shadow_pkey_reg &= clear_pkey_flags(pkey, PKEY_DISABLE_ACCESS); > > dprintf1("%s(pkey=%ld) syscall ret: %d\n", __func__, pkey, ret); > > return ret; > > } > > This would be great code for an actual application. But, I'm not > immediately convinced we want sane, kind behavior in our selftest. x86 > doesn't clear the hardware register at pkey_free, so wouldn't this cause > the shadow and the hardware register to diverge? Have deleted the code in the newer version. RP -- To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/tools/testing/selftests/vm/protection_keys.c b/tools/testing/selftests/vm/protection_keys.c index da4f5d5..42a91c7 100644 --- a/tools/testing/selftests/vm/protection_keys.c +++ b/tools/testing/selftests/vm/protection_keys.c @@ -556,6 +556,9 @@ int alloc_pkey(void) int sys_pkey_free(unsigned long pkey) { int ret = syscall(SYS_pkey_free, pkey); + + if (!ret) + shadow_pkey_reg &= clear_pkey_flags(pkey, PKEY_DISABLE_ACCESS); dprintf1("%s(pkey=%ld) syscall ret: %d\n", __func__, pkey, ret); return ret; }
When a key is freed, the key is no more effective. Clear the bits corresponding to the pkey in the shadow register. Otherwise it will carry some spurious bits which can trigger false-positive asserts. cc: Dave Hansen <dave.hansen@intel.com> cc: Florian Weimer <fweimer@redhat.com> Signed-off-by: Ram Pai <linuxram@us.ibm.com> --- tools/testing/selftests/vm/protection_keys.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)