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

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] [day] [month] [year] [list]

Date:	Tue, 5 Jan 2016 12:20:14 +0100
From:	Borislav Petkov <bp@...en8.de>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Tony Luck <tony.luck@...il.com>, Ingo Molnar <mingo@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andy Lutomirski <luto@...nel.org>,
	Dan Williams <dan.j.williams@...el.com>,
	Robert <elliott@....com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	linux-nvdimm <linux-nvdimm@...1.01.org>, X86-ML <x86@...nel.org>
Subject: Re: [PATCH v6 1/4] x86: Clean up extable entry format (and free up a
 bit)

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@...en8.de> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/