Messages in this thread | | | Date | Fri, 3 Jul 2020 22:02:37 +0100 | From | Al Viro <> | Subject | Re: objtool clac/stac handling change.. |
| |
On Fri, Jul 03, 2020 at 02:33:28AM +0100, Al Viro wrote: > On Thu, Jul 02, 2020 at 02:55:19PM -0700, Linus Torvalds wrote: > > > And while XSTATE_OP() is still disgusting, it's > > > > (a) slightly less disgusting than it used to be > > > > (b) now easily fixable if we do the "exceptions clear AC" thing. > > > > so it's an improvement all around. > > > > If it works, that is. As mentioned: IT HAS NO TESTING. > > What about load_unaligned_zeropad()? Normally the caller doesn't > want to know about the exception on crossing into an unmapped > page. Blanket "clear #AC of fixup, don't go through user_access_end() > in case of exception" would complicate the code that calls that sucker.
Actually, for more serious problem consider arch/x86/lib/copy_user_64.S
In case of an unhandled fault on attempt to read an (unaligned) word, the damn thing falls back to this: SYM_CODE_START_LOCAL(.Lcopy_user_handle_tail) movl %edx,%ecx 1: rep movsb 2: mov %ecx,%eax ASM_CLAC ret
_ASM_EXTABLE_UA(1b, 2b) SYM_CODE_END(.Lcopy_user_handle_tail)
We could do what alpha, sparc et.al. are doing - have both reads and writes aligned, with every output word being a mix of two input ones. But I would expect that to be considerably slower than the current variants. Sure, we can set AC in .Lcopy_user_handle_tail, but that doesn't look right.
And while squeezing every byte on a short copy is not a hard requirement, in situation when the source is one byte before the end of page and destination is aligned, raw_copy_from_user() really must copy at least one byte if it's readable.
So I suspect that we need a variant of extable entry that does not clear AC, at least for these fallbacks.
PS: I'm still going through the _ASM_EXTABLE... users on x86, so there might be more fun. Will post when I'm done...
| |