linux-kernel - Re: [PATCH] x86/boot: Rename overlapping memcpy() to memmove()

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 25 Apr 2016 09:36:43 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Kees Cook <keescook@...omium.org>
Cc:	Yinghai Lu <yinghai@...nel.org>, Baoquan He <bhe@...hat.com>,
	Borislav Petkov <bp@...e.de>, Ingo Molnar <mingo@...hat.com>,
	"x86@...nel.org" <x86@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andrey Ryabinin <aryabinin@...tuozzo.com>,
	Dmitry Vyukov <dvyukov@...gle.com>,
	"H.J. Lu" <hjl.tools@...il.com>,
	Josh Poimboeuf <jpoimboe@...hat.com>,
	Andy Lutomirski <luto@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86/boot: Rename overlapping memcpy() to memmove()


* Kees Cook <keescook@...omium.org> wrote:

> On Sat, Apr 23, 2016 at 4:08 AM, Ingo Molnar <mingo@...nel.org> wrote:
> >
> > * Kees Cook <keescook@...omium.org> wrote:
> >
> >> --- a/arch/x86/boot/compressed/string.c
> >> +++ b/arch/x86/boot/compressed/string.c
> >> @@ -1,7 +1,13 @@
> >> +/*
> >> + * This provides an optimized implementation of memcpy, and a simplified
> >> + * implementation of memset and memmove, to avoid problems with the
> >> + * built-in implementations when running in the restricted decompression
> >> + * stub environment.
> >> + */
> >
> > Does 'built in' here mean the compiler's implementation?
> >
> > We cannot call kernel built-in functions yet, so we have to duplicate everything
> > we might need, right?
> 
> Right, I actually mean both: we can use neither gcc nor kernel
> built-ins. (I am fuzzy on why the gcc built-ins aren't available -- I
> think because they're not available for standalone builds.)

I think part of it is that we simply don't trust libgcc: it might be using FPU ops 
or it might start doing something silly from a kernel perspective while 
language-lawyering their way out of the regression with some sort of 'we never 
promised to keep that kind of detail stable'.

The smaller the cross-surface to a historically compatibility-breakage-happy 
compiler like GCC the better.

Thanks,

	Ingo