linux-stable.git/tools/testing, branch v5.13.2

selftests/vm/pkeys: refill shadow register after implicit kernel write

2021-07-14T15:07:48+00:00

[ Upstream commit 6039ca254979694c5362dfebadd105e286c397bb ]

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().

Link: https://lkml.kernel.org/r/20210611164200.EF76AB73@viggo.jf.intel.com
Fixes: 6af17cf89e99 ("x86/pkeys/selftests: Add PROT_EXEC test")
Signed-off-by: Dave Hansen 
Signed-off-by: Thomas Gleixner 
Tested-by: Aneesh Kumar K.V 
Cc: Ram Pai 
Cc: Sandipan Das 
Cc: Florian Weimer 
Cc: "Desnes A. Nunes do Rosario" 
Cc: Ingo Molnar 
Cc: Thiago Jung Bauermann 
Cc: Michael Ellerman 
Cc: Michal Hocko 
Cc: Michal Suchanek 
Cc: Shuah Khan 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

selftests/vm/pkeys: handle negative sys_pkey_alloc() return code

2021-07-14T15:07:48+00:00

[ Upstream commit bf68294a2ec39ed7fec6a5b45d52034e6983157a ]

The alloc_pkey() sefltest function wraps the sys_pkey_alloc() system call.
On success, it updates its "shadow" register value because
sys_pkey_alloc() updates the real register.

But, the success check is wrong.  pkey_alloc() considers any non-zero
return code to indicate success where the pkey register will be modified.
This fails to take negative return codes into account.

Consider only a positive return value as a successful call.

Link: https://lkml.kernel.org/r/20210611164157.87AB4246@viggo.jf.intel.com
Fixes: 5f23f6d082a9 ("x86/pkeys: Add self-tests")
Reported-by: Thomas Gleixner 
Signed-off-by: Dave Hansen 
Tested-by: Aneesh Kumar K.V 
Cc: Ram Pai 
Cc: Sandipan Das 
Cc: Florian Weimer 
Cc: "Desnes A. Nunes do Rosario" 
Cc: Ingo Molnar 
Cc: Thiago Jung Bauermann 
Cc: Michael Ellerman 
Cc: Michal Hocko 
Cc: Michal Suchanek 
Cc: Shuah Khan 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

selftests/vm/pkeys: fix alloc_random_pkey() to make it really, really random

2021-07-14T15:07:48+00:00

[ Upstream commit f36ef407628835a7d7fb3d235b1f1aac7022d9a3 ]

Patch series "selftests/vm/pkeys: Bug fixes and a new test".

There has been a lot of activity on the x86 front around the XSAVE
architecture which is used to context-switch processor state (among other
things).  In addition, AMD has recently joined the protection keys club by
adding processor support for PKU.

The AMD implementation helped uncover a kernel bug around the PKRU "init
state", which actually applied to Intel's implementation but was just
harder to hit.  This series adds a test which is expected to help find
this class of bug both on AMD and Intel.  All the work around pkeys on x86
also uncovered a few bugs in the selftest.

This patch (of 4):

The "random" pkey allocation code currently does the good old:

	srand((unsigned int)time(NULL));

*But*, it unfortunately does this on every random pkey allocation.

There may be thousands of these a second.  time() has a one second
resolution.  So, each time alloc_random_pkey() is called, the PRNG is
*RESET* to time().  This is nasty.  Normally, if you do:

	srand();
	foo = rand();
	bar = rand();

You'll be quite guaranteed that 'foo' and 'bar' are different.  But, if
you do:

	srand(1);
	foo = rand();
	srand(1);
	bar = rand();

You are quite guaranteed that 'foo' and 'bar' are the *SAME*.  The recent
"fix" effectively forced the test case to use the same "random" pkey for
the whole test, unless the test run crossed a second boundary.

Only run srand() once at program startup.

This explains some very odd and persistent test failures I've been seeing.

Link: https://lkml.kernel.org/r/20210611164153.91B76FB8@viggo.jf.intel.com
Link: https://lkml.kernel.org/r/20210611164155.192D00FF@viggo.jf.intel.com
Fixes: 6e373263ce07 ("selftests/vm/pkeys: fix alloc_random_pkey() to make it really random")
Signed-off-by: Dave Hansen 
Signed-off-by: Thomas Gleixner 
Tested-by: Aneesh Kumar K.V 
Cc: Ram Pai 
Cc: Sandipan Das 
Cc: Florian Weimer 
Cc: "Desnes A. Nunes do Rosario" 
Cc: Ingo Molnar 
Cc: Thiago Jung Bauermann 
Cc: Michael Ellerman 
Cc: Michal Hocko 
Cc: Michal Suchanek 
Cc: Shuah Khan 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

selftests/sgx: remove checks for file execute permissions

2021-07-14T15:07:44+00:00

[ Upstream commit 4896df9d53ae5521f3ce83751e828ad70bc65c80 ]

The SGX selftests can fail for a bunch of non-obvious reasons
like 'noexec' permissions on /dev (which is the default *EVERYWHERE*
it seems).

A new test mistakenly also looked for +x permission on the
/dev/sgx_enclave.  File execute permissions really only apply to
the ability of execve() to work on a file, *NOT* on the ability
for an application to map the file with PROT_EXEC.  SGX needs to
mmap(PROT_EXEC), but doesn't need to execve() the device file.

Remove the check.

Fixes: 4284f7acb78b ("selftests/sgx: Improve error detection and messages")
Reported-by: Tim Gardner 
Cc: Jarkko Sakkinen 
Cc: Reinette Chatre 
Cc: Dave Hansen 
Cc: Shuah Khan 
Cc: linux-sgx@vger.kernel.org
Cc: linux-kselftest@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Tested-by: Reinette Chatre 
Signed-off-by: Dave Hansen 
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Shuah Khan 
Signed-off-by: Sasha Levin

selftests/ftrace: fix event-no-pid on 1-core machine

2021-07-14T15:07:44+00:00

[ Upstream commit 07b60713b57a8f952d029a2b6849d003d9c16108 ]

When running event-no-pid test on small machines (e.g. cloud 1-core
instance), other events might not happen:

    + cat trace
    + cnt=0
    + [ 0 -eq 0 ]
    + fail No other events were recorded
    [15] event tracing - restricts events based on pid notrace filtering [FAIL]

Schedule a simple sleep task to be sure that some other process events
get recorded.

Fixes: ebed9628f5c2 ("selftests/ftrace: Add test to test new set_event_notrace_pid file")
Signed-off-by: Krzysztof Kozlowski 
Acked-by: Steven Rostedt (VMware) 
Signed-off-by: Shuah Khan 
Signed-off-by: Sasha Levin

selftests: splice: Adjust for handler fallback removal

2021-07-14T15:07:35+00:00

[ Upstream commit 6daf076b717d189f4d02a303d45edd5732341ec1 ]

Some pseudo-filesystems do not have an explicit splice fops since adding
commit 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops"),
and now will reject attempts to use splice() in those filesystem paths.

Reported-by: kernel test robot 
Link: https://lore.kernel.org/lkml/202009181443.C2179FB@keescook/
Fixes: 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops")
Cc: Christoph Hellwig 
Cc: Shuah Khan 
Cc: linux-kselftest@vger.kernel.org
Signed-off-by: Kees Cook 
Signed-off-by: Shuah Khan 
Signed-off-by: Sasha Levin

tc-testing: fix list handling

2021-07-14T15:07:15+00:00

[ Upstream commit b4fd096cbb871340be837491fa1795864a48b2d9 ]

python lists don't have an 'add' method, but 'append'.

Fixes: 14e5175e9e04 ("tc-testing: introduce scapyPlugin for basic traffic")
Signed-off-by: Marcelo Ricardo Leitner 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

selftests: tls: fix chacha+bidir tests

2021-07-14T15:07:13+00:00

[ Upstream commit 291c53e4dacd3a2cc3152d8af37f07f8496c594a ]

ChaCha support did not adjust the bidirectional test.
We need to set up KTLS in reverse direction correctly,
otherwise these two cases will fail:

  tls.12_chacha.bidir
  tls.13_chacha.bidir

Fixes: 4f336e88a870 ("selftests/tls: add CHACHA20-POLY1305 to tls selftests")
Signed-off-by: Jakub Kicinski 
Acked-by: Vadim Fedorenko 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

selftests: tls: clean up uninitialized warnings

2021-07-14T15:07:12+00:00

[ Upstream commit baa00119d69e3318da8d99867fc1170ebddf09ce ]

A bunch of tests uses uninitialized stack memory as random
data to send. This is harmless but generates compiler warnings.
Explicitly init the buffers with random data.

Signed-off-by: Jakub Kicinski 
Acked-by: Vadim Fedorenko 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

selftests/bpf: Retry for EAGAIN in udp_redir_to_connected()

2021-07-14T15:07:11+00:00

[ Upstream commit a7e65fe7d8201527129206754db1a2db6a6b2fde ]

We use non-blocking sockets for testing sockmap redirections,
and got some random EAGAIN errors from UDP tests.

There is no guarantee the packet would be immediately available
to receive as soon as it is sent out, even on the local host.
For UDP, this is especially true because it does not lock the
sock during BH (unlike the TCP path). This is probably why we
only saw this error in UDP cases.

No matter how hard we try to make the queue empty check accurate,
it is always possible for recvmsg() to beat ->sk_data_ready().
Therefore, we should just retry in case of EAGAIN.

Fixes: d6378af615275 ("selftests/bpf: Add a test case for udp sockmap")
Reported-by: Jiang Wang 
Signed-off-by: Cong Wang 
Signed-off-by: Daniel Borkmann 
Acked-by: John Fastabend 
Acked-by: Jakub Sitnicki 
Link: https://lore.kernel.org/bpf/20210615021342.7416-3-xiyou.wangcong@gmail.com
Signed-off-by: Sasha Levin