Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp2094795ybe; Tue, 3 Sep 2019 07:56:51 -0700 (PDT) X-Google-Smtp-Source: APXvYqxNTxLiZX6uI6mjLVtXdwojojgPimCLGbMDZvfXSl8+A1tRbpYUfc1BT5rA9lsMTbInAhTd X-Received: by 2002:a17:902:f301:: with SMTP id gb1mr34826090plb.249.1567522611838; Tue, 03 Sep 2019 07:56:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567522611; cv=none; d=google.com; s=arc-20160816; b=tn2Cx6EpdMX1PmAf+pfG8j5oj4cPU9t+3pWH5hRXed31+y0g3VDvz2olOwqU+AuzG1 oPfBUzLmESUuWtbg+WFe5/Wuv5f3GK0PRKuwoWttHBKv3gnbK/o7qQEeYdLMtzmVoRrK ImD+xK+DCoI7DAODFZedDZTmZ4PGAoHWrUMQXc/WmdnVIuBb31coF5NOuQ0dSe7jmp9L otN+pqy77BRIxREZ6PpYDeJ4xgdTrOEt3i/Bw4jrhHiiHruvPjebH8zekJDVCGn0Ahmm dCcu5cjv1Y/e+AbJqPpUNHpx5et5Ylwa2QuhU9Vzcogz5QO0uh7JGvtQsjmYYjCxmzbG noLQ== 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:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=CZ8tuOmuka1RKOh9uZYxX64asskdg/IRNCGvFNDvGIA=; b=eQnz9TxhpST2nnj3i/waKbjYVFeZxWWrmfgrkbvyyDoKcyncxiTDGEp3MEF8rAMMu6 irzZBn6uJ7gVjagbWUF8Fa2Veu9e/8dsS3N191oxqhGXqMlFWePrRcenpz6rHn9DUlAi I6osdXcidsZjwXp+HNQ9VspBscHbveroHvty0k9E7KyfDv/btxfgUx33BFYu4owtBpL2 u2I6WDB4PxAceEclsabNum7MTUvsq4ncGRxfpCoHMIhSypravzeCSYm1SrnbyKi65hWB djorn0ZqhR1b3FXN97tmtEYCJfKOySEdhmVUoQWQUrDqaemMQGnFnCtp5PwmNBQr7nNU ivVw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@axtens.net header.s=google header.b=TdUwLWei; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m15si15070996pgt.495.2019.09.03.07.56.35; Tue, 03 Sep 2019 07:56:51 -0700 (PDT) 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=@axtens.net header.s=google header.b=TdUwLWei; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729538AbfICOzn (ORCPT + 99 others); Tue, 3 Sep 2019 10:55:43 -0400 Received: from mail-pl1-f194.google.com ([209.85.214.194]:45081 "EHLO mail-pl1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727069AbfICOzm (ORCPT ); Tue, 3 Sep 2019 10:55:42 -0400 Received: by mail-pl1-f194.google.com with SMTP id x3so2856080plr.12 for ; Tue, 03 Sep 2019 07:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axtens.net; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=CZ8tuOmuka1RKOh9uZYxX64asskdg/IRNCGvFNDvGIA=; b=TdUwLWei7O2GtGjoJhNuW4vtXToUDnCEFGBEiMFSqOyEYvn6uuCUIwq7PO0SfU3C1K 4XWtsZ8X8qoN3HlM5ZOtpCNAZJhSObGLt+wAwQpqWRKZcVQAXZKIY/iEco+KRr/iWOAM gDhizUh7ejhWyPK/F7TxskflMYw2pUoXZlkDU= 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:date:message-id:mime-version :content-transfer-encoding; bh=CZ8tuOmuka1RKOh9uZYxX64asskdg/IRNCGvFNDvGIA=; b=nPIn4hx3EwloI5rxBVySz+3fycAB6oL63jrdSZgHveCn6rBbUeJljGu8K2rWOCDpd/ 6j4cOaEOxCXSQ1gHW1SowllGLe6aqrmP2kveUSKxZtERO4qUqF5zJiuJOFQznTrQ8hNu 0Ih14t0mstF7P3Tn6aInyzhlLglics9im5PfDPDlxUm7uPFPqJGP1VF0P5GQ2S3g1aab dKPjfUXn8HZN/bhiz9G2yryxPoCGLPReKg9MLRs2HWoveYozDuneZzK7UD/3FO276Ojp /k0G4QrvX063yqv60qLtqNIt6LMkrcbwvLiNbKg9jgQZIzbNxCBDJMNCX/myg5Xw5tGO 77HQ== X-Gm-Message-State: APjAAAUnZHaerFXQVEkaMnmDPKX+UbvX6FfbyEu94xw7MF9icMXINvFn UFt51g0kJmAqgM6v3xX1cOnkqQ== X-Received: by 2002:a17:902:543:: with SMTP id 61mr35725696plf.20.1567522542162; Tue, 03 Sep 2019 07:55:42 -0700 (PDT) Received: from localhost (ppp167-251-205.static.internode.on.net. [59.167.251.205]) by smtp.gmail.com with ESMTPSA id 65sm15600780pgf.30.2019.09.03.07.55.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Sep 2019 07:55:41 -0700 (PDT) From: Daniel Axtens To: kasan-dev@googlegroups.com, linux-mm@kvack.org, x86@kernel.org, aryabinin@virtuozzo.com, glider@google.com, luto@kernel.org, linux-kernel@vger.kernel.org, mark.rutland@arm.com, dvyukov@google.com, christophe.leroy@c-s.fr Cc: linuxppc-dev@lists.ozlabs.org, gor@linux.ibm.com, Daniel Axtens Subject: [PATCH v7 0/5] kasan: support backing vmalloc space with real shadow memory Date: Wed, 4 Sep 2019 00:55:31 +1000 Message-Id: <20190903145536.3390-1-dja@axtens.net> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Currently, vmalloc space is backed by the early shadow page. This means that kasan is incompatible with VMAP_STACK. This series provides a mechanism to back vmalloc space with real, dynamically allocated memory. I have only wired up x86, because that's the only currently supported arch I can work with easily, but it's very easy to wire up other architectures, and it appears that there is some work-in-progress code to do this on arm64 and s390. This has been discussed before in the context of VMAP_STACK: - https://bugzilla.kernel.org/show_bug.cgi?id=202009 - https://lkml.org/lkml/2018/7/22/198 - https://lkml.org/lkml/2019/7/19/822 In terms of implementation details: Most mappings in vmalloc space are small, requiring less than a full page of shadow space. Allocating a full shadow page per mapping would therefore be wasteful. Furthermore, to ensure that different mappings use different shadow pages, mappings would have to be aligned to KASAN_SHADOW_SCALE_SIZE * PAGE_SIZE. Instead, share backing space across multiple mappings. Allocate a backing page when a mapping in vmalloc space uses a particular page of the shadow region. This page can be shared by other vmalloc mappings later on. We hook in to the vmap infrastructure to lazily clean up unused shadow memory. v1: https://lore.kernel.org/linux-mm/20190725055503.19507-1-dja@axtens.net/ v2: https://lore.kernel.org/linux-mm/20190729142108.23343-1-dja@axtens.net/ Address review comments: - Patch 1: use kasan_unpoison_shadow's built-in handling of ranges that do not align to a full shadow byte - Patch 3: prepopulate pgds rather than faulting things in v3: https://lore.kernel.org/linux-mm/20190731071550.31814-1-dja@axtens.net/ Address comments from Mark Rutland: - kasan_populate_vmalloc is a better name - handle concurrency correctly - various nits and cleanups - relax module alignment in KASAN_VMALLOC case v4: https://lore.kernel.org/linux-mm/20190815001636.12235-1-dja@axtens.net/ Changes to patch 1 only: - Integrate Mark's rework, thanks Mark! - handle the case where kasan_populate_shadow might fail - poision shadow on free, allowing the alloc path to just unpoision memory that it uses v5: https://lore.kernel.org/linux-mm/20190830003821.10737-1-dja@axtens.net/ Address comments from Christophe Leroy: - Fix some issues with my descriptions in commit messages and docs - Dynamically free unused shadow pages by hooking into the vmap book-keeping - Split out the test into a separate patch - Optional patch to track the number of pages allocated - minor checkpatch cleanups v6: https://lore.kernel.org/linux-mm/20190902112028.23773-1-dja@axtens.net/ Properly guard freeing pages in patch 1, drop debugging code. v7: Add a TLB flush on freeing, thanks Mark Rutland. Explain more clearly how I think freeing is concurrency-safe. Daniel Axtens (5): kasan: support backing vmalloc space with real shadow memory kasan: add test for vmalloc fork: support VMAP_STACK with KASAN_VMALLOC x86/kasan: support KASAN_VMALLOC kasan debug: track pages allocated for vmalloc shadow Documentation/dev-tools/kasan.rst | 63 ++++++++ arch/Kconfig | 9 +- arch/x86/Kconfig | 1 + arch/x86/mm/kasan_init_64.c | 60 ++++++++ include/linux/kasan.h | 31 ++++ include/linux/moduleloader.h | 2 +- include/linux/vmalloc.h | 12 ++ kernel/fork.c | 4 + lib/Kconfig.kasan | 16 +++ lib/test_kasan.c | 26 ++++ mm/kasan/common.c | 230 ++++++++++++++++++++++++++++++ mm/kasan/generic_report.c | 3 + mm/kasan/kasan.h | 1 + mm/vmalloc.c | 45 +++++- 14 files changed, 497 insertions(+), 6 deletions(-) -- 2.20.1