[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jJibUuByt=L8-NkWEvBbx==wZxTRgJkSqKEeD=kS9=VAA@mail.gmail.com>
Date: Sat, 23 Apr 2016 12:46:51 -0700
From: Kees Cook <keescook@...omium.org>
To: Ingo Molnar <mingo@...nel.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()
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.)
-Kees
>
> Thanks,
>
> Ingo
--
Kees Cook
Chrome OS & Brillo Security
Powered by blists - more mailing lists