linux-kernel - Re: [RFC PATCH] Drop some asm from copy_user

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

Message-ID: <CA+55aFxf9wcrx4xfj8a-kEDveKHZSOagGCxi40_NC3vPx2J4DQ@mail.gmail.com>
Date:	Wed, 13 May 2015 09:02:41 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Ingo Molnar <mingo@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andy Lutomirski <luto@...capital.net>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] Drop some asm from copy_user_64.S

On Wed, May 13, 2015 at 2:52 AM, Borislav Petkov <bp@...en8.de> wrote:
>
> Now we CALL _copy_*_user which does CALL the optimal alternative
> version. Advantage is that we're saving some space and alternatives
> application for copy_user* is being done in less places, i.e.
> arch/x86/lib/uaccess_64.c. If I move all copy_user_generic() callers
> there, it would be the only compilation unit where the alternatives will
> be done.
>
> The disadvantage is that we have CALL after CALL and I wanted to have a
> single CALL directly to the optimal copy_user function. That'll cost us
> space, though, and more alternatives sites to patch during boot...
>
> Thoughts?

So I think we should do this first call-to-call thing, because it
makes it easier to go to the second step: replace the final call with
a asm-alternative that just puts the "rep movsb" inline for the (more
and more common) case of X86_FEATURE_ERMS.

The nice thing about using "rep movsb" for the user copy is that not
only is it fairly close to optimal (for non-constant sizes) on newer
Intel CPU's, but the fixup is also trivial. So we really should inline
it. Just look at it: the copy_user_enhanced_fast_string function is
literally just three 2-byte instructions right now:

    mov    %edx,%ecx
    rep movsb
    xor    %eax,%eax

and the rest is just the exception table thing.

(And yes, there's the STAC/CLAC thing around it, but I think that
should just be moved into _copy_from/to_user() too, since *all* of the
copy_user_generic() cases need it).

Yeah, yeah, we'd still do the double call thing for the more complex
cases of the unrolled copy loop or the "movsq + tail" cases, but those
are at least big enough that it makes sense. And they are presumably
getting less common anyway.

                          Linus
--
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/