#
acd80cdc |
|
14-Mar-2024 |
Guenter Roeck <linux@roeck-us.net> |
Revert "kunit: memcpy: Split slow memcpy tests into MEMCPY_SLOW_KUNIT_TEST" This reverts commit 4acf1de35f41549e60c3c02a8defa7cb95eabdf2. Commit d055c6a2cc16 ("kunit: memcpy: Mark tests as slow using test attributes") marks slow memcpy unit tests as slow. Since this commit, the tests can be disabled with a module parameter, and the configuration option to skip the slow tests is no longer needed. Revert the patch introducing it. Cc: David Gow <davidgow@google.com> Cc: Kees Cook <keescook@chromium.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20240314151200.2285314-1-linux@roeck-us.net Signed-off-by: Kees Cook <keescook@chromium.org>
|
#
0a549ed2 |
|
21-Feb-2024 |
David Gow <davidgow@google.com> |
lib: memcpy_kunit: Fix an invalid format specifier in an assertion msg The 'i' passed as an assertion message is a size_t, so should use '%zu', not '%d'. This was found by annotating the _MSG() variants of KUnit's assertions to let gcc validate the format strings. Fixes: bb95ebbe89a7 ("lib: Introduce CONFIG_MEMCPY_KUNIT_TEST") Signed-off-by: David Gow <davidgow@google.com> Tested-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Justin Stitt <justinstitt@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
|
#
d055c6a2 |
|
25-Jul-2023 |
Rae Moar <rmoar@google.com> |
kunit: memcpy: Mark tests as slow using test attributes Mark slow memcpy KUnit tests using test attributes. Tests marked as slow are as follows: memcpy_large_test, memmove_test, memmove_large_test, and memmove_overlap_test. These tests were the slowest of the memcpy tests and relatively slower to most other KUnit tests. Most of these tests are already skipped when CONFIG_MEMCPY_SLOW_KUNIT_TEST is not enabled. These tests can now be filtered using the KUnit test attribute filtering feature. Example: --filter "speed>slow". This will run only the tests that have speeds faster than slow. The slow attribute will also be outputted in KTAP. Note: This patch is intended to replace the use of CONFIG_MEMCPY_SLOW_KUNIT_TEST and to potentially deprecate this feature. This patch does not remove the config option but does add a note to the config definition commenting on this future shift. Reviewed-by: David Gow <davidgow@google.com> Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: Rae Moar <rmoar@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
|
#
4acf1de3 |
|
06-Jan-2023 |
Kees Cook <keescook@chromium.org> |
kunit: memcpy: Split slow memcpy tests into MEMCPY_SLOW_KUNIT_TEST Since the long memcpy tests may stall a system for tens of seconds in virtualized architecture environments, split those tests off under CONFIG_MEMCPY_SLOW_KUNIT_TEST so they can be separately disabled. Reported-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/lkml/20221226195206.GA2626419@roeck-us.net Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-and-tested-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: David Gow <davidgow@google.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Nathan Chancellor <nathan@kernel.org> Cc: linux-hardening@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org>
|
#
96fce387 |
|
28-Sep-2022 |
Kees Cook <keescook@chromium.org> |
kunit/memcpy: Add dynamic size and window tests The "side effects" memmove() test accidentally found[1] a corner case in the recent refactoring of the i386 assembly memmove(), but missed another corner case. Instead of hoping to get lucky next time, implement much more complete tests of memcpy() and memmove() -- especially the moving window overlap for memmove() -- which catches all the issues encountered and should catch anything new. [1] https://lore.kernel.org/lkml/CAKwvOdkaKTa2aiA90VzFrChNQM6O_ro+b7VWs=op70jx-DKaXA@mail.gmail.com Cc: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Kees Cook <keescook@chromium.org>
|
#
bce5a1e8 |
|
18-Oct-2022 |
Nick Desaulniers <ndesaulniers@google.com> |
x86/mem: Move memmove to out of line assembler When building ARCH=i386 with CONFIG_LTO_CLANG_FULL=y, it's possible (depending on additional configs which I have not been able to isolate) to observe a failure during register allocation: error: inline assembly requires more registers than available when memmove is inlined into tcp_v4_fill_cb() or tcp_v6_fill_cb(). memmove is quite large and probably shouldn't be inlined due to size alone. A noinline function attribute would be the simplest fix, but there's a few things that stand out with the current definition: In addition to having complex constraints that can't always be resolved, the clobber list seems to be missing %bx. By using numbered operands rather than symbolic operands, the constraints are quite obnoxious to refactor. Having a large function be 99% inline asm is a code smell that this function should simply be written in stand-alone out-of-line assembler. Moving this to out of line assembler guarantees that the compiler cannot inline calls to memmove. This has been done previously for 64b: commit 9599ec0471de ("x86-64, mem: Convert memmove() to assembly file and fix return value bug") That gives the opportunity for other cleanups like fixing the inconsistent use of tabs vs spaces and instruction suffixes, and the label 3 appearing twice. Symbolic operands, local labels, and additional comments would provide this code with a fresh coat of paint. Finally, add a test that tickles the `rep movsl` implementation to test it for correctness, since it has implicit operands. Suggested-by: Ingo Molnar <mingo@kernel.org> Suggested-by: David Laight <David.Laight@aculab.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Kees Cook <keescook@chromium.org> Tested-by: Kees Cook <keescook@chromium.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/all/20221018172155.287409-1-ndesaulniers%40google.com
|
#
66cb2a36 |
|
07-Sep-2022 |
Kees Cook <keescook@chromium.org> |
kunit/memcpy: Avoid pathological compile-time string size The memcpy() KUnit tests are trying to sanity-check run-time behaviors, but tripped compile-time warnings about a pathological condition of a too-small buffer being used for input. Avoid this by explicitly resizing the buffer, but leaving the string short. Avoid the following warning: lib/memcpy_kunit.c: In function 'strtomem_test': include/linux/string.h:303:42: warning: 'strnlen' specified bound 4 exceeds source size 3 [-Wstringop-overread] 303 | memcpy(dest, src, min(_dest_len, strnlen(src, _dest_len))); \ include/linux/minmax.h:32:39: note: in definition of macro '__cmp_once' 32 | typeof(y) unique_y = (y); \ | ^ include/linux/minmax.h:45:25: note: in expansion of macro '__careful_cmp' 45 | #define min(x, y) __careful_cmp(x, y, <) | ^~~~~~~~~~~~~ include/linux/string.h:303:27: note: in expansion of macro 'min' 303 | memcpy(dest, src, min(_dest_len, strnlen(src, _dest_len))); \ | ^~~ lib/memcpy_kunit.c:290:9: note: in expansion of macro 'strtomem' 290 | strtomem(wrap.output, input); | ^~~~~~~~ lib/memcpy_kunit.c:275:27: note: source object allocated here 275 | static const char input[] = "hi"; | ^~~~~ Reported-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/linux-mm/202209070728.o3stvgVt-lkp@intel.com Fixes: dfbafa70bde2 ("string: Introduce strtomem() and strtomem_pad()") Signed-off-by: Kees Cook <keescook@chromium.org>
|
#
dfbafa70 |
|
26-Aug-2022 |
Kees Cook <keescook@chromium.org> |
string: Introduce strtomem() and strtomem_pad() One of the "legitimate" uses of strncpy() is copying a NUL-terminated string into a fixed-size non-NUL-terminated character array. To avoid the weaknesses and ambiguity of intent when using strncpy(), provide replacement functions that explicitly distinguish between trailing padding and not, and require the destination buffer size be discoverable by the compiler. For example: struct obj { int foo; char small[4] __nonstring; char big[8] __nonstring; int bar; }; struct obj p; /* This will truncate to 4 chars with no trailing NUL */ strncpy(p.small, "hello", sizeof(p.small)); /* p.small contains 'h', 'e', 'l', 'l' */ /* This will NUL pad to 8 chars. */ strncpy(p.big, "hello", sizeof(p.big)); /* p.big contains 'h', 'e', 'l', 'l', 'o', '\0', '\0', '\0' */ When the "__nonstring" attributes are missing, the intent of the programmer becomes ambiguous for whether the lack of a trailing NUL in the p.small copy is a bug. Additionally, it's not clear whether the trailing padding in the p.big copy is _needed_. Both cases become unambiguous with: strtomem(p.small, "hello"); strtomem_pad(p.big, "hello", 0); See also https://github.com/KSPP/linux/issues/90 Expand the memcpy KUnit tests to include these functions. Cc: Wolfram Sang <wsa+renesas@sang-engineering.com> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Kees Cook <keescook@chromium.org>
|
#
6dbefad4 |
|
17-May-2021 |
Kees Cook <keescook@chromium.org> |
string.h: Introduce memset_startat() for wiping trailing members and padding A common idiom in kernel code is to wipe the contents of a structure starting from a given member. These open-coded cases are usually difficult to read and very sensitive to struct layout changes. Like memset_after(), introduce a new helper, memset_startat() that takes the target struct instance, the byte to write, and the member name where zeroing should start. Note that this doesn't zero padding preceding the target member. For those cases, memset_after() should be used on the preceding member. Cc: Steffen Klassert <steffen.klassert@secunet.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Francis Laniel <laniel_francis@privacyrequired.com> Cc: Vincenzo Frascino <vincenzo.frascino@arm.com> Cc: Daniel Axtens <dja@axtens.net> Cc: netdev@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org>
|
#
4797632f |
|
17-May-2021 |
Kees Cook <keescook@chromium.org> |
string.h: Introduce memset_after() for wiping trailing members/padding A common idiom in kernel code is to wipe the contents of a structure after a given member. This is especially useful in places where there is trailing padding. These open-coded cases are usually difficult to read and very sensitive to struct layout changes. Introduce a new helper, memset_after() that takes the target struct instance, the byte to write, and the member name after which the zeroing should start. Cc: Steffen Klassert <steffen.klassert@secunet.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Francis Laniel <laniel_francis@privacyrequired.com> Cc: Vincenzo Frascino <vincenzo.frascino@arm.com> Cc: Daniel Axtens <dja@axtens.net> Cc: netdev@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org>
|
#
bb95ebbe |
|
25-Jun-2021 |
Kees Cook <keescook@chromium.org> |
lib: Introduce CONFIG_MEMCPY_KUNIT_TEST Before changing anything about memcpy(), memmove(), and memset(), add run-time tests to check basic behaviors for any regressions. Signed-off-by: Kees Cook <keescook@chromium.org>
|