linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Nick Desaulniers <ndesaulniers@google.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Kees Cook <keescook@chromium.org>,
	John Stultz <jstultz@google.com>,
	 Sami Tolvanen <samitolvanen@google.com>,
	Yongqin Liu <yongqin.liu@linaro.org>,
	 Vlastimil Babka <vbabka@suse.cz>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	 Rasmus Villemoes <rasmus.villemoes@prevas.dk>,
	Thomas Gleixner <tglx@linutronix.de>,
	 Jason Gunthorpe <jgg@ziepe.ca>, Nishanth Menon <nm@ti.com>,
	Michael Kelley <mikelley@microsoft.com>,
	 Dan Williams <dan.j.williams@intel.com>,
	Won Chung <wonchung@google.com>,  David Gow <davidgow@google.com>,
	Christoph Lameter <cl@linux.com>,
	Pekka Enberg <penberg@kernel.org>,
	 David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	 Roman Gushchin <roman.gushchin@linux.dev>,
	Hyeonggon Yoo <42.hyeyoo@gmail.com>,
	 Guenter Roeck <linux@roeck-us.net>,
	Andy Shevchenko <andriy.shevchenko@intel.com>,
	 Paolo Abeni <pabeni@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	 Nathan Chancellor <nathan@kernel.org>, Tom Rix <trix@redhat.com>,
	linux-kernel@vger.kernel.org,  linux-mm@kvack.org,
	linux-hardening@vger.kernel.org, llvm@lists.linux.dev,
	 Sumit Semwal <sumit.semwal@linaro.org>
Subject: Re: [PATCH 5/6] driver core: Add __alloc_size hint to devm allocators
Date: Thu, 2 Feb 2023 11:31:01 -0800	[thread overview]
Message-ID: <CAKwvOd=cuDb2NNK4uoUTYTLryFig47hvDQ08ta5XhjHsEhAG4A@mail.gmail.com> (raw)
In-Reply-To: <CAMj1kXHTwFH-OADZ5nZXfZyuH-x7XJL3DMyiz2Tr_nCuup+xFA@mail.gmail.com>

On Thu, Feb 2, 2023 at 11:20 AM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Thu, 2 Feb 2023 at 20:10, Kees Cook <keescook@chromium.org> wrote:
> >
> > On Thu, Feb 02, 2023 at 10:56:29AM -0800, John Stultz wrote:
> > > That said, making sense of the error message isn't completely trivial
> > > either. I've been seeing a few cases recently of some of the new
> > > compiler tooling (I pinged you earlier on a CFI one) causing errors
> > > that developers aren't really sure how to address.  I know sometimes
> > > it's not easy to surface the errors with context to what was wrong,
> > > but at the risk of intense bike shedding, is there some way to provide
> > > something like "Likely array bounds error" instead of just "BRK
> > > handler: Fatal exception"?
> >
> > Yeah, this is a result of the size trade-off that resulted in config
> > CONFIG_UBSAN_TRAP -- there ends up being no message about what went
> > wrong. I'd really like to have cleaner handling of this -- perhaps what
> > was done for KCFI could be applied to UBSAN as well, though this is an
> > area I don't know well myself. (i.e. encoding "this was a UBSAN trap"
> > in the trap itself.)
> >
> > Sami or Ard, is this something that could be improved for arm64?
> >
>
> -ENOCONTEXT, so I am going to assume this is about runtime
> instrumentation that needs some kind of 'panic' function which it will
> invoke if some condition is met that should never occur?
>
> We already use brk with different immediate values in the opcode, so
> the arch layer already has what we need. Is this a limitation in the
> compiler, perhaps, where it always emits the same brk opcode?

Yeah, we'd need to update both the compiler to produce the encoding,
and the kernel to recognize the encoding and do something special.

-- 
Thanks,
~Nick Desaulniers


  reply	other threads:[~2023-02-02 19:31 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-01 22:33 [PATCH 0/6] slab: Provide full coverage for __alloc_size attribute Kees Cook
2022-11-01 22:33 ` [PATCH 1/6] slab: Clean up SLOB vs kmalloc() definition Kees Cook
2022-11-03 13:32   ` Hyeonggon Yoo
2022-11-01 22:33 ` [PATCH 2/6] slab: Remove special-casing of const 0 size allocations Kees Cook
2022-11-03 14:00   ` Hyeonggon Yoo
2022-11-01 22:33 ` [PATCH 3/6] slab: Provide functional __alloc_size() hints to kmalloc_trace*() Kees Cook
2022-11-03 14:16   ` Hyeonggon Yoo
2022-11-04 18:22     ` Kees Cook
2022-11-05  1:09       ` Hyeonggon Yoo
2022-11-05  6:45         ` Kees Cook
2022-11-01 22:33 ` [PATCH 4/6] string: Add __realloc_size hint to kmemdup() Kees Cook
2022-11-02  9:26   ` Rasmus Villemoes
2022-11-02 19:40     ` Kees Cook
2022-11-01 22:33 ` [PATCH 5/6] driver core: Add __alloc_size hint to devm allocators Kees Cook
2023-02-01  7:36   ` Yongqin Liu
2023-02-01  8:11     ` John Stultz
2023-02-01  8:16       ` John Stultz
2023-02-01 18:41       ` Andy Shevchenko
2023-02-02 17:18       ` Kees Cook
2023-02-02 18:56         ` John Stultz
2023-02-02 19:10           ` Kees Cook
2023-02-02 19:20             ` Ard Biesheuvel
2023-02-02 19:31               ` Nick Desaulniers [this message]
2023-02-02 19:49                 ` Sami Tolvanen
2023-02-02 19:53                   ` Kees Cook
2023-02-02 20:11                     ` Sami Tolvanen
2023-02-02 20:43                       ` Kees Cook
2022-11-01 22:33 ` [PATCH 6/6] kunit/fortify: Validate __alloc_size attribute results Kees Cook
2022-11-29 12:24 ` [PATCH 0/6] slab: Provide full coverage for __alloc_size attribute Conor Dooley
2022-11-29 12:33   ` Arnd Bergmann
2022-12-01 17:15     ` 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='CAKwvOd=cuDb2NNK4uoUTYTLryFig47hvDQ08ta5XhjHsEhAG4A@mail.gmail.com' \
    --to=ndesaulniers@google.com \
    --cc=42.hyeyoo@gmail.com \
    --cc=andriy.shevchenko@intel.com \
    --cc=ardb@kernel.org \
    --cc=cl@linux.com \
    --cc=dan.j.williams@intel.com \
    --cc=davidgow@google.com \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=jgg@ziepe.ca \
    --cc=jstultz@google.com \
    --cc=keescook@chromium.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@roeck-us.net \
    --cc=llvm@lists.linux.dev \
    --cc=mikelley@microsoft.com \
    --cc=nathan@kernel.org \
    --cc=nm@ti.com \
    --cc=pabeni@redhat.com \
    --cc=penberg@kernel.org \
    --cc=rasmus.villemoes@prevas.dk \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=samitolvanen@google.com \
    --cc=sumit.semwal@linaro.org \
    --cc=tglx@linutronix.de \
    --cc=trix@redhat.com \
    --cc=vbabka@suse.cz \
    --cc=wonchung@google.com \
    --cc=yongqin.liu@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox