[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANpmjNM4pFHYRqmBLi0qUm8K2SroYWg7NFjreHffHvk0WW95kA@mail.gmail.com>
Date: Wed, 29 May 2024 20:30:20 +0200
From: Marco Elver <elver@...gle.com>
To: Gatlin Newhouse <gatlin.newhouse@...il.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
"H. Peter Anvin" <hpa@...or.com>, Kees Cook <keescook@...omium.org>,
Andrey Konovalov <andreyknvl@...il.com>, Andrey Ryabinin <ryabinin.a.a@...il.com>,
Nathan Chancellor <nathan@...nel.org>, Nick Desaulniers <ndesaulniers@...gle.com>,
Bill Wendling <morbo@...gle.com>, Justin Stitt <justinstitt@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>, Baoquan He <bhe@...hat.com>,
Rick Edgecombe <rick.p.edgecombe@...el.com>, Changbin Du <changbin.du@...wei.com>,
Pengfei Xu <pengfei.xu@...el.com>, Josh Poimboeuf <jpoimboe@...nel.org>, Xin Li <xin3.li@...el.com>,
Jason Gunthorpe <jgg@...pe.ca>, "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
linux-kernel@...r.kernel.org, kasan-dev@...glegroups.com,
linux-hardening@...r.kernel.org, llvm@...ts.linux.dev
Subject: Re: [PATCH] x86/traps: Enable UBSAN traps on x86
On Wed, 29 May 2024 at 20:17, Gatlin Newhouse <gatlin.newhouse@...il.com> wrote:
>
> On Wed, May 29, 2024 at 09:25:21AM UTC, Marco Elver wrote:
> > On Wed, 29 May 2024 at 04:20, Gatlin Newhouse <gatlin.newhouse@...il.com> wrote:
> > [...]
> > > if (regs->flags & X86_EFLAGS_IF)
> > > raw_local_irq_enable();
> > > - if (report_bug(regs->ip, regs) == BUG_TRAP_TYPE_WARN ||
> > > - handle_cfi_failure(regs) == BUG_TRAP_TYPE_WARN) {
> > > - regs->ip += LEN_UD2;
> > > - handled = true;
> > > +
> > > + if (insn == INSN_UD2) {
> > > + if (report_bug(regs->ip, regs) == BUG_TRAP_TYPE_WARN ||
> > > + handle_cfi_failure(regs) == BUG_TRAP_TYPE_WARN) {
> > > + regs->ip += LEN_UD2;
> > > + handled = true;
> > > + }
> > > + } else {
> > > + if (handle_ubsan_failure(regs, insn) == BUG_TRAP_TYPE_WARN) {
> >
> > handle_ubsan_failure currently only returns BUG_TRAP_TYPE_NONE?
> >
> > > + if (insn == INSN_REX)
> > > + regs->ip += LEN_REX;
> > > + regs->ip += LEN_UD1;
> > > + handled = true;
> > > + }
> > > }
> > > if (regs->flags & X86_EFLAGS_IF)
> > > raw_local_irq_disable();
> > > diff --git a/arch/x86/kernel/ubsan.c b/arch/x86/kernel/ubsan.c
> > > new file mode 100644
> > > index 000000000000..6cae11f4fe23
> > > --- /dev/null
> > > +++ b/arch/x86/kernel/ubsan.c
> > > @@ -0,0 +1,32 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * Clang Undefined Behavior Sanitizer trap mode support.
> > > + */
> > > +#include <linux/bug.h>
> > > +#include <linux/string.h>
> > > +#include <linux/printk.h>
> > > +#include <linux/ubsan.h>
> > > +#include <asm/ptrace.h>
> > > +#include <asm/ubsan.h>
> > > +
> > > +/*
> > > + * Checks for the information embedded in the UD1 trap instruction
> > > + * for the UB Sanitizer in order to pass along debugging output.
> > > + */
> > > +enum bug_trap_type handle_ubsan_failure(struct pt_regs *regs, int insn)
> > > +{
> > > + u32 type = 0;
> > > +
> > > + if (insn == INSN_REX) {
> > > + type = (*(u16 *)(regs->ip + LEN_REX + LEN_UD1));
> > > + if ((type & 0xFF) == 0x40)
> > > + type = (type >> 8) & 0xFF;
> > > + } else {
> > > + type = (*(u16 *)(regs->ip + LEN_UD1));
> > > + if ((type & 0xFF) == 0x40)
> > > + type = (type >> 8) & 0xFF;
> > > + }
> > > + pr_crit("%s at %pS\n", report_ubsan_failure(regs, type), (void *)regs->ip);
> > > +
> > > + return BUG_TRAP_TYPE_NONE;
> > > +}
> >
> > Shouldn't this return BUG_TRAP_TYPE_WARN?
>
> So as far as I understand, UBSAN trap mode never warns. Perhaps it does on
> arm64, although it calls die() so I am unsure. Maybe the condition in
> handle_bug() should be rewritten in the case of UBSAN ud1s? Do you have any
> suggestions?
AFAIK on arm64 it's basically a kernel OOPS.
The main thing I just wanted to point out though is that your newly added branch
> if (handle_ubsan_failure(regs, insn) == BUG_TRAP_TYPE_WARN) {
will never be taken, because I don't see where handle_ubsan_failure()
returns BUG_TRAP_TYPE_WARN.
That means 'handled' will be false, and the code in exc_invalid_op
will proceed to call handle_invalid_op() which is probably not what
you intended - i.e. it's definitely not BUG_TRAP_TYPE_NONE, but one of
TYPE_WARN of TYPE_BUG.
Did you test it and you got the behaviour you expected?
Powered by blists - more mailing lists