From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7EB42C282DE for ; Thu, 23 May 2019 07:01:38 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F2A0921773 for ; Thu, 23 May 2019 07:01:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=axtens.net header.i=@axtens.net header.b="Oe+r78Ud" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F2A0921773 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=axtens.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 458gQl6rCDzDqX9 for ; Thu, 23 May 2019 17:01:35 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=axtens.net (client-ip=2607:f8b0:4864:20::542; helo=mail-pg1-x542.google.com; envelope-from=dja@axtens.net; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=axtens.net Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=axtens.net header.i=@axtens.net header.b="Oe+r78Ud"; dkim-atps=neutral Received: from mail-pg1-x542.google.com (mail-pg1-x542.google.com [IPv6:2607:f8b0:4864:20::542]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 458gNs5n8xzDqC4 for ; Thu, 23 May 2019 16:59:55 +1000 (AEST) Received: by mail-pg1-x542.google.com with SMTP id a3so2623447pgb.3 for ; Wed, 22 May 2019 23:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axtens.net; s=google; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-transfer-encoding; bh=sTVf2HlQGeeweyPoper6ABpd3ug5oigjMesp2xkd4m0=; b=Oe+r78UdW+Kd0IH2xb+qj2L2OV8okEa0WqG9Fe7j+KI7DOhP6xZoTxw6EFyYiT2HAp v4TJeLUZoaaH0Uc4I/7mfkGKdIlkFvnVJNcsaj+fYNYasshr4DVtEZLtZn9FQOkyse4W IDAA1S+VVRcKOhiEOEBsTK7ALVSQUz0M+mEwI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=sTVf2HlQGeeweyPoper6ABpd3ug5oigjMesp2xkd4m0=; b=pbvKwFqizuPAjPg61Dilydt5NkteLu/sWB8I7rtv8TzJgHHn3BBLoNpamynAR1M+Br gCKrbRrEFCVRmUhdpl4zRTYmc4pmfobVnFZjDkXMs1TVeBOHFG4B3LtLmEmGDl2HqOm+ rNiXkEfnVVzMnlvSQZ8bZZimq5rWw6gIJyD1EQnA3kO3SzZQoZ19Bu2pVmunPNgcOooG 8TTYxg7qKx/D+fRtyORulD3yDmKBX79H20BpVfrXsk1fOo1F82Ui1f4in1M7LegZCqe2 onu6bp2mEAaUcnAJ5Vq7C610eumvAHShrKpXb1vSVTSJspbnpRFx1x+uiqNWxhQtFnlq GyPw== X-Gm-Message-State: APjAAAUktRLEDJhSFBlhStB9JMCM9ORH7sewTNQLJl9ul97yUAOpRQc5 Qz47BL+vN/+cXwyH5DJ3vMDyFA== X-Google-Smtp-Source: APXvYqzM4PWOJt5MxCFOI2DrqbYW4isjjV9tRRbe6Fz5yaniZBRItZhT4Kfk1bwqh+c09DtBf551dw== X-Received: by 2002:a17:90a:2590:: with SMTP id k16mr219167pje.11.1558594791623; Wed, 22 May 2019 23:59:51 -0700 (PDT) Received: from localhost (ppp167-251-205.static.internode.on.net. [59.167.251.205]) by smtp.gmail.com with ESMTPSA id v81sm52690410pfa.16.2019.05.22.23.59.50 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 22 May 2019 23:59:50 -0700 (PDT) From: Daniel Axtens To: Christophe Leroy , aneesh.kumar@linux.ibm.com, bsingharora@gmail.com Subject: Re: [RFC PATCH 6/7] kasan: allow arches to hook into global registration In-Reply-To: References: <20190523052120.18459-1-dja@axtens.net> <20190523052120.18459-7-dja@axtens.net> Date: Thu, 23 May 2019 16:59:47 +1000 Message-ID: <87h89lzme4.fsf@dja-thinkpad.axtens.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linuxppc-dev@lists.ozlabs.org, kasan-dev@googlegroups.com Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Christophe Leroy writes: > Le 23/05/2019 =C3=A0 07:21, Daniel Axtens a =C3=A9crit=C2=A0: >> Not all arches have a specific space carved out for modules - >> some, such as powerpc, just use regular vmalloc space. Therefore, >> globals in these modules cannot be backed by real shadow memory. > > Can you explain in more details the reason why ? At this point, purely simplicity. As you discuss below, it's possible to do better. > > PPC32 also uses regular vmalloc space, and it has been possible to=20 > manage globals on it, by simply implementing a module_alloc() function. > > See=20 > https://elixir.bootlin.com/linux/v5.2-rc1/source/arch/powerpc/mm/kasan/ka= san_init_32.c#L135 > > It is also possible to easily define a different area for modules, by=20 > replacing the call to vmalloc_exec() by a call to __vmalloc_node_range()= =20 > as done by vmalloc_exec(), but with different bounds than=20 > VMALLOC_START/VMALLOC_END > > See https://elixir.bootlin.com/linux/v5.2-rc1/source/mm/vmalloc.c#L2633 > > Today in PPC64 (unlike PPC32), there is already a split between VMALLOC=20 > space and IOREMAP space. I'm sure it would be easy to split it once more= =20 > for modules. > OK, good to know, I'll look into one of those approaches for the next spin! Regards, Daniel > Christophe > >>=20 >> In order to allow arches to perform this check, add a hook. >>=20 >> Signed-off-by: Daniel Axtens >> --- >> include/linux/kasan.h | 5 +++++ >> mm/kasan/generic.c | 3 +++ >> 2 files changed, 8 insertions(+) >>=20 >> diff --git a/include/linux/kasan.h b/include/linux/kasan.h >> index dfee2b42d799..4752749e4797 100644 >> --- a/include/linux/kasan.h >> +++ b/include/linux/kasan.h >> @@ -18,6 +18,11 @@ struct task_struct; >> static inline bool kasan_arch_is_ready(void) { return true; } >> #endif >>=20=20=20 >> +#ifndef kasan_arch_can_register_global >> +static inline bool kasan_arch_can_register_global(const void * addr) { = return true; } >> +#endif >> + >> + >> #ifndef ARCH_HAS_KASAN_EARLY_SHADOW >> extern unsigned char kasan_early_shadow_page[PAGE_SIZE]; >> extern pte_t kasan_early_shadow_pte[PTRS_PER_PTE]; >> diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c >> index 0336f31bbae3..935b06f659a0 100644 >> --- a/mm/kasan/generic.c >> +++ b/mm/kasan/generic.c >> @@ -208,6 +208,9 @@ static void register_global(struct kasan_global *glo= bal) >> { >> size_t aligned_size =3D round_up(global->size, KASAN_SHADOW_SCALE_SIZ= E); >>=20=20=20 >> + if (!kasan_arch_can_register_global(global->beg)) >> + return; >> + >> kasan_unpoison_shadow(global->beg, global->size); >>=20=20=20 >> kasan_poison_shadow(global->beg + aligned_size, >>=20