Messages in this thread | | | Date | Fri, 3 Jul 2020 23:25:16 +0100 | From | Al Viro <> | Subject | Re: objtool clac/stac handling change.. |
| |
On Fri, Jul 03, 2020 at 02:41:43PM -0700, Andy Lutomirski wrote:
> I still feel like the ex_handler-automatically-does-CLAC thing is an > optimization that isn't worth it. Once we pull our heads out of the > giant pile of macros and inlined functions, we're talking about > changing:
> clac; jmp. But on the flip side, the jump folding pattern looks > better like this: > > unsafe_uaccess_begin(); > if (unsafe_get_user(...)) > goto fail; > if (unsafe_get_user(...)) > goto fail; > unsafe_uaccess_end(); > > fail: > unsafe_uaccess_end(); > > than like: > > unsafe_uaccess_begin(); > if (unsafe_get_user(...)) > goto fail; > if (unsafe_get_user(...)) > goto fail; > unsafe_uaccess_end(); > > fail: > /* not unsafe_uaccess_end(); because unsafe_get_user() has > conditional-CLAC semantics */
First of all, user_access_begin() itself can bloody well fail. So you need to handle that as well. And then it becomes nowhere near as pretty.
We can pretend that it's normal C; however, that's not true at all - there are shitloads of things you can't do in such areas, starting with "call anything other than a very small list of functions". It's not a normal C environment at all.
My problem is not with having AC turned off in exception handler - it leads to saner patterns, no arguments here. I'm not happy with doing doing that on *every* exception, with no way to specify whether it should or should not be done. It's not like it would've cost us anything to be able to specify that - we have the third argument of _ASM_EXTABLE_HANDLE(), after all.
| |