|
Message-ID: <20170509174403.etx64yozb7ctr4ur@treble> Date: Tue, 9 May 2017 12:44:03 -0500 From: Josh Poimboeuf <jpoimboe@...hat.com> To: Kees Cook <keescook@...omium.org> Cc: LKML <linux-kernel@...r.kernel.org>, Peter Zijlstra <peterz@...radead.org>, PaX Team <pageexec@...email.hu>, Jann Horn <jannh@...gle.com>, Eric Biggers <ebiggers3@...il.com>, Christoph Hellwig <hch@...radead.org>, "axboe@...nel.dk" <axboe@...nel.dk>, James Bottomley <James.Bottomley@...senpartnership.com>, Elena Reshetova <elena.reshetova@...el.com>, Hans Liljestrand <ishkamiel@...il.com>, David Windsor <dwindsor@...il.com>, "x86@...nel.org" <x86@...nel.org>, Ingo Molnar <mingo@...nel.org>, Arnd Bergmann <arnd@...db.de>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, "David S. Miller" <davem@...emloft.net>, Rik van Riel <riel@...hat.com>, linux-arch <linux-arch@...r.kernel.org>, "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com> Subject: Re: [PATCH v3 2/2] x86/refcount: Implement fast refcount overflow protection On Tue, May 09, 2017 at 10:29:16AM -0700, Kees Cook wrote: > On Tue, May 9, 2017 at 10:08 AM, Josh Poimboeuf <jpoimboe@...hat.com> wrote: > > On Mon, May 08, 2017 at 08:58:29PM -0500, Josh Poimboeuf wrote: > >> On Mon, May 08, 2017 at 04:31:11PM -0700, Kees Cook wrote: > >> > On Mon, May 8, 2017 at 3:53 PM, Josh Poimboeuf <jpoimboe@...hat.com> wrote: > >> > > On Mon, May 08, 2017 at 12:32:52PM -0700, Kees Cook wrote: > >> > >> +#define REFCOUNT_EXCEPTION \ > >> > >> + "movl $0x7fffffff, %[counter]\n\t" \ > >> > >> + "int $"__stringify(X86_REFCOUNT_VECTOR)"\n" \ > >> > >> + "0:\n\t" \ > >> > >> + _ASM_EXTABLE(0b, 0b) > >> > > > >> > > Despite the objtool warnings going away, this still uses the exception > >> > > table in a new way, which will confuse objtool. I need to do some more > >> > > thinking about the best way to fix it, either as a change to your patch > >> > > or a change to objtool. > >> > > >> > In that it's not a "true" exception? > >> > >> Right. And also that it doesn't need the "fixup" since it would return > >> to the same address anyway. > > > > How about the following on top of your patch? It uses #UD (invalid > > opcode). Notice it's mostly code deletions :-) > > Hah, I wrote this patch almost exactly last night, but hadn't had a > chance to send it out. :) > > I ended up defining a new exception handler, which means nothing > special in the generic trap code. I didn't send it out because it was > still using a jns instead of js, and I was pondering if I wanted to > reintroduce the text section jump just to gain the initial benefit of > forward-branch-not-taken optimization... > > > diff --git a/arch/x86/include/asm/refcount.h b/arch/x86/include/asm/refcount.h > > index 6e8bbd7..653a985 100644 > > --- a/arch/x86/include/asm/refcount.h > > +++ b/arch/x86/include/asm/refcount.h > > @@ -8,15 +8,16 @@ > > */ > > #include <linux/refcount.h> > > #include <asm/irq_vectors.h> > > +#include <asm/bug.h> > > > > #define REFCOUNT_EXCEPTION \ > > "movl $0x7fffffff, %[counter]\n\t" \ > > - "int $"__stringify(X86_REFCOUNT_VECTOR)"\n" \ > > - "0:\n\t" \ > > - _ASM_EXTABLE(0b, 0b) > > + "1:\t" ASM_UD0 "\n" \ > > + "2:\n\t" \ > > + _ASM_EXTABLE(1b, 2b) > > I used _ASM_EXTABLE_REFCOUNT(1b, 2b) here, with > arch/x86/include/asm/asm.h adding: > > +# define _ASM_EXTABLE_REFCOUNT(from, to) \ > + _ASM_EXTABLE_HANDLE(from, to, ex_handler_refcount) > > > diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c > > index 0b2dbcc..7de95b7 100644 > > --- a/arch/x86/kernel/traps.c > > +++ b/arch/x86/kernel/traps.c > > @@ -220,8 +220,8 @@ do_trap_no_signal(struct task_struct *tsk, int trapnr, char *str, > > if (!user_mode(regs)) { > > if (fixup_exception(regs, trapnr)) { > > if (IS_ENABLED(CONFIG_FAST_REFCOUNT) && > > - trapnr == X86_REFCOUNT_VECTOR) > > - refcount_error_report(regs, str); > > + trapnr == X86_TRAP_UD) > > + refcount_error_report(regs); > > > > return 0; > > } > > And then I could leave out this hunk, instead adding this to > arch/x86/mm/extable.c: > > +bool ex_handler_refcount(const struct exception_table_entry *fixup, > + struct pt_regs *regs, int trapnr) > +{ > + regs->ip = ex_fixup_addr(fixup); > + refcount_error_report(regs, "overflow"); > + return true; > +} > +EXPORT_SYMBOL_GPL(ex_handler_refcount); > > After looking at the assembly output, the "movl" instructions can be > various sizes, depending on where %[counter] lives, so I'm also > considering returning to using PaX's "lea", but I'm not sure the > benefit would be very large. Good, your patch sounds better than mine :-) -- Josh
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.