Commit c272612cb4a2 ("kunit: Taint the kernel when KUnit tests are run")
added a new taint flag for when in-kernel tests run. This commit adds
recognition of this new flag in kernel-chktaint.
Reviewed-by: David Gow <davidgow(a)google.com>
Signed-off-by: Joe Fradley <joefradley(a)google.com>
---
Changes in v2:
- based off of kselftest/kunit branch
- Added David's Reviewed-by tag
tools/debugging/kernel-chktaint | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/tools/debugging/kernel-chktaint b/tools/debugging/kernel-chktaint
index f1af27ce9f20..279be06332be 100755
--- a/tools/debugging/kernel-chktaint
+++ b/tools/debugging/kernel-chktaint
@@ -187,6 +187,7 @@ else
echo " * auxiliary taint, defined for and used by distros (#16)"
fi
+
T=`expr $T / 2`
if [ `expr $T % 2` -eq 0 ]; then
addout " "
@@ -195,6 +196,14 @@ else
echo " * kernel was built with the struct randomization plugin (#17)"
fi
+T=`expr $T / 2`
+if [ `expr $T % 2` -eq 0 ]; then
+ addout " "
+else
+ addout "N"
+ echo " * an in-kernel test (such as a KUnit test) has been run (#18)"
+fi
+
echo "For a more detailed explanation of the various taint flags see"
echo " Documentation/admin-guide/tainted-kernels.rst in the Linux kernel sources"
echo " or https://kernel.org/doc/html/latest/admin-guide/tainted-kernels.html"
--
2.37.1.595.g718a3a8f04-goog
Hi,
I'm hoping to at least get this into -next to see how noisy it ends up
being. I've tracked down several false positives that are getting fixed,
but I'd like to see this get wider testing. For details, see patch 1,
but this is the run-time half of the recent FORTIFY_SOURCE memcpy()
bounds checking work.
-Kees
Kees Cook (2):
fortify: Add run-time WARN for cross-field memcpy()
lkdtm: Update tests for memcpy() run-time warnings
drivers/misc/lkdtm/fortify.c | 96 +++++++++++++++++++++----
include/linux/fortify-string.h | 70 +++++++++++++++++-
tools/testing/selftests/lkdtm/tests.txt | 8 ++-
3 files changed, 155 insertions(+), 19 deletions(-)
--
2.34.1
Hello,
This is v2 of the patch series for TDX selftests.
It is based on v5.19-rc8 and Intel's V8 of the TDX host patches which
was proposed in https://lkml.org/lkml/2022/8/8/877
The tree can be found at
https://github.com/googleprodkernel/linux-cc/tree/selftests
Major changes vrom v1:
- rebased to v5.19
- added helpers for success and failure reporting
- added additional test cases
---
TDX stands for Trust Domain Extensions which isolates VMs from the
virtual-machine manager (VMM)/hypervisor and any other software on the
platform.
Intel has recently submitted a set of RFC patches for KVM support for
TDX and more information can be found on the latest TDX Support
Patches: https://lkml.org/lkml/2022/8/8/877
Due to the nature of the confidential computing environment that TDX
provides, it is very difficult to verify/test the KVM support. TDX
requires UEFI and the guest kernel to be enlightened which are all under
development.
We are working on a set of selftests to close this gap and be able to
verify the KVM functionality to support TDX lifecycle and GHCI [1]
interface.
We are looking for any feedback on:
- Patch series itself
- Any suggestion on how we should approach testing TDX functionality.
Does selftests seems reasonable or should we switch to using KVM
unit tests. I would be happy to get some perspective on how KVM unit
tests can help us more.
- Any test case or scenario that we should add.
- Anything else I have not thought of yet.
Current patch series provide the following capabilities:
- Provide helper functions to create a TD (Trusted Domain) using the KVM
ioctls
- Provide helper functions to create a guest image that can include any
testing code
- Provide helper functions and wrapper functions to write testing code
using GHCI interface
- Add a test case that verifies TDX life cycle
- Add a test case that verifies TDX GHCI port IO
TODOs:
- Use existing function to create page tables dynamically
(ie __virt_pg_map())
- Remove arbitrary defined magic numbers for data structure offsets
- Add TDVMCALL for error reporting
- Add additional test cases as some listed below
- Add #VE handlers to help testing more complicated test cases
---
Erdem Aktas (4):
KVM: selftests: Add support for creating non-default type VMs
KVM: selftest: Add helper functions to create TDX VMs
KVM: selftest: Adding TDX life cycle test.
KVM: selftest: Adding test case for TDX port IO
Roger Wang (1):
KVM: selftest: TDX: Add TDG.VP.INFO test
Ryan Afranji (2):
KVM: selftest: TDX: Verify the behavior when host consumes a TD
private memory
KVM: selftest: TDX: Add shared memory test
Sagi Shahar (10):
KVM: selftest: TDX: Add report_fatal_error test
KVM: selftest: TDX: Add basic TDX CPUID test
KVM: selftest: TDX: Add basic get_td_vmcall_info test
KVM: selftest: TDX: Add TDX IO writes test
KVM: selftest: TDX: Add TDX IO reads test
KVM: selftest: TDX: Add TDX MSR read/write tests
KVM: selftest: TDX: Add TDX HLT exit test
KVM: selftest: TDX: Add TDX MMIO reads test
KVM: selftest: TDX: Add TDX MMIO writes test
KVM: selftest: TDX: Add TDX CPUID TDVMCALL test
tools/testing/selftests/kvm/Makefile | 2 +
.../selftests/kvm/include/kvm_util_base.h | 12 +-
.../selftests/kvm/include/x86_64/processor.h | 1 +
tools/testing/selftests/kvm/lib/kvm_util.c | 6 +-
.../selftests/kvm/lib/x86_64/processor.c | 27 +
tools/testing/selftests/kvm/lib/x86_64/tdx.h | 495 +++++
.../selftests/kvm/lib/x86_64/tdx_lib.c | 373 ++++
.../selftests/kvm/x86_64/tdx_vm_tests.c | 1666 +++++++++++++++++
8 files changed, 2577 insertions(+), 5 deletions(-)
create mode 100644 tools/testing/selftests/kvm/lib/x86_64/tdx.h
create mode 100644 tools/testing/selftests/kvm/lib/x86_64/tdx_lib.c
create mode 100644 tools/testing/selftests/kvm/x86_64/tdx_vm_tests.c
--
2.37.2.789.g6183377224-goog
Note: this commit is intended to apply to mm-unstable, the commit being
fixed only exists in that branch for now.
Commit b4efb234e53cc60ccdc855190be9f35918687412 ("Kselftests: remove
support of libhugetlbfs from kselftests") removed the rule describing
how to build local_config.{h,mk}, but it left two references to these
files lingering around. The result is, none of the selftests could be
built due to dependencies with no rule for how to build them.
Signed-off-by: Axel Rasmussen <axelrasmussen(a)google.com>
---
tools/testing/selftests/vm/Makefile | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/tools/testing/selftests/vm/Makefile b/tools/testing/selftests/vm/Makefile
index b52f2cc51482..4ae879f70f4c 100644
--- a/tools/testing/selftests/vm/Makefile
+++ b/tools/testing/selftests/vm/Makefile
@@ -1,9 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
# Makefile for vm selftests
-LOCAL_HDRS += $(selfdir)/vm/local_config.h $(top_srcdir)/mm/gup_test.h
-
-include local_config.mk
+LOCAL_HDRS += $(top_srcdir)/mm/gup_test.h
uname_M := $(shell uname -m 2>/dev/null || echo not)
MACHINE ?= $(shell echo $(uname_M) | sed -e 's/aarch64.*/arm64/' -e 's/ppc64.*/ppc64/')
--
2.37.2.789.g6183377224-goog