On Thu, Feb 2, 2023 at 11:20 AM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > On Thu, 2 Feb 2023 at 20:10, Kees Cook <keescook@xxxxxxxxxxxx> 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
