All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Popescu <georgepope@google.com>
To: Kees Cook <keescook@chromium.org>
Cc: maz@kernel.org, catalin.marinas@arm.com, will@kernel.org,
	masahiroy@kernel.org, michal.lkml@markovi.net,
	linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org,
	linux-kbuild@vger.kernel.org, clang-built-linux@googlegroups.com,
	james.morse@arm.com, julien.thierry.kdev@gmail.com,
	suzuki.poulose@arm.com, natechancellor@gmail.com,
	ndesaulniers@google.com, dbrazdil@google.com, broonie@kernel.org,
	maskray@google.com, ascull@google.com, akpm@linux-foundation.org,
	dvyukov@google.com, elver@google.com, tglx@linutronix.de,
	arnd@arndb.de
Subject: Re: [PATCH 06/14] Fix CFLAGS for UBSAN_BOUNDS on Clang
Date: Tue, 15 Sep 2020 10:24:58 +0000	[thread overview]
Message-ID: <20200915102458.GA1650630@google.com> (raw)
In-Reply-To: <202009141509.CDDC8C8@keescook>

On Mon, Sep 14, 2020 at 03:13:14PM -0700, Kees Cook wrote:
> On Mon, Sep 14, 2020 at 05:27:42PM +0000, George-Aurelian Popescu wrote:
> > From: George Popescu <georgepope@google.com>
> > 
> > When the kernel is compiled with Clang, UBSAN_BOUNDS inserts a brk after
> > the handler call, preventing it from printing any information processed
> > inside the buffer.
> > For Clang -fsanitize=bounds expands to -fsanitize=array-bounds and
> > -fsanitize=local-bounds, and the latter adds a brk after the handler
> > call
> 
> That sounds like a compiler bug?
Actually in clang 12 documentation is written that -fsanitize=bounds
expands to that. GCC  doesn't have those two options, only the
-fsanitize=bounds which looks similar to -fsanitize=array-bounds from
clang. So I don't see it as a compiler bug, just a misuse of flags.

> > Signed-off-by: George Popescu <georgepope@google.com>
> > ---
> >  scripts/Makefile.ubsan | 9 ++++++++-
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/scripts/Makefile.ubsan b/scripts/Makefile.ubsan
> > index 27348029b2b8..3d15ac346c97 100644
> > --- a/scripts/Makefile.ubsan
> > +++ b/scripts/Makefile.ubsan
> > @@ -4,7 +4,14 @@ ifdef CONFIG_UBSAN_ALIGNMENT
> >  endif
> >  
> >  ifdef CONFIG_UBSAN_BOUNDS
> > -      CFLAGS_UBSAN += $(call cc-option, -fsanitize=bounds)
> > +      # For Clang -fsanitize=bounds translates to -fsanitize=array-bounds and
> > +      # -fsanitize=local-bounds; the latter adds a brk right after the
> > +      # handler is called.
> > +      ifdef CONFIG_CC_IS_CLANG
> > +            CFLAGS_UBSAN += $(call cc-option, -fsanitize=array-bounds)
> 
> This would mean losing the local-bounds coverage? Isn't that for locally
> defined arrays on the stack?
This would mean losing the local-bounds coverage. I tried to  test it without
local-bounds and with a locally defined array on the stack and it works fine
(the handler is called and the error reported). For me it feels like
--array-bounds and --local-bounds are triggered for the same type of
undefined_behaviours but they are handling them different.

> > +      else
> > +            CFLAGS_UBSAN += $(call cc-option, -fsanitize=bounds)
> > +      endif
> >  endif
> >  
> >  ifdef CONFIG_UBSAN_MISC
> > -- 
> > 2.28.0.618.gf4bc123cb7-goog
> > 
> 
> --
Thanks,
George

WARNING: multiple messages have this Message-ID (diff)
From: George Popescu <georgepope@google.com>
To: Kees Cook <keescook@chromium.org>
Cc: tglx@linutronix.de, catalin.marinas@arm.com, will@kernel.org,
	kvmarm@lists.cs.columbia.edu, maskray@google.com, maz@kernel.org,
	masahiroy@kernel.org, clang-built-linux@googlegroups.com,
	linux-arm-kernel@lists.infradead.org, elver@google.com,
	arnd@arndb.de, linux-kbuild@vger.kernel.org, broonie@kernel.org,
	natechancellor@gmail.com, dvyukov@google.com,
	michal.lkml@markovi.net, ndesaulniers@google.com,
	linux-kernel@vger.kernel.org, akpm@linux-foundation.org
Subject: Re: [PATCH 06/14] Fix CFLAGS for UBSAN_BOUNDS on Clang
Date: Tue, 15 Sep 2020 10:24:58 +0000	[thread overview]
Message-ID: <20200915102458.GA1650630@google.com> (raw)
In-Reply-To: <202009141509.CDDC8C8@keescook>

On Mon, Sep 14, 2020 at 03:13:14PM -0700, Kees Cook wrote:
> On Mon, Sep 14, 2020 at 05:27:42PM +0000, George-Aurelian Popescu wrote:
> > From: George Popescu <georgepope@google.com>
> > 
> > When the kernel is compiled with Clang, UBSAN_BOUNDS inserts a brk after
> > the handler call, preventing it from printing any information processed
> > inside the buffer.
> > For Clang -fsanitize=bounds expands to -fsanitize=array-bounds and
> > -fsanitize=local-bounds, and the latter adds a brk after the handler
> > call
> 
> That sounds like a compiler bug?
Actually in clang 12 documentation is written that -fsanitize=bounds
expands to that. GCC  doesn't have those two options, only the
-fsanitize=bounds which looks similar to -fsanitize=array-bounds from
clang. So I don't see it as a compiler bug, just a misuse of flags.

> > Signed-off-by: George Popescu <georgepope@google.com>
> > ---
> >  scripts/Makefile.ubsan | 9 ++++++++-
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/scripts/Makefile.ubsan b/scripts/Makefile.ubsan
> > index 27348029b2b8..3d15ac346c97 100644
> > --- a/scripts/Makefile.ubsan
> > +++ b/scripts/Makefile.ubsan
> > @@ -4,7 +4,14 @@ ifdef CONFIG_UBSAN_ALIGNMENT
> >  endif
> >  
> >  ifdef CONFIG_UBSAN_BOUNDS
> > -      CFLAGS_UBSAN += $(call cc-option, -fsanitize=bounds)
> > +      # For Clang -fsanitize=bounds translates to -fsanitize=array-bounds and
> > +      # -fsanitize=local-bounds; the latter adds a brk right after the
> > +      # handler is called.
> > +      ifdef CONFIG_CC_IS_CLANG
> > +            CFLAGS_UBSAN += $(call cc-option, -fsanitize=array-bounds)
> 
> This would mean losing the local-bounds coverage? Isn't that for locally
> defined arrays on the stack?
This would mean losing the local-bounds coverage. I tried to  test it without
local-bounds and with a locally defined array on the stack and it works fine
(the handler is called and the error reported). For me it feels like
--array-bounds and --local-bounds are triggered for the same type of
undefined_behaviours but they are handling them different.

> > +      else
> > +            CFLAGS_UBSAN += $(call cc-option, -fsanitize=bounds)
> > +      endif
> >  endif
> >  
> >  ifdef CONFIG_UBSAN_MISC
> > -- 
> > 2.28.0.618.gf4bc123cb7-goog
> > 
> 
> --
Thanks,
George
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

WARNING: multiple messages have this Message-ID (diff)
From: George Popescu <georgepope@google.com>
To: Kees Cook <keescook@chromium.org>
Cc: tglx@linutronix.de, catalin.marinas@arm.com, will@kernel.org,
	kvmarm@lists.cs.columbia.edu, maskray@google.com, maz@kernel.org,
	masahiroy@kernel.org, suzuki.poulose@arm.com,
	clang-built-linux@googlegroups.com,
	linux-arm-kernel@lists.infradead.org, dbrazdil@google.com,
	julien.thierry.kdev@gmail.com, elver@google.com, arnd@arndb.de,
	linux-kbuild@vger.kernel.org, broonie@kernel.org,
	ascull@google.com, natechancellor@gmail.com, dvyukov@google.com,
	michal.lkml@markovi.net, ndesaulniers@google.com,
	linux-kernel@vger.kernel.org, james.morse@arm.com,
	akpm@linux-foundation.org
Subject: Re: [PATCH 06/14] Fix CFLAGS for UBSAN_BOUNDS on Clang
Date: Tue, 15 Sep 2020 10:24:58 +0000	[thread overview]
Message-ID: <20200915102458.GA1650630@google.com> (raw)
In-Reply-To: <202009141509.CDDC8C8@keescook>

On Mon, Sep 14, 2020 at 03:13:14PM -0700, Kees Cook wrote:
> On Mon, Sep 14, 2020 at 05:27:42PM +0000, George-Aurelian Popescu wrote:
> > From: George Popescu <georgepope@google.com>
> > 
> > When the kernel is compiled with Clang, UBSAN_BOUNDS inserts a brk after
> > the handler call, preventing it from printing any information processed
> > inside the buffer.
> > For Clang -fsanitize=bounds expands to -fsanitize=array-bounds and
> > -fsanitize=local-bounds, and the latter adds a brk after the handler
> > call
> 
> That sounds like a compiler bug?
Actually in clang 12 documentation is written that -fsanitize=bounds
expands to that. GCC  doesn't have those two options, only the
-fsanitize=bounds which looks similar to -fsanitize=array-bounds from
clang. So I don't see it as a compiler bug, just a misuse of flags.

> > Signed-off-by: George Popescu <georgepope@google.com>
> > ---
> >  scripts/Makefile.ubsan | 9 ++++++++-
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/scripts/Makefile.ubsan b/scripts/Makefile.ubsan
> > index 27348029b2b8..3d15ac346c97 100644
> > --- a/scripts/Makefile.ubsan
> > +++ b/scripts/Makefile.ubsan
> > @@ -4,7 +4,14 @@ ifdef CONFIG_UBSAN_ALIGNMENT
> >  endif
> >  
> >  ifdef CONFIG_UBSAN_BOUNDS
> > -      CFLAGS_UBSAN += $(call cc-option, -fsanitize=bounds)
> > +      # For Clang -fsanitize=bounds translates to -fsanitize=array-bounds and
> > +      # -fsanitize=local-bounds; the latter adds a brk right after the
> > +      # handler is called.
> > +      ifdef CONFIG_CC_IS_CLANG
> > +            CFLAGS_UBSAN += $(call cc-option, -fsanitize=array-bounds)
> 
> This would mean losing the local-bounds coverage? Isn't that for locally
> defined arrays on the stack?
This would mean losing the local-bounds coverage. I tried to  test it without
local-bounds and with a locally defined array on the stack and it works fine
(the handler is called and the error reported). For me it feels like
--array-bounds and --local-bounds are triggered for the same type of
undefined_behaviours but they are handling them different.

> > +      else
> > +            CFLAGS_UBSAN += $(call cc-option, -fsanitize=bounds)
> > +      endif
> >  endif
> >  
> >  ifdef CONFIG_UBSAN_MISC
> > -- 
> > 2.28.0.618.gf4bc123cb7-goog
> > 
> 
> --
Thanks,
George

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-09-15 10:25 UTC|newest]

Thread overview: 98+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-14 17:27 [PATCH 00/14] UBSan Enablement for hyp/nVHE code George-Aurelian Popescu
2020-09-14 17:27 ` George-Aurelian Popescu
2020-09-14 17:27 ` George-Aurelian Popescu
2020-09-14 17:27 ` [PATCH 01/14] KVM: arm64: Enable UBSan instrumentation in nVHE hyp code George-Aurelian Popescu
2020-09-14 17:27   ` George-Aurelian Popescu
2020-09-14 17:27   ` George-Aurelian Popescu
2020-09-14 17:27 ` [PATCH 02/14] KVM: arm64: Define a macro for storing a value inside a per_cpu variable George-Aurelian Popescu
2020-09-14 17:27   ` George-Aurelian Popescu
2020-09-14 17:27   ` George-Aurelian Popescu
2020-09-14 17:27 ` [PATCH 03/14] KVM: arm64: Add support for creating and checking a logging buffer inside hyp/nVHE George-Aurelian Popescu
2020-09-14 17:27   ` George-Aurelian Popescu
2020-09-14 17:27   ` George-Aurelian Popescu
2020-10-01 10:07   ` Andrew Scull
2020-10-01 10:07     ` Andrew Scull
2020-10-01 10:07     ` Andrew Scull
2020-09-14 17:27 ` [PATCH 04/14] KVM: arm64: Add support for buffer usage George-Aurelian Popescu
2020-09-14 17:27   ` George-Aurelian Popescu
2020-09-14 17:27   ` George-Aurelian Popescu
2020-09-14 17:27 ` [PATCH 05/14] KVM: arm64: Define a buffer that can pass UBSan data from hyp/nVHE to kernel George-Aurelian Popescu
2020-09-14 17:27   ` George-Aurelian Popescu
2020-09-14 17:27   ` George-Aurelian Popescu
2020-09-15 13:25   ` George Popescu
2020-09-15 13:25     ` George Popescu
2020-09-15 13:25     ` George Popescu
2020-10-01 10:51   ` Andrew Scull
2020-10-01 10:51     ` Andrew Scull
2020-10-01 10:51     ` Andrew Scull
2020-09-14 17:27 ` [PATCH 06/14] Fix CFLAGS for UBSAN_BOUNDS on Clang George-Aurelian Popescu
2020-09-14 17:27   ` George-Aurelian Popescu
2020-09-14 17:27   ` George-Aurelian Popescu
2020-09-14 21:17   ` Nick Desaulniers
2020-09-14 21:17     ` Nick Desaulniers
2020-09-14 21:17     ` Nick Desaulniers
2020-09-14 22:13   ` Kees Cook
2020-09-14 22:13     ` Kees Cook
2020-09-14 22:13     ` Kees Cook
2020-09-15 10:24     ` George Popescu [this message]
2020-09-15 10:24       ` George Popescu
2020-09-15 10:24       ` George Popescu
2020-09-15 11:18       ` Marco Elver
2020-09-15 11:18         ` Marco Elver
2020-09-15 11:18         ` Marco Elver
2020-09-15 12:01         ` George Popescu
2020-09-15 12:01           ` George Popescu
2020-09-15 12:01           ` George Popescu
2020-09-15 17:32           ` Marco Elver
2020-09-15 17:32             ` Marco Elver
2020-09-15 17:32             ` Marco Elver
2020-09-16  7:40             ` George Popescu
2020-09-16  7:40               ` George Popescu
2020-09-16  7:40               ` George Popescu
2020-09-16  8:32               ` Marco Elver
2020-09-16  8:32                 ` Marco Elver
2020-09-16  8:32                 ` Marco Elver
2020-09-16 12:14                 ` George Popescu
2020-09-16 12:14                   ` George Popescu
2020-09-16 13:40                   ` Marco Elver
2020-09-16 13:40                     ` Marco Elver
2020-09-16 13:40                     ` Marco Elver
2020-09-17  6:37                     ` Marco Elver
2020-09-17  6:37                       ` Marco Elver
2020-09-17  6:37                       ` Marco Elver
2020-09-17 11:35                       ` George Popescu
2020-09-17 11:35                         ` George Popescu
2020-09-17 11:35                         ` George Popescu
2020-09-17 22:21                         ` Kees Cook
2020-09-17 22:21                           ` Kees Cook
2020-09-17 22:21                           ` Kees Cook
2020-09-17 22:17       ` Kees Cook
2020-09-17 22:17         ` Kees Cook
2020-09-17 22:17         ` Kees Cook
2020-09-14 17:27 ` [PATCH 07/14] KVM: arm64: Enable UBSAN_BOUNDS for the both the kernel and hyp/nVHE George-Aurelian Popescu
2020-09-14 17:27   ` George-Aurelian Popescu
2020-09-14 17:27   ` George-Aurelian Popescu
2020-10-01 10:57   ` Andrew Scull
2020-10-01 10:57     ` Andrew Scull
2020-10-01 10:57     ` Andrew Scull
2020-09-14 17:27 ` [PATCH 08/14] KVM: arm64: Enable UBsan check for unreachable code inside hyp/nVHE code George-Aurelian Popescu
2020-09-14 17:27   ` George-Aurelian Popescu
2020-09-14 17:27   ` George-Aurelian Popescu
2020-09-14 17:27 ` [PATCH 09/14] KVM: arm64: Enable shift out of bounds undefined behaviour check for hyp/nVHE George-Aurelian Popescu
2020-09-14 17:27   ` George-Aurelian Popescu
2020-09-14 17:27   ` George-Aurelian Popescu
2020-09-14 17:27 ` [PATCH 10/14] KVM: arm64: __ubsan_handle_load_invalid_value hyp/nVHE implementation George-Aurelian Popescu
2020-09-14 17:27   ` George-Aurelian Popescu
2020-09-14 17:27   ` George-Aurelian Popescu
2020-09-14 17:27 ` [PATCH 11/14] KVM: arm64: Detect type mismatch undefined behaviour from hyp/nVHE code George-Aurelian Popescu
2020-09-14 17:27   ` George-Aurelian Popescu
2020-09-14 17:27   ` George-Aurelian Popescu
2020-09-14 17:27 ` [PATCH 12/14] KVM: arm64: Detect arithmetic overflow is inside hyp/nVHE George-Aurelian Popescu
2020-09-14 17:27   ` George-Aurelian Popescu
2020-09-14 17:27   ` George-Aurelian Popescu
2020-09-14 17:27 ` [PATCH 13/14] KVM: arm64: Enable the CONFIG_TEST UBSan for PKVM George-Aurelian Popescu
2020-09-14 17:27   ` George-Aurelian Popescu
2020-09-14 17:27   ` George-Aurelian Popescu
2020-09-14 17:27 ` [PATCH 14/14] DO NOT MERGE: Enable configs to test the patch series George-Aurelian Popescu
2020-09-14 17:27   ` George-Aurelian Popescu
2020-09-14 17:27   ` George-Aurelian Popescu

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=20200915102458.GA1650630@google.com \
    --to=georgepope@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=ascull@google.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=clang-built-linux@googlegroups.com \
    --cc=dbrazdil@google.com \
    --cc=dvyukov@google.com \
    --cc=elver@google.com \
    --cc=james.morse@arm.com \
    --cc=julien.thierry.kdev@gmail.com \
    --cc=keescook@chromium.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=maskray@google.com \
    --cc=maz@kernel.org \
    --cc=michal.lkml@markovi.net \
    --cc=natechancellor@gmail.com \
    --cc=ndesaulniers@google.com \
    --cc=suzuki.poulose@arm.com \
    --cc=tglx@linutronix.de \
    --cc=will@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.