All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marco Elver <elver@google.com>
To: Kees Cook <keescook@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Jarkko Sakkinen <jarkko@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Andrey Konovalov <andreyknvl@gmail.com>,
	Jiri Olsa <jolsa@kernel.org>,
	linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH] lib/test_ubsan: Silence compile-time array bounds warnings
Date: Fri, 3 Dec 2021 17:53:15 +0100	[thread overview]
Message-ID: <CANpmjNMCrLU0J3W+-=wihEaHXMytSfNy=iu-8-oO8JDvEUYAJw@mail.gmail.com> (raw)
In-Reply-To: <CE7F1A95-67C7-4BDA-B803-D93901EC2378@chromium.org>

On Fri, 3 Dec 2021 at 17:21, Kees Cook <keescook@chromium.org> wrote:
> On December 3, 2021 2:49:53 AM PST, Marco Elver <elver@google.com> wrote:
[...]
> >Are there other warnings or only the one for the fsanitize=object-size
> >test? I think this is fine if there are other warnings.
>
> I will double check, but I think it's only the object-size test, which seems to confirm my suspicion that -Warray-bounds provides sufficient coverage and object-size can be removed.
>
> I have another patch I intend to send today for the sk_buff/sk_buff_head issue, as -Warray-bounds warns for that as well.

Nice.

Do you want to send the patch removing UBSAN_OBJECT_SIZE, or shall I
do it? Perhaps it ties in better with the rest of your patches which I
have no state of.

> >But, if it's only about the fsanitize=object-size test, I'm going to
> >propose something more drastic. :-)
>
> Are there any cases where object-size does a run-time check that couldn't be done at compile time? That's the only reason I could see to keep it at this point, as -Warray-bounds can do the compile time checks.

No, I don't think so.

I stared at the LLVM code several times now, because I still couldn't
quite believe it myself, but I think it really doesn't do any dynamic
checks. Hence, why below I say it should have been a compiler warning.
As mentioned in the bugzilla bug, there's a FIXME in the LLVM code to
do a dynamic check with the help of fsanitize=address, but that never
happened. And that doesn't make much sense anyway if fsanitize=address
(viz. KASAN for us) is already on and does checking itself.

> >I had wanted to wait a bit and dig a little deeper, but I just posted
> >part of my analysis here:
> >https://bugzilla.kernel.org/show_bug.cgi?id=214861#c4
>
> Thanks, I'll refer to that in my sk_buff patch. It seems -Warray-bounds suffers from the same conservativism about object casts, which is frustrating on the one hand since the warning can be a false positive (cast vs access), but on the other, it does call attention to fragile arrangements which maybe could do with adjustment.
>
> >My proposal is to remove UBSAN_OBJECT_SIZE and its related tests. The
> >bugzilla bug goes into the details, but the TLDR is:
> >1. fsanitize=object-size is incomplete,
> >2. it should have been a compiler warning,
> >3. for everything else there is KASAN which detects real OOB,
> >4. for GCC we already disable UBSAN_OBJECT_SIZE.
>
> And maybe:
> 5. -Warray-bounds provides the same coverage and is about to be enabled globally.

Yup, in which case the compiler warning already exists and point #2
above is moot.

Thanks,
-- Marco

  reply	other threads:[~2021-12-03 16:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-03  9:30 [PATCH] lib/test_ubsan: Silence compile-time array bounds warnings Kees Cook
2021-12-03 10:49 ` Marco Elver
2021-12-03 16:21   ` Kees Cook
2021-12-03 16:53     ` Marco Elver [this message]
2021-12-03 23:07       ` Kees Cook

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='CANpmjNMCrLU0J3W+-=wihEaHXMytSfNy=iu-8-oO8JDvEUYAJw@mail.gmail.com' \
    --to=elver@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@gmail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=jarkko@kernel.org \
    --cc=jolsa@kernel.org \
    --cc=keescook@chromium.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.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.