Messages in this thread | | | Date | Mon, 25 Apr 2016 09:36:43 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH] x86/boot: Rename overlapping memcpy() to memmove() |
| |
* Kees Cook <keescook@chromium.org> wrote:
> On Sat, Apr 23, 2016 at 4:08 AM, Ingo Molnar <mingo@kernel.org> wrote: > > > > * Kees Cook <keescook@chromium.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
| |