All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Chancellor <natechancellor@gmail.com>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Kees Cook <keescook@chromium.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	clang-built-linux <clang-built-linux@googlegroups.com>
Subject: Re: [PATCH] ubsan: Implement __ubsan_handle_alignment_assumption
Date: Tue, 12 Jan 2021 14:37:03 -0700	[thread overview]
Message-ID: <20210112213703.GA1376568@ubuntu-m3-large-x86> (raw)
In-Reply-To: <CAKwvOd=yrVKBn9TN2cP8SiB7A8=c2g41PyodKGJu+xEQwAmnDA@mail.gmail.com>

On Tue, Jan 12, 2021 at 01:15:42PM -0800, Nick Desaulniers wrote:
> On Tue, Jan 12, 2021 at 12:55 PM Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> >
> > When building ARCH=mips 32r2el_defconfig with CONFIG_UBSAN_ALIGNMENT:
> >
> > ld.lld: error: undefined symbol: __ubsan_handle_alignment_assumption
> > >>> referenced by slab.h:557 (include/linux/slab.h:557)
> > >>>               main.o:(do_initcalls) in archive init/built-in.a
> > >>> referenced by slab.h:448 (include/linux/slab.h:448)
> > >>>               do_mounts_rd.o:(rd_load_image) in archive init/built-in.a
> > >>> referenced by slab.h:448 (include/linux/slab.h:448)
> > >>>               do_mounts_rd.o:(identify_ramdisk_image) in archive init/built-in.a
> > >>> referenced 1579 more times
> >
> > Implement this for the kernel based on LLVM's
> > handleAlignmentAssumptionImpl because the kernel is not linked against
> > the compiler runtime.
> >
> > Link: https://github.com/ClangBuiltLinux/linux/issues/1245
> > Link: https://github.com/llvm/llvm-project/blob/llvmorg-11.0.1/compiler-rt/lib/ubsan/ubsan_handlers.cpp#L151-L190
> > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> > ---
> >  lib/ubsan.c | 28 ++++++++++++++++++++++++++++
> >  lib/ubsan.h |  6 ++++++
> >  2 files changed, 34 insertions(+)
> >
> > diff --git a/lib/ubsan.c b/lib/ubsan.c
> > index 3e3352f3d0da..a1e6cc9993f8 100644
> > --- a/lib/ubsan.c
> > +++ b/lib/ubsan.c
> > @@ -427,3 +427,31 @@ void __ubsan_handle_load_invalid_value(void *_data, void *val)
> >         ubsan_epilogue();
> >  }
> >  EXPORT_SYMBOL(__ubsan_handle_load_invalid_value);
> > +
> > +void __ubsan_handle_alignment_assumption(void *_data, unsigned long ptr,
> > +                                        unsigned long align,
> > +                                        unsigned long offset)
> > +{
> > +       struct alignment_assumption_data *data = _data;
> > +       unsigned long real_ptr;
> > +
> > +       if (suppress_report(&data->location))
> > +               return;
> > +
> > +       ubsan_prologue(&data->location, "alignment-assumption");
> > +
> > +       if (offset)
> > +               pr_err("assumption of %lu byte alignment (with offset of %lu byte) for pointer of type %s failed",
> > +                      align, offset, data->type->type_name);
> > +       else
> > +               pr_err("assumption of %lu byte alignment for pointer of type %s failed",
> > +                      align, data->type->type_name);
> > +
> > +       real_ptr = ptr - offset;
> > +       pr_err("%saddress is %lu aligned, misalignment offset is %lu bytes",
> > +              offset ? "offset " : "", BIT(ffs(real_ptr)),
> 
> if real_ptr is an unsigned long, do we want to use `__ffs(real_ptr) +
> 1` here rather than ffs which takes an int?  It seems the kernel is
> missing a definition of ffsl. :(

Why the + 1? I think if we use __ffs (which it seems like we should), I
think that needs to become

BIT(real_ptr ? __ffs(real_ptr) : 0)

I have made that change locally and will send it for v2 in a day or so
to give Kees some time to check it out.

Thanks for the review!
Nathan

  reply	other threads:[~2021-01-12 21:41 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-12 20:55 [PATCH] ubsan: Implement __ubsan_handle_alignment_assumption Nathan Chancellor
2021-01-12 21:15 ` Nick Desaulniers
2021-01-12 21:37   ` Nathan Chancellor [this message]
2021-01-12 21:53     ` Nick Desaulniers
2021-01-12 22:06       ` Nathan Chancellor
2021-01-12 23:56         ` Kees Cook
2021-01-13  0:12 ` [PATCH v2] " Nathan Chancellor
2021-01-27 22:44   ` [PATCH v3] " Nathan Chancellor
2021-01-27 22:54     ` Nick Desaulniers
2021-01-13  0:18 ` [PATCH] " kernel test robot
2021-01-13  0:18   ` kernel test robot
2021-01-13  0:39 ` kernel test robot
2021-01-13  0:39   ` kernel test robot
2021-01-13  1:31   ` Nathan Chancellor
2021-01-13  1:39     ` Nick Desaulniers
2021-01-13  1:39       ` Nick Desaulniers
2021-01-13  1:39       ` Nick Desaulniers
2021-01-27 22:26       ` Nick Desaulniers
2021-01-27 22:26         ` Nick Desaulniers
2021-01-27 22:26         ` Nick Desaulniers

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=20210112213703.GA1376568@ubuntu-m3-large-x86 \
    --to=natechancellor@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=clang-built-linux@googlegroups.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ndesaulniers@google.com \
    /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.