[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 2 Feb 2023 19:10:00 +0000
From: Kees Cook <keescook@...omium.org>
To: John Stultz <jstultz@...gle.com>,
Sami Tolvanen <samitolvanen@...gle.com>,
Ard Biesheuvel <ardb@...nel.org>
Cc: Yongqin Liu <yongqin.liu@...aro.org>,
Vlastimil Babka <vbabka@...e.cz>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Rasmus Villemoes <rasmus.villemoes@...vas.dk>,
Thomas Gleixner <tglx@...utronix.de>,
Jason Gunthorpe <jgg@...pe.ca>, Nishanth Menon <nm@...com>,
Michael Kelley <mikelley@...rosoft.com>,
Dan Williams <dan.j.williams@...el.com>,
Won Chung <wonchung@...gle.com>,
David Gow <davidgow@...gle.com>,
Christoph Lameter <cl@...ux.com>,
Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Roman Gushchin <roman.gushchin@...ux.dev>,
Hyeonggon Yoo <42.hyeyoo@...il.com>,
Guenter Roeck <linux@...ck-us.net>,
Andy Shevchenko <andriy.shevchenko@...el.com>,
Paolo Abeni <pabeni@...hat.com>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Nathan Chancellor <nathan@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Tom Rix <trix@...hat.com>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, linux-hardening@...r.kernel.org,
llvm@...ts.linux.dev, Sumit Semwal <sumit.semwal@...aro.org>
Subject: Re: [PATCH 5/6] driver core: Add __alloc_size hint to devm allocators
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?
--
Kees Cook
Powered by blists - more mailing lists