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=-3.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 46445C4727C for ; Thu, 1 Oct 2020 11:26:25 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 D69A720691 for ; Thu, 1 Oct 2020 11:26:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Aeo2hn9k"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="QCZTFGmp" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D69A720691 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Wlh/pCqxPsmA4+pR0O5NplGRicy0StvgA1A8j+6B3r4=; b=Aeo2hn9k733fgwRP7sX3vA6FG jtRsDufExQ71IGhoXdh52W+8rXimX3wYb4Jj1EdvNUd/3bYPJ53zm5pxbsZ8swVRkDNPgQjMc9c+2 a5GXfEt7idYQi+N1mvZM4zG72eYoBe1ISGB3UMysysBviliAREjv9FWwR2XgvS4YrTv/naAVEZevD k4TUJQ3GSC6g8OA8pTEb9spJscdL9l5fRRB0wzu4CZ+UZ7Ja4N3IIsC5t2h4aVJF5QcIRqRTwN8Wl PU5+nJXe+Om+52POza/G+gsWeUyvExqQ5rz3IXecX8xNvDjtSKSRJKzOj5WapTzHprseuuhUC5yt/ Zi4TR6yyQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kNwhu-0003pY-VB; Thu, 01 Oct 2020 11:25:07 +0000 Received: from mail-wr1-x443.google.com ([2a00:1450:4864:20::443]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kNwhr-0003nI-Hg for linux-arm-kernel@lists.infradead.org; Thu, 01 Oct 2020 11:25:04 +0000 Received: by mail-wr1-x443.google.com with SMTP id m6so5258991wrn.0 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=KfWjW6bZNHNumn6NPVV4RKW5E1NDGf1/i/hWsuPbqZppJoa1ZAU3ql09+BC/SMIIXW rtaAyuwRQbeMPVrQhYxLL3bpxk/Ppdrisxnwnmu5NnMxtOZCEys+JXNsFksRZA//5gJU ETNc1o81tCOyNAvx1JPvZM14rwN3NDg5YMooaROACakP1tQTr3zQCgkRRBFWYA795EWX dOjg4gPiV6vU45Me/TtJxlZFH2WM7gH0oSC1G27i/6jGP+2M1v8+o7hfgjX73EfqgZS7 T6e0MzsQNdEX9gHyId+RnnOrVSSBeslbMT+e4Zu7r/E19U/c+cXUI2f1iyGC6pf3ZXP1 gedA== X-Gm-Message-State: AOAM5326rTS3Y7UpJtUUK/ywW9pFnV4synKkxSizvd7mpD03LLKvt5kb bQ6d4sxFoSKbUCgcDwvmPf50RvjhBOjLlkNQaf6iFw== 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201001_072503_671811_885586D4 X-CRM114-Status: GOOD ( 22.16 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Hillf Danton , "open list:DOCUMENTATION" , Peter Zijlstra , Catalin Marinas , Dave Hansen , Linux Memory Management List , Eric Dumazet , "H. Peter Anvin" , Christoph Lameter , Will Deacon , SeongJae Park , Jonathan Corbet , the arch/x86 maintainers , kasan-dev , Ingo Molnar , Vlastimil Babka , David Rientjes , Andrey Ryabinin , Marco Elver , Kees Cook , "Paul E. McKenney" , Jann Horn , Andrey Konovalov , Borislav Petkov , Andy Lutomirski , Jonathan Cameron , Thomas Gleixner , Joonsoo Kim , Dmitriy Vyukov , Linux ARM , Greg Kroah-Hartman , LKML , Pekka Enberg , Andrew Morton Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel