linux-hardening - Re: [PATCH 5/6] driver core: Add __alloc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 2 Feb 2023 11:31:01 -0800
From:   Nick Desaulniers <ndesaulniers@...gle.com>
To:     Ard Biesheuvel <ardb@...nel.org>
Cc:     Kees Cook <keescook@...omium.org>,
        John Stultz <jstultz@...gle.com>,
        Sami Tolvanen <samitolvanen@...gle.com>,
        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>,
        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 2, 2023 at 11:20 AM Ard Biesheuvel <ardb@...nel.org> wrote:
>
> On Thu, 2 Feb 2023 at 20:10, Kees Cook <keescook@...omium.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