Received: by 2002:ac0:e350:0:0:0:0:0 with SMTP id g16csp278647imn; Wed, 3 Aug 2022 03:35:17 -0700 (PDT) X-Google-Smtp-Source: AGRyM1s/JL0M+LNYlf5ic40NDmz98wQbaM22YwgNdxDIGNoiTI6DuvqjReq++Y+9mLsAf3sFEmpc X-Received: by 2002:a17:906:ff48:b0:72f:10c:bb3f with SMTP id zo8-20020a170906ff4800b0072f010cbb3fmr19717455ejb.718.1659522917049; Wed, 03 Aug 2022 03:35:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659522917; cv=none; d=google.com; s=arc-20160816; b=ynf66m7kbcQNaFwgckOeGOCt7JdDQbgodMUj8r4oxuU3yvnSt99sETy3KvVMMWFDbo /eYKLk+OFKflmFZSOmdUym2+NthExgwBQahOQZSoKs0tvqIpv+d11iLHx5rzsc3OfpE/ a7FQNj7HugUToQjRr2PDO527WHWi2t4ACqdpEV+XZbQDJtIJhbueRXJn59pvkHhoC/k0 uuG3jEudhsi6dumEHq4sywmpns+vkv9PCwxGv3tK/4tgDpo7bxOE9vEQReKi5PEKywK5 Mgg5uVV5DTpqXBZeP+HP23qNxOTuVRyNjP/SFZW004aAWCNRqMwQRBkEkAVOk5+sy+uD ngTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=BnCISkt/rTW8As5S0Z1/CmUKmWtp6KufxVc54xAHFLs=; b=GzfDx5eSyPu6tCnRWy+XYSRhao+g8zQlEGniawNKosesWnLuR7LqNDyoaxVSXloFDS EMtQVMRKU5gU5tVVP1G4odR2qRfk4jvI2cJfETYvtZfGhXKx+bvRQxdWqm/eN8mvIpC9 56Ah6AlwV8kHsWq+vMaf9q7eJlxqFhYrFEQ4t73h4moPaGYE5PLfv7j5eYzHFL1LB58t N7g2A9aid17RhTAzInJFJC9HxfIjhKlYsM/wApAsYuHbpKPp3PU7YMSyHWIjuZ70R+qB g2oQi0Tff38rDtuBaGOqzV5SYCGAepZqo/qjBeiYSdFuKNT+fmsqqOmKWrf/mArbxmLk iseQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=bTMMrVHL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l6-20020a170906794600b00729c19c5106si16887091ejo.999.2022.08.03.03.34.50; Wed, 03 Aug 2022 03:35:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=bTMMrVHL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S238019AbiHCKdR (ORCPT + 99 others); Wed, 3 Aug 2022 06:33:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35282 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238050AbiHCKb2 (ORCPT ); Wed, 3 Aug 2022 06:31:28 -0400 Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 11EB732DAB for ; Wed, 3 Aug 2022 03:30:59 -0700 (PDT) Received: by mail-yb1-xb2b.google.com with SMTP id g5so3324839ybg.11 for ; Wed, 03 Aug 2022 03:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc; bh=BnCISkt/rTW8As5S0Z1/CmUKmWtp6KufxVc54xAHFLs=; b=bTMMrVHLEXsaZsPJ4ir9RlmOn/kRdosyeadx3rkmGXU4lflYbV46JM5DZksUMtzIVN U/XEZSrcnqjbOBxVyOOXZVWlx0hp9Fu5nKxWv12BNG1XktevXZFB3m/Y6U7AR+1tVcE2 moSCPz5d5L9dbdRbJMQnG2/CX8KHw3/wr6ghKVtubKYXwknqG+9T92FwxaKne2npOKfO fDB0cU62aoS1208GpKYOLg5LwYk5buP/sgF+RjfJpmGKtXJeAinS5Jzr3wLXQdoHpwkg lGa+9i5+l/igcHME3dLynxA3WXk5TN5TBIaxPE4oeCTUDNBsXUUsFu1mf5QJV6HhkRE8 9BPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc; bh=BnCISkt/rTW8As5S0Z1/CmUKmWtp6KufxVc54xAHFLs=; b=VsPMBKkLqnh8OyFa64+A/98rngqoDrHGRcsbr735k5QBtX7UXFiUueBKGnk2Q3Mxz0 TEbDq+KTvxobVTWiGZ11VHTzlmBhi3C9P8Bdlw4gtRGvlqlwgECKaHvqzZUmrepr774c D/1nE6C23Ue0/12ZlSQWz+mOCv0ZUIvqECaD+r32GiPJ9I4bc7CJgStEaVeQtjhLU87H 7us9ugM8SAvQzyDvOJBCy538Q/icmCVMJ4YT7llyctsFhbAY1lP+0VzCuwuKGCMg9JS4 UjaqqEDlr+dLfirVI2qf52cloJII1Zc597ayCvBl2BYBu1ynjsh18elCQsCs2A1CAgru lJdQ== X-Gm-Message-State: ACgBeo1U4jDwOtx9wZKIlbcWTkZpTaiFfhXdEWLhi68nsh8qhytUsdm4 QMSOAsJfrOT6A88X51OBNxbfeFFi0brLu7uq5A9OYg== X-Received: by 2002:a05:6902:1348:b0:671:78a4:471f with SMTP id g8-20020a056902134800b0067178a4471fmr19280596ybu.242.1659522658125; Wed, 03 Aug 2022 03:30:58 -0700 (PDT) MIME-Version: 1.0 References: <20220701142310.2188015-1-glider@google.com> <20220701142310.2188015-15-glider@google.com> In-Reply-To: From: Alexander Potapenko Date: Wed, 3 Aug 2022 12:30:21 +0200 Message-ID: Subject: Re: [PATCH v4 14/45] mm: kmsan: maintain KMSAN metadata for page operations To: Marco Elver Cc: Alexander Viro , Alexei Starovoitov , Andrew Morton , Andrey Konovalov , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Christoph Hellwig , Christoph Lameter , David Rientjes , Dmitry Vyukov , Eric Dumazet , Greg Kroah-Hartman , Herbert Xu , Ilya Leoshkevich , Ingo Molnar , Jens Axboe , Joonsoo Kim , Kees Cook , Mark Rutland , Matthew Wilcox , "Michael S. Tsirkin" , Pekka Enberg , Peter Zijlstra , Petr Mladek , Steven Rostedt , Thomas Gleixner , Vasily Gorbik , Vegard Nossum , Vlastimil Babka , kasan-dev , Linux Memory Management List , Linux-Arch , LKML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 12, 2022 at 2:21 PM Marco Elver wrote: > > On Fri, 1 Jul 2022 at 16:23, Alexander Potapenko wrot= e: > > > > Insert KMSAN hooks that make the necessary bookkeeping changes: > > - poison page shadow and origins in alloc_pages()/free_page(); > > - clear page shadow and origins in clear_page(), copy_user_highpage(); > > - copy page metadata in copy_highpage(), wp_page_copy(); > > - handle vmap()/vunmap()/iounmap(); > > > > Signed-off-by: Alexander Potapenko > > --- > > v2: > > -- move page metadata hooks implementation here > > -- remove call to kmsan_memblock_free_pages() > > > > v3: > > -- use PAGE_SHIFT in kmsan_ioremap_page_range() > > > > v4: > > -- change sizeof(type) to sizeof(*ptr) > > -- replace occurrences of |var| with @var > > -- swap mm: and kmsan: in the subject > > -- drop __no_sanitize_memory from clear_page() > > > > Link: https://linux-review.googlesource.com/id/I6d4f53a0e7eab46fa29f034= 8f3095d9f2e326850 > > --- > > arch/x86/include/asm/page_64.h | 12 ++++ > > arch/x86/mm/ioremap.c | 3 + > > include/linux/highmem.h | 3 + > > include/linux/kmsan.h | 123 +++++++++++++++++++++++++++++++++ > > mm/internal.h | 6 ++ > > mm/kmsan/hooks.c | 87 +++++++++++++++++++++++ > > mm/kmsan/shadow.c | 114 ++++++++++++++++++++++++++++++ > > mm/memory.c | 2 + > > mm/page_alloc.c | 11 +++ > > mm/vmalloc.c | 20 +++++- > > 10 files changed, 379 insertions(+), 2 deletions(-) > > > > diff --git a/arch/x86/include/asm/page_64.h b/arch/x86/include/asm/page= _64.h > > index baa70451b8df5..227dd33eb4efb 100644 > > --- a/arch/x86/include/asm/page_64.h > > +++ b/arch/x86/include/asm/page_64.h > > @@ -45,14 +45,26 @@ void clear_page_orig(void *page); > > void clear_page_rep(void *page); > > void clear_page_erms(void *page); > > > > +/* This is an assembly header, avoid including too much of kmsan.h */ > > All of this code is under an "#ifndef __ASSEMBLY__" guard, does it matter= ? Actually, the comment is a bit outdated. kmsan-checks.h doesn't introduce any unnecessary declarations and can be used here. > > +#ifdef CONFIG_KMSAN > > +void kmsan_unpoison_memory(const void *addr, size_t size); > > +#endif > > static inline void clear_page(void *page) > > { > > +#ifdef CONFIG_KMSAN > > + /* alternative_call_2() changes @page. */ > > + void *page_copy =3D page; > > +#endif > > alternative_call_2(clear_page_orig, > > clear_page_rep, X86_FEATURE_REP_GOOD, > > clear_page_erms, X86_FEATURE_ERMS, > > "=3DD" (page), > > "0" (page) > > : "cc", "memory", "rax", "rcx"); > > +#ifdef CONFIG_KMSAN > > + /* Clear KMSAN shadow for the pages that have it. */ > > + kmsan_unpoison_memory(page_copy, PAGE_SIZE); > > What happens if this is called before the alternative-call? Could this > (in the interest of simplicity) be moved above it? And if you used the > kmsan-checks.h header, it also doesn't need any "ifdef CONFIG_KMSAN" > anymore. Good idea, that'll work. > > +#endif > > } --=20 Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Stra=C3=9Fe, 33 80636 M=C3=BCnchen Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Liana Sebastian Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg