All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: "Ricardo Cañuelo" <ricardo.canuelo@collabora.com>
Cc: kernel@collabora.com, shuah@kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH] selftests/lkdtm: Disable CONFIG_UBSAN_TRAP in test config
Date: Tue, 1 Aug 2023 17:26:44 -0700	[thread overview]
Message-ID: <202308011724.C76E2B90@keescook> (raw)
In-Reply-To: <20230801094329.1878928-1-ricardo.canuelo@collabora.com>

On Tue, Aug 01, 2023 at 11:43:29AM +0200, Ricardo Cañuelo wrote:
> The lkdtm selftest config fragment enables CONFIG_UBSAN_TRAP to make the
> ARRAY_BOUNDS test kill the calling process when an out-of-bound access
> is detected by UBSAN. However, after this [1] commit, UBSAN is triggered
> under many new scenarios that weren't detected before, such as in struct
> definitions with fixed-size trailing arrays used as flexible arrays. As
> a result, CONFIG_UBSAN_TRAP=y has become a very aggressive option to
> enable except for specific situations.

Yeah, that's fair. We need to actually get these issues reported and
TRAP doesn't help with that.

> 
> `make kselftest-merge` applies CONFIG_UBSAN_TRAP=y to the kernel config
> for all selftests, which makes many of them fail because of system hangs
> during boot.
> 
> This change removes the config option from the lkdtm kselftest and also
> the ARRAY_BOUNDS test to skip it rather than have it failing. If
> out-of-bound array accesses need to be checked, there's
> CONFIG_TEST_UBSAN for that.

I *think* instead, we can turn off TRAP but retain the ARRAY_BOUNDS
kselftest by looking for either WARN or TRAP results:

-ARRAY_BOUNDS
+ARRAY_BOUNDS call trace:|UBSAN: array-index-out-of-bounds

Can test that and send a v2?

-Kees

-- 
Kees Cook

  reply	other threads:[~2023-08-02  0:26 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-01  9:43 [PATCH] selftests/lkdtm: Disable CONFIG_UBSAN_TRAP in test config Ricardo Cañuelo
2023-08-02  0:26 ` Kees Cook [this message]
2023-08-02  6:18   ` Ricardo Cañuelo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202308011724.C76E2B90@keescook \
    --to=keescook@chromium.org \
    --cc=kernel@collabora.com \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=ricardo.canuelo@collabora.com \
    --cc=shuah@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.