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=-11.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no 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 D8037C4727F for ; Thu, 1 Oct 2020 11:25:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3BCB721707 for ; Thu, 1 Oct 2020 11:25:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="QCZTFGmp" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3BCB721707 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 554BD6B005C; Thu, 1 Oct 2020 07:25:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 503436B0062; Thu, 1 Oct 2020 07:25:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3F2828E0001; Thu, 1 Oct 2020 07:25:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0133.hostedemail.com [216.40.44.133]) by kanga.kvack.org (Postfix) with ESMTP id 2B0676B005C for ; Thu, 1 Oct 2020 07:25:03 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id C56CD180AD761 for ; Thu, 1 Oct 2020 11:25:02 +0000 (UTC) X-FDA: 77323124844.20.berry18_33094e12719b Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin20.hostedemail.com (Postfix) with ESMTP id 94B7A180C07A3 for ; Thu, 1 Oct 2020 11:25:02 +0000 (UTC) X-HE-Tag: berry18_33094e12719b X-Filterd-Recvd-Size: 6448 Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by imf26.hostedemail.com (Postfix) with ESMTP for ; Thu, 1 Oct 2020 11:25:02 +0000 (UTC) Received: by mail-wr1-f65.google.com with SMTP id w5so5238130wrp.8 for ; Thu, 01 Oct 2020 04:25:01 -0700 (PDT) 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; bh=rIrqsNB2CCkv+5Up492E6RUjeUyfI0426YjKqnUmMhw=; b=QCZTFGmpea3i9RVr/67JK8ZN36dSLFeJjSgI6yS88Ca8rxeTc7ji8wthxQWMpuy6L5 u38dUNAPrZ77ARjpb1ujurLSC6fur8w2OAkwLL02Za5S8+J4n9uwpZdfMlMOgj5kIS/x YH8nDHFCe4v3IU0+qrJygKqAgr+frNx0suL3E6RPhxO+uEp8EGRu3tKOOHOJAVwvjSnJ 1khf7ghrPbRMUyZOLWNxZ8J2oV4KE7oaZDCSSE5t6aEdfcrbfOkDVUWOjiVSKQnB0cay kTucVLYQhI+hSkAC7BzKpjTg8tSYzuviz1LuY68gXQYPam7gwzl/XpH8Ue9QmTxNm6jZ BV9A== 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; bh=rIrqsNB2CCkv+5Up492E6RUjeUyfI0426YjKqnUmMhw=; b=RsDMz3rTgE4D0oEIXtsiOiSvkyOTTeBGuk2mXyBsVCEyvKIETKqdfSEru6I6zd5llA 5d4x+xZ0Ob+3b5MZObrDgnbnX+Q/yVGkhg8AcuUE6hEwRPy5cctOYOPBuCcVolKZa211 +pVF0zmdnSgVH5bSfg4Lj6xuHdy5rXnfPU/h0EfNCAst4hHO0HOJ2XSFaGMSpCWdYf1y 3V6KulpBbvVHW++hxUTlmUBqDNH61zKpiUyq8I6ZBBeLMu0U4cfRRhIfFuxLoAoVGCJO KCmkE60xhGU34PuvCI4YKh0sD5d5ljEkACqNWUW7eH7oTAc/FVcxLlvMVFY10H5fdfzH Q2rg== X-Gm-Message-State: AOAM5323mz/11254xxgu1LJ4RJ+s26ExT+EuqsTHogaIegbgIZszxlH3 h1OPVeEDjdoVfV+D82rdED6PpFZg2esZq81wO7u2WQ== X-Google-Smtp-Source: ABdhPJzGuN41NKZ9z4kTko7jROyZG/OJ7AHb1nE6sC1xk6wR5ZdnjF4TzEwMBHuBpFfZC3poYstIgrbkwtRyeClLy/A= X-Received: by 2002:adf:f101:: with SMTP id r1mr8370892wro.314.1601551500540; Thu, 01 Oct 2020 04:25:00 -0700 (PDT) MIME-Version: 1.0 References: <20200921132611.1700350-1-elver@google.com> <20200921132611.1700350-4-elver@google.com> <20200921143059.GO2139@willie-the-truck> <20200929140226.GB53442@C02TD0UTHF1T.local> In-Reply-To: <20200929140226.GB53442@C02TD0UTHF1T.local> From: Alexander Potapenko Date: Thu, 1 Oct 2020 13:24:49 +0200 Message-ID: Subject: Re: [PATCH v3 03/10] arm64, kfence: enable KFENCE for ARM64 To: Mark Rutland Cc: Will Deacon , Marco Elver , Andrew Morton , "H. Peter Anvin" , "Paul E. McKenney" , Andrey Konovalov , Andrey Ryabinin , Andy Lutomirski , Borislav Petkov , Catalin Marinas , Christoph Lameter , Dave Hansen , David Rientjes , Dmitriy Vyukov , Eric Dumazet , Greg Kroah-Hartman , Hillf Danton , Ingo Molnar , Jann Horn , Jonathan Cameron , Jonathan Corbet , Joonsoo Kim , Kees Cook , Pekka Enberg , Peter Zijlstra , SeongJae Park , Thomas Gleixner , Vlastimil Babka , "the arch/x86 maintainers" , "open list:DOCUMENTATION" , LKML , kasan-dev , Linux ARM , Linux Memory Management List Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Mark, > If you need virt_to_page() to work, the address has to be part of the > linear/direct map. > > If you need to find the struct page for something that's part of the > kernel image you can use virt_to_page(lm_alias(x)). > > > Looks like filling page table entries (similarly to what's being done > > in arch/arm64/mm/kasan_init.c) is not enough. > > I thought maybe vmemmap_populate() would do the job, but it didn't > > (virt_to_pfn() still returns invalid PFNs). > > As above, I think lm_alias() will solve the problem here. Please see > that and CONFIG_DEBUG_VIRTUAL. The approach you suggest works to some extent, but there are some caveats. To reiterate, we are trying to allocate the pool (2Mb by default, but users may want a bigger one, up to, say, 64 Mb) in a way that: (1) The underlying page tables support 4K granularity. (2) is_kfence_address() (checks that __kfence_pool <= addr <= __kfence_pool + KFENCE_POOL_SIZE) does not reference memory (3) For addresses belonging to that pool virt_addr_valid() is true (SLAB/SLUB rely on that) On x86 we achieve (2) by making our pool a .bss array, so that its address is known statically. Aligning that array on 4K and calling set_memory_4k() ensures that (1) is also fulfilled. (3) seems to just happen automagically without any address translations. Now, what we are seeing on arm64 is different. My understanding (please correct me if I'm wrong) is that on arm64 only the memory range at 0xffff000000000000 has valid struct pages, and the size of that range depends on the amount of memory on the system. This probably means we cannot just pick a fixed address for our pool in that range, unless it is very close to 0xffff000000000000. If we allocate the pool statically in the way x86 does (assuming we somehow resolve (1)), we can apply lm_alias() to addresses returned by the KFENCE allocator, making kmalloc() always return addresses from the linear map and satisfying (3). But in that case is_kfence_address() will also need to be updated to compare the addresses to lm_alias(__kfence_pool), and this becomes more heavyweight than just reading the address from memory. So looks like it's still more preferable to allocate the pool dynamically on ARM64, unless there's a clever trick to allocate a fixed address in the linear map (DTS maybe?) Thanks, Alex