summaryrefslogtreecommitdiff
path: root/tools/testing/selftests/powerpc/security/mitigation-patching.sh
AgeCommit message (Collapse)Author
2021-12-16selftests/powerpc: skip tests for unavailable mitigations.Sachin Sant
Mitigation patching test iterates over a set of mitigations irrespective of whether a certain mitigation is supported/available in the kernel. This causes following messages on a kernel where some mitigations are unavailable: Spawned threads enabling/disabling mitigations ... cat: entry_flush: No such file or directory cat: uaccess_flush: No such file or directory Waiting for timeout ... OK This patch adds a check for available mitigations in the kernel. Reported-by: Nageswara R Sastry <rnsastry@linux.ibm.com> Signed-off-by: Sachin Sant <sachinp@linux.vnet.ibm.com> Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com> Reviewed-by: Russell Currey <ruscur@russell.cc> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/163941374362.36967.18016981579099073379.sendpatchset@1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa
2021-10-27selftests/powerpc: Use date instead of EPOCHSECONDS in mitigation-patching.shRussell Currey
The EPOCHSECONDS environment variable was added in bash 5.0 (released 2019). Some distributions of the "stable" and "long-term" variety ship older versions of bash than this, so swap to using the date command instead. "%s" was added to coreutils `date` in 1993 so we should be good, but who knows, it is a GNU extension and not part of the POSIX spec for `date`. Signed-off-by: Russell Currey <ruscur@russell.cc> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20211025102436.19177-1-ruscur@russell.cc
2021-05-17selftests/powerpc: Add test of mitigation patchingMichael Ellerman
We recently discovered some of our mitigation patching was not safe against other CPUs running concurrently. Add a test which enable/disables all mitigations in a tight loop while also running some stress load. On an unpatched system this almost always leads to an oops and panic/reboot, but we also check if the kernel becomes tainted in case we have a non-fatal oops. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210507064225.1556312-1-mpe@ellerman.id.au