Re: [PATCH v6 1/4] x86: Clean up extable entry format (and free up a bit)

From: Borislav Petkov
Date: Tue Jan 05 2016 - 06:20:22 EST


On Mon, Jan 04, 2016 at 03:25:58PM -0800, Andy Lutomirski wrote:
> On Mon, Jan 4, 2016 at 3:02 PM, Borislav Petkov <bp@xxxxxxxxx> wrote:
> > On Mon, Jan 04, 2016 at 02:29:09PM -0800, Andy Lutomirski wrote:
> >> Josh will argue with you if he sees that :)
> >
> > Except Josh doesn't need allyesconfigs. tinyconfig's __ex_table is 2K.
>
> If we do the make-it-bigger approach, we get a really nice
> simplification. Screw the whole 'class' idea -- just store an offset
> to a handler.
>
> bool extable_handler_default(struct pt_regs *regs, unsigned int fault,
> unsigned long error_code, unsigned long info)
> {
> if (fault == X86_TRAP_MC)
> return false;
>
> ...
> }
>
> bool extable_handler_mc_copy(struct pt_regs *regs, unsigned int fault,
> unsigned long error_code, unsigned long info);
> bool extable_handler_getput_ex(struct pt_regs *regs, unsigned int
> fault, unsigned long error_code, unsigned long info);
>
> and then shove ".long extable_handler_whatever - ." into the extable entry.

And to make it even cooler and more generic, you can make the exception
table entry look like this:

{ <offset to fault address>, <offset to handler>, <offset to an opaque pointer> }

and that opaque pointer would be a void * to some struct we pass to
that handler and filled with stuff it needs. For starters, it would
contain the return address where the fixup wants us to go.

The struct will have to be statically allocated but ok, that's fine.

And this way you can do all the sophisticated handling you desire.

> Major bonus points to whoever can figure out how to make
> extable_handler_iret work -- the current implementation of that is a
> real turd. (Hint: it's not clear to me that it's even possible
> without preserving at least part of the asm special case.)

What's extable_handler_iret? IRET-ting from an exception? Where do we do
that?

--
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/