lkml.org 
[lkml]   [2016]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2016-04-25 10:01    [W:0.050 / U:1.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site