From: Ira Weiny <[email protected]>
When pkeys are not available on the hardware pkey_alloc() has specific
behavior which was previously untested.
Add test for this.
Cc: Dave Hansen <[email protected]>
Cc: Aneesh Kumar K.V <[email protected]>
Signed-off-by: Ira Weiny <[email protected]>
---
tools/testing/selftests/vm/protection_keys.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/tools/testing/selftests/vm/protection_keys.c b/tools/testing/selftests/vm/protection_keys.c
index 43e47de19c0d..4b733a75606f 100644
--- a/tools/testing/selftests/vm/protection_keys.c
+++ b/tools/testing/selftests/vm/protection_keys.c
@@ -1554,6 +1554,16 @@ void test_implicit_mprotect_exec_only_memory(int *ptr, u16 pkey)
do_not_expect_pkey_fault("plain read on recently PROT_EXEC area");
}
+void test_pkey_alloc_on_unsupported_cpu(void)
+{
+ int test_pkey = sys_pkey_alloc(0, 0);
+
+ dprintf1("pkey_alloc: %d (%d %s)\n", test_pkey, errno,
+ strerror(errno));
+ pkey_assert(test_pkey < 0);
+ pkey_assert(errno == ENOSPC);
+}
+
void test_mprotect_pkey_on_unsupported_cpu(int *ptr, u16 pkey)
{
int size = PAGE_SIZE;
@@ -1688,6 +1698,8 @@ int main(int argc, char *argv[])
printf("running PKEY tests for unsupported CPU/OS\n");
+ test_pkey_alloc_on_unsupported_cpu();
+
ptr = mmap(NULL, size, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE, -1, 0);
assert(ptr != (void *)-1);
test_mprotect_pkey_on_unsupported_cpu(ptr, 1);
--
2.35.1
On 6/10/2022 4:35 PM, [email protected] wrote:
>
> +void test_pkey_alloc_on_unsupported_cpu(void)
> +{
> + int test_pkey = sys_pkey_alloc(0, 0);
> +
> + dprintf1("pkey_alloc: %d (%d %s)\n", test_pkey, errno,
> + strerror(errno));
> + pkey_assert(test_pkey < 0);
> + pkey_assert(errno == ENOSPC);
This assert fails on a kernel with
CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS disabled.
Since pkey_alloc() is an architecture dependent syscall, ENOSYS is
returned instead of ENOSPC when support is disabled at compile time.
See kernel/sys_ni.c
This brings us to an interesting question.
Should we have different return error codes when compile support is
disabled vs when runtime support is missing?
Here is the current behavior for pkey_alloc():
No compile time support -> return ENOSYS
No runtime support (but compile time support present) -> return ENOSPC
I would think applications would prefer the same error code. But, I am
not sure if we can achieve this now due to ABI reasons.
> +}
> +
On 6/16/22 12:25, Sohil Mehta wrote:
> Should we have different return error codes when compile support is
> disabled vs when runtime support is missing?
It doesn't *really* matter. Programs have to be able to run on old
kernels which will return ENOSYS. So, _when_ new kernels return ENOSYS
or ENOSPC is pretty immaterial.