Commit Graph

11 Commits

Author SHA1 Message Date
Nico Pache 47395c4d65 Revert "kunit: memcpy: Split slow memcpy tests into MEMCPY_SLOW_KUNIT_TEST"
commit acd80cdcee17eb770fcb2b0dc659b78f369d8c01
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Thu Mar 14 08:12:00 2024 -0700

    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>

JIRA: https://issues.redhat.com/browse/RHEL-39303
Signed-off-by: Nico Pache <npache@redhat.com>
2024-07-31 20:32:29 -06:00
Nico Pache 2ba9ef0995 lib: memcpy_kunit: Fix an invalid format specifier in an assertion msg
commit 0a549ed22c3c7cc6da5c5f5918efd019944489a5
Author: David Gow <davidgow@google.com>
Date:   Wed Feb 21 17:27:16 2024 +0800

    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>

JIRA: https://issues.redhat.com/browse/RHEL-39303
Signed-off-by: Nico Pache <npache@redhat.com>
2024-07-31 20:32:29 -06:00
Prarit Bhargava 45f2995d6a x86/mem: Move memmove to out of line assembler
JIRA: https://issues.redhat.com/browse/RHEL-25415

commit bce5a1e8a34006a5e80213ede5e5c465d53f1dce
Author: Nick Desaulniers <ndesaulniers@google.com>
Date:   Tue Oct 18 10:21:55 2022 -0700

    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 9599ec0471 ("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

Signed-off-by: Prarit Bhargava <prarit@redhat.com>
2024-03-20 09:42:47 -04:00
Nico Pache 6029420a1d kunit: memcpy: Mark tests as slow using test attributes
commit d055c6a2cc162fa3fe23d0a88a279baf46abe85d
Author: Rae Moar <rmoar@google.com>
Date:   Tue Jul 25 21:25:17 2023 +0000

    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>

JIRA: https://issues.redhat.com/browse/RHEL-5618
Signed-off-by: Nico Pache <npache@redhat.com>
2023-11-02 15:26:58 -06:00
Nico Pache b4dd261fe0 kunit: memcpy: Split slow memcpy tests into MEMCPY_SLOW_KUNIT_TEST
Conflicts:
       lib/Kconfig.debug: unexpected neighboring config

commit 4acf1de35f41549e60c3c02a8defa7cb95eabdf2
Author: Kees Cook <keescook@chromium.org>
Date:   Fri Jan 6 19:47:05 2023 -0800

    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>

JIRA: https://issues.redhat.com/browse/RHEL-5618
Signed-off-by: Nico Pache <npache@redhat.com>
2023-11-02 15:26:55 -06:00
Nico Pache fd8eeb5c9a kunit/memcpy: Add dynamic size and window tests
commit 96fce387d58fa8eae6e8d9b1ecdfbc18292d7a68
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Sep 28 14:17:05 2022 -0700

    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>

JIRA: https://issues.redhat.com/browse/RHEL-5618
Signed-off-by: Nico Pache <npache@redhat.com>
2023-11-02 15:26:54 -06:00
Josef Oskera 9140be7222 kunit/memcpy: Avoid pathological compile-time string size
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2139493

commit 66cb2a36a96f6facbcb4ef1db967b8e9ea6910fe
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Sep 7 16:27:06 2022 -0700

    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)));     \n    include/linux/minmax.h:32:39: note: in definition of macro '__cmp_once'
       32 |                 typeof(y) unique_y = (y);               \n          |                                       ^
    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)));     \n          |                           ^~~
    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>

Signed-off-by: Josef Oskera <joskera@redhat.com>
2022-12-11 02:15:17 +01:00
Josef Oskera 5e1b428c6e string: Introduce strtomem() and strtomem_pad()
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2139493

commit dfbafa70bde26c40615f8c538ce68dac82a64fb4
Author: Kees Cook <keescook@chromium.org>
Date:   Fri Aug 26 11:04:43 2022 -0700

    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>

Signed-off-by: Josef Oskera <joskera@redhat.com>
2022-12-10 23:19:13 +01:00
Íñigo Huguet 5cc3b81ae2 string.h: Introduce memset_startat() for wiping trailing members and padding
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2077839

commit 6dbefad40815a61aecbcf9b552e87ef57ab8cc7d
Author: Kees Cook <keescook@chromium.org>
Date:   Mon May 17 20:16:57 2021 -0700

    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>

Signed-off-by: Íñigo Huguet <ihuguet@redhat.com>
2022-04-25 11:35:24 +02:00
Íñigo Huguet 48ed66d4c7 string.h: Introduce memset_after() for wiping trailing members/padding
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2077839

commit 4797632f4f1d8af4e0670adcb97bf9800dc3beca
Author: Kees Cook <keescook@chromium.org>
Date:   Mon May 17 20:16:57 2021 -0700

    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>

Signed-off-by: Íñigo Huguet <ihuguet@redhat.com>
2022-04-25 11:34:58 +02:00
Nico Pache 1f421f477e lib: Introduce CONFIG_MEMCPY_KUNIT_TEST
commit bb95ebbe89a7854368be061acefb22040fbcc486
Author: Kees Cook <keescook@chromium.org>
Date:   Fri Jun 25 17:45:15 2021 -0700

    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>

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2048326
Signed-off-by: Nico Pache <npache@redhat.com>
2022-02-02 18:47:40 -05:00