Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1412641imu; Wed, 16 Jan 2019 19:20:15 -0800 (PST) X-Google-Smtp-Source: ALg8bN5un/UXAq6/ys0qqh6gH1CmQgnBtAPVwmcmSSpN3ieNJx9xkzWmLjzsKQlZtEJ3H+9tB6g7 X-Received: by 2002:a63:ef04:: with SMTP id u4mr12003548pgh.197.1547695215792; Wed, 16 Jan 2019 19:20:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547695215; cv=none; d=google.com; s=arc-20160816; b=e39v5UNJ1H6DSxpjGxDPaFCvnezhSqzrsaigy3rwblT2XBniu+C3HDXgmZ0izmnnMq kuvbNelhM0OxmX/9JGpHrcqyl5YaUomjcVoEDlHZlG3L+CjUPNFl4z8WISfpenAzdZkD eOKYIJxEagYEGwu83mFtG5at4wL2hELppWq2Qg4B5zMXEEkCOcCwtlajBmfaEszqEl0T kvHvw3LD8nUmXRHsuO7xrPqGKoa3TtzWSF1sqnP9YJMxcsKNIAecB+GxamH5CqXj/hbL zEkqi+MSuP12DFWP38Os8BIZ1YZOt8lXpL8v/NgiXsFbkPWGBxlFwAWL28fLrgPJ/V3m E+yQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=1rZmRkYrQKk3sCyEFFu33/UQOzqgS6+8CGeODCvYF/s=; b=wHO//z0ISpbMNTRNqz9HBnEb4sLgV7MiDB+0Jkl8SDI3Qu5spgi8ztYLAMG4nenC6D WoWXWZnHu/N4D+XbPt0RgzJlcgQ8vecwRZNdhplJRMeRDSBbS7c6zTNqfv/jTe7kCL1r NvTVnpEewxmgft2P8hI/puMA/ptTFEQfj3OQlDkEgJyzHYBKvWzqQkCX7Xzj7VENOUEh pONY5NB3HaBdCTjG0nTzcsm1i6Nge7e6LRghFlrfGNmGZERkNHtgcRD336cQuWLtdfv8 K1c4Wulko1avEyRxJeg0I+gq2FFGq2627NNkoeBy24uZ5z/b2Tt4G2FYQPvH/NUTHAmx mgEg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=TF2ylQHQ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a10si345837pgq.270.2019.01.16.19.19.55; Wed, 16 Jan 2019 19:20:15 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=TF2ylQHQ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731720AbfAPKEF (ORCPT + 99 others); Wed, 16 Jan 2019 05:04:05 -0500 Received: from mail-it1-f196.google.com ([209.85.166.196]:54913 "EHLO mail-it1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728780AbfAPKEE (ORCPT ); Wed, 16 Jan 2019 05:04:04 -0500 Received: by mail-it1-f196.google.com with SMTP id i145so2089476ita.4 for ; Wed, 16 Jan 2019 02:04:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1rZmRkYrQKk3sCyEFFu33/UQOzqgS6+8CGeODCvYF/s=; b=TF2ylQHQEd5iJSoMu3xW3NRRnQg0nLYymB0YSGlvJyLWjfZEN+1R0SvUAjR3hr3gov LE3Bys85UGMon+7lUvmZdB4Zy3zB+9SjOk7TNeynbZX9KgegPPTlSKEJqGFU4eNJBF+E 0ND+IccUodxtSVBIrEQGYOW+x96X97fHNmyidOlv2zX5EpV5ZdOYtNYmhdHXrmJb0fyk iCG4MFql60DSCyCy3ylU1QIrIgfd9DZ9gLwxwh1qEwmpricyEPND87Pk3d3N1Y82cB6f mgX3egvRkAQiTqalnc/71+66GrUv9OKvfNVfl7rPqYCPrDSicoMogDMj+b+UN6sVOoez xMpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=1rZmRkYrQKk3sCyEFFu33/UQOzqgS6+8CGeODCvYF/s=; b=dmoWjqn4Sjk7AhrV8csyaRlA38IwWORt76GhBzVTWBRjDBCNaJr8s/Ji5K+JHjAS0g O0v2b1rtQFhSKi9hXVnSA8NEKMIOkPiS4NDz6uGyVE+opbT7KQ+Vo4Ql9si7v8iw+Ssl 5X1AQm6WAfn5yOcAtQRs5OA6ny3TFEulPwttBagkP2vua8RN91uRmJmh4OGc4PZ3H/OA reDq43UJdNQbCGYhgQKKBDwPVrYKqdVIsOf8LCy/RDh5kmvWq/qkyd48ObJCfH1JD9wu w2uie1eQponytSjqjFTvWErU2sf10SjmMWECL0MT+7VQAwWeVsq4Z9OkjKRW9nynhVfv /Oig== X-Gm-Message-State: AJcUukfcv8hpzbvNjAFR2P6coNPjvPPsEEXTZ/s+pWFido9sS3zxCHKT 7sYVEjEZODbK4K30bjDXLNaIYppXZ590QcdErpbLOA== X-Received: by 2002:a24:6511:: with SMTP id u17mr5175695itb.12.1547633043176; Wed, 16 Jan 2019 02:04:03 -0800 (PST) MIME-Version: 1.0 References: <0c854dd6b110ac2b81ef1681f6e097f59f84af8b.1547289808.git.christophe.leroy@c-s.fr> <801c7d58-417d-1e65-68a0-b8cf02f9f956@c-s.fr> <330696c0-90c6-27de-5eb3-4da2159fdfbc@virtuozzo.com> <301f5826-64ab-1cf4-7e7e-cd026de77bca@c-s.fr> In-Reply-To: <301f5826-64ab-1cf4-7e7e-cd026de77bca@c-s.fr> From: Dmitry Vyukov Date: Wed, 16 Jan 2019 11:03:51 +0100 Message-ID: Subject: Re: [PATCH v3 1/3] powerpc/mm: prepare kernel for KAsan on PPC32 To: Christophe Leroy Cc: Andrey Ryabinin , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Nicholas Piggin , "Aneesh Kumar K.V" , Alexander Potapenko , LKML , linuxppc-dev@lists.ozlabs.org, kasan-dev , Linux-MM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 15, 2019 at 6:25 PM Christophe Leroy wrote: > > Le 15/01/2019 =C3=A0 18:10, Dmitry Vyukov a =C3=A9crit : > > On Tue, Jan 15, 2019 at 6:06 PM Andrey Ryabinin wrote: > >> > >> On 1/15/19 2:14 PM, Dmitry Vyukov wrote: > >>> On Tue, Jan 15, 2019 at 8:27 AM Christophe Leroy > >>> wrote: > >>>> On 01/14/2019 09:34 AM, Dmitry Vyukov wrote: > >>>>> On Sat, Jan 12, 2019 at 12:16 PM Christophe Leroy > >>>>> wrote: > >>>>> > > >>>>> > In kernel/cputable.c, explicitly use memcpy() in order > >>>>> > to allow GCC to replace it with __memcpy() when KASAN is > >>>>> > selected. > >>>>> > > >>>>> > Since commit 400c47d81ca38 ("powerpc32: memset: only use dcbz = once cache is > >>>>> > enabled"), memset() can be used before activation of the cache= , > >>>>> > so no need to use memset_io() for zeroing the BSS. > >>>>> > > >>>>> > Signed-off-by: Christophe Leroy > >>>>> > --- > >>>>> > arch/powerpc/kernel/cputable.c | 4 ++-- > >>>>> > arch/powerpc/kernel/setup_32.c | 6 ++---- > >>>>> > 2 files changed, 4 insertions(+), 6 deletions(-) > >>>>> > > >>>>> > diff --git a/arch/powerpc/kernel/cputable.c > >>>>> b/arch/powerpc/kernel/cputable.c > >>>>> > index 1eab54bc6ee9..84814c8d1bcb 100644 > >>>>> > --- a/arch/powerpc/kernel/cputable.c > >>>>> > +++ b/arch/powerpc/kernel/cputable.c > >>>>> > @@ -2147,7 +2147,7 @@ void __init set_cur_cpu_spec(struct cpu_= spec *s) > >>>>> > struct cpu_spec *t =3D &the_cpu_spec; > >>>>> > > >>>>> > t =3D PTRRELOC(t); > >>>>> > - *t =3D *s; > >>>>> > + memcpy(t, s, sizeof(*t)); > >>>>> > >>>>> Hi Christophe, > >>>>> > >>>>> I understand why you are doing this, but this looks a bit fragile a= nd > >>>>> non-scalable. This may not work with the next version of compiler, > >>>>> just different than yours version of compiler, clang, etc. > >>>> > >>>> My felling would be that this change makes it more solid. > >>>> > >>>> My understanding is that when you do *t =3D *s, the compiler can use > >>>> whatever way it wants to do the copy. > >>>> When you do memcpy(), you ensure it will do it that way and not anot= her > >>>> way, don't you ? > >>> > >>> It makes this single line more deterministic wrt code-gen (though, > >>> strictly saying compiler can turn memcpy back into inlines > >>> instructions, it knows memcpy semantics anyway). > >>> But the problem I meant is that the set of places that are subject to > >>> this problem is not deterministic. So if we go with this solution, > >>> after this change it's in the status "works on your machine" and we > >>> either need to commit to not using struct copies and zeroing > >>> throughout kernel code or potentially have a long tail of other > >>> similar cases, and since they can be triggered by another compiler > >>> version, we may need to backport these changes to previous releases > >>> too. Whereas if we would go with compiler flags, it would prevent the > >>> problem in all current and future places and with other past/future > >>> versions of compilers. > >>> > >> > >> The patch will work for any compiler. The point of this patch is to ma= ke > >> memcpy() visible to the preprocessor which will replace it with __memc= py(). > > > > For this single line, yes. But it does not mean that KASAN will work. > > > >> After preprocessor's work, compiler will see just __memcpy() call here= . > > This problem can affect any arch I believe. Maybe the 'solution' would > be to run a generic script similar to > arch/powerpc/kernel/prom_init_check.sh on all objects compiled with > KASAN_SANITIZE_object.o :=3D n don't include any reference to memcpy() > memset() or memmove() ? We do this when building user-space sanitizers runtime. There all code always runs with sanitizer enabled, but at the same time must not be instrumented. So we committed to changing all possible memcpy/memset injection points and have a script that checks that we indeed have no such calls at any paths. There problem is a bit simpler as we don't have gazillion combinations of configs and the runtime is usually self-hosted (as it is bundled with compiler), so we know what compiler is used to build it. And that all is checked on CI. I don't know how much work it is to do the same for kernel, though. Adding -ffreestanding, if worked, looked like a cheap option to achieve the same. Another option is to insert checks into KASAN's memcpy/memset that at least some early init has completed. If early init hasn't finished yet, then they could skip all additional work besides just doing memcpy/memset. We can't afford this for memory access instrumentation for performance reasons, but it should be bearable for memcpy/memset.