From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753738AbcDYHgv (ORCPT <rfc822;w@1wt.eu>);
	Mon, 25 Apr 2016 03:36:51 -0400
Received: from mail-wm0-f65.google.com ([74.125.82.65]:32870 "EHLO
	mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753512AbcDYHgt (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 25 Apr 2016 03:36:49 -0400
Date: Mon, 25 Apr 2016 09:36:43 +0200
From: Ingo Molnar <mingo@kernel.org>
To: Kees Cook <keescook@chromium.org>
Cc: Yinghai Lu <yinghai@kernel.org>, Baoquan He <bhe@redhat.com>,
        Borislav Petkov <bp@suse.de>, Ingo Molnar <mingo@redhat.com>,
        "x86@kernel.org" <x86@kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Andrey Ryabinin <aryabinin@virtuozzo.com>,
        Dmitry Vyukov <dvyukov@google.com>, "H.J. Lu" <hjl.tools@gmail.com>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        Andy Lutomirski <luto@kernel.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86/boot: Rename overlapping memcpy() to memmove()
Message-ID: <20160425073643.GA27425@gmail.com>
References: <20160422222641.GA15276@www.outflux.net>
 <20160423110836.GA12304@gmail.com>
 <CAGXu5jJibUuByt=L8-NkWEvBbx==wZxTRgJkSqKEeD=kS9=VAA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAGXu5jJibUuByt=L8-NkWEvBbx==wZxTRgJkSqKEeD=kS9=VAA@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* 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