[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aLqMAWTwDh5eXgUJ@tucnak>
Date: Fri, 5 Sep 2025 09:06:41 +0200
From: Jakub Jelinek <jakub@...hat.com>
To: Kees Cook <kees@...nel.org>
Cc: Qing Zhao <qing.zhao@...cle.com>, Andrew Pinski <pinskia@...il.com>,
Richard Biener <rguenther@...e.de>, Joseph Myers <josmyers@...hat.com>,
Jan Hubicka <hubicka@....cz>,
Richard Earnshaw <richard.earnshaw@....com>,
Richard Sandiford <richard.sandiford@....com>,
Marcus Shawcroft <marcus.shawcroft@....com>,
Kyrylo Tkachov <kyrylo.tkachov@....com>,
Kito Cheng <kito.cheng@...il.com>, Palmer Dabbelt <palmer@...belt.com>,
Andrew Waterman <andrew@...ive.com>,
Jim Wilson <jim.wilson.gcc@...il.com>,
Peter Zijlstra <peterz@...radead.org>,
Dan Li <ashimida.1990@...il.com>,
Sami Tolvanen <samitolvanen@...gle.com>,
Ramon de C Valle <rcvalle@...gle.com>,
Joao Moreira <joao@...rdrivepizza.com>,
Nathan Chancellor <nathan@...nel.org>,
Bill Wendling <morbo@...gle.com>, gcc-patches@....gnu.org,
linux-hardening@...r.kernel.org
Subject: Re: [PATCH v2 7/7] kcfi: Add regression test suite
On Thu, Sep 04, 2025 at 05:24:15PM -0700, Kees Cook wrote:
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/kcfi/kcfi-adjacency.c
> @@ -0,0 +1,73 @@
> +/* Test KCFI check/transfer adjacency - regression test for instruction
> + insertion. */
> +/* { dg-do compile } */
> +/* { dg-options "-fsanitize=kcfi -O2" } */
> +/* { dg-options "-fsanitize=kcfi -O2 -march=armv7-a -mfloat-abi=soft" { target arm32 } } */
For stuff like this you should be using dg-additional-options.
/* { dg-options "-fsanitize=kcfi -O2" } */
/* { dg-additional-options "-march=armv7-a -mfloat-abi=soft" { target arm32 } } */
(in various other tests too).
> +/* Should have KCFI instrumentation for all indirect calls. */
> +
> +/* x86_64: Complete KCFI check sequence should be present. */
> +/* { dg-final { scan-assembler {movl\t\$-?[0-9]+, %r1[01]d\n\taddl\t[^,]+, %r1[01]d\n\tje\t\.Lkcfi_call[0-9]+\n\.Lkcfi_trap[0-9]+:\n\tud2} { target x86_64-*-* } } } */
This at least needs
/* { dg-additional-options "-masm=att" { target x86_64-*-* } } */
because Intel syntax wouldn't match. Does this match with all possible
-march/-mtune settings?
Peope very often do test
make check RUNTESTFLAGS='--target_board=unix/-march=skylake-avx512'
etc. so if the test depends on a particular ISA or tuning, better
add it explicitly to dg-options.
Also, we try not to use triplets like x86_64-*-* but instead
{ i?86-*-* x86_64-*-* } && lp64
or
{ i?86-*-* x86_64-*-* } && { ! ia32 }
depending on whether it is only for -m64, or for both -m64 and -mx32,
because on some targets the multilib compiler is i?86-*-* defaulting
to -m32, on most obviously x86_64-*-* defaulting to -m64.
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/kcfi/kcfi-basics.c
> @@ -0,0 +1,101 @@
> +/* Test basic KCFI functionality - preamble generation. */
> +/* { dg-do compile } */
> +/* { dg-options "-fsanitize=kcfi" } */
> +/* { dg-options "-fsanitize=kcfi -falign-functions=16" { target x86_64-*-* } } */
> +/* { dg-options "-fsanitize=kcfi -march=armv7-a -mfloat-abi=soft" { target arm32 } } */
Again (and in many others).
> +/* x86_64: Should have 0 entry NOPs - function starts immediately with
> + pushq. */
> +/* { dg-final { scan-assembler {test_function:\n\.LFB[0-9]+:\n\t*\.cfi_startproc\n\t*pushq\t*%rbp} { target x86_64-*-* } } } */
> +/* { dg-final { scan-assembler-not {\t*\.weak\t*__kcfi_typeid_test_function\n} { target x86_64-*-* } } } */
.weak is ELF specific, not all targets have it, are the tests restricted to
targets that do support it and in this syntax? We have
/* { dg-require-weak "" } */
but that doesn't imply a particular function.
Also, not all configurations will support .cfi_* directives, that depends
both on command line parameters and on whether assembler supports those.
If you expect them in all tests, perhaps you should test for those in
kcfi.exp and not run the tests at all if the directives aren't supported
(or if weak isn't supported etc.).
Also, there are targets with different line endings, so usually one scans
for [\n\r]* instead of just \n. No idea why you're using \t*, the compiler
emits just one tab.
Jakub
Powered by blists - more mailing lists