Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp3940268pxk; Tue, 29 Sep 2020 09:54:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxDrPKnStsaZo/RKH8+Am1T3HGPbli03HF2BUR5Wn58SWmFyffZGKbT104EHCTeMljo6pFD X-Received: by 2002:aa7:d9c9:: with SMTP id v9mr2539728eds.103.1601398467755; Tue, 29 Sep 2020 09:54:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601398467; cv=none; d=google.com; s=arc-20160816; b=OKgb5r9sGT6dg4aROUB0EddGKSHGm0GxP1v6+AZVcvQWFe1gc3stho1Gt5VvFdp2uh h4/VG+2m5DrzhGwKV5VWnJDSV5vTw+OwOSDFOUPOhIosXQGb5oiyB/ELsKBn0G2hPbPj YhBKpijXoLEKXDY3EEFoO38maBXnjgATrCJzYPG00EhelLXc22gw+4Vw2csRzC7NWMaM R1sUJ5ED6K5+Z2DVthKHzkWfK4rQTda+LvKHD9RgWu4y3/UWbJ08fzeiDMyOlr0D7/zp jbl8iAwgl7TYN1tn4NsLeKPMhqUrarPX1F1p5S3mUKeoP4ecyvfcW37YPICOHfYJeqDt tNlQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=09UR9SuLwWLskf/m2OzcloavK4YxVGusfREn6SghSM8=; b=rr4xUTq0F6BOrTxantDbqAE0qZaovx6inlQUX/3EOrgSOCnzOHCBl4cnZIfO+aAyoW ChZxAfcnq46rK68HbykdKwcxLPhDhPIXKsHHgktUzek8yGX+sHYenLeb1mS/Yzo7fDCe kuaJYzGcKwMs5jEhAMurZb5lP3YLaJfHXQyDA/QP24VdDqh63bEGDp9YQ6VL+7sQubCB d5JAldUR/vsK2YKZreUceFBaM8Tvq1tmDR8HJ9zblZI9GAq0hhkLPMqlOnBO1fTRjNYu wM91Bf2j0Vmg1gnkaL5U2LS02Jl7TpJ4PBrqUZ5OcZMLabtnRvtNJYE7EDVrpJks1szV kFHw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=VqnhGR7e; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f8si1511974eja.717.2020.09.29.09.54.04; Tue, 29 Sep 2020 09:54:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=VqnhGR7e; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1728923AbgI2QwZ (ORCPT + 99 others); Tue, 29 Sep 2020 12:52:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59100 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728392AbgI2QwZ (ORCPT ); Tue, 29 Sep 2020 12:52:25 -0400 Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A87EAC0613D0 for ; Tue, 29 Sep 2020 09:52:24 -0700 (PDT) Received: by mail-wm1-x342.google.com with SMTP id k18so5545016wmj.5 for ; Tue, 29 Sep 2020 09:52:24 -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=09UR9SuLwWLskf/m2OzcloavK4YxVGusfREn6SghSM8=; b=VqnhGR7e5Y+QNVAikhl7b51GeAH0EF7GfRijsXSqLCApylXqui81r15GHmRn5NZZkT WLGdkW9xG86unltU1fBRLlBax2QXjGmvOovG6PuhQ3fY0nztGMo6g++2xONgQDoiLAvw rcAjPYA6JiB6PZfyVfONcNCvNGQdZW5qr+iMHxyqQeQEIUsS5oODanUYK1uAmAFWzQXK n1ah0v3kFA89AXxKTVDnYkAZIlSFvFE0WDktm+kOn3FueQE9hONwJHlB2HswC4WWrgGR WulwwyJT9pFPdi2ANZocEl9EwCJDK1CvAkQD7Ipkiu9AZh3v8WgO63C2qhDrs/Mqwhox hpuQ== 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=09UR9SuLwWLskf/m2OzcloavK4YxVGusfREn6SghSM8=; b=BG7IWlp1p7VBWVCnMxJ31HQ+7FZqrqLs7OAqFXCTleDoSYouU7rQztg5PveGuEsqwF SoZY6K/Vm+RP+rNzmW+Hw3S9T6a5yF4WkcpYAEmrOQIbym/G+yH2lI1ftaHA5HT7Nprr RqNt7xFKBtTuvAMzXKXeVAfvTnrdjXIBV+hkukv/4h23q/lU9/EPP6dNubvQF+NmOz5I lrGBygKU4C3z/EDUH8c4fQCLD6e0Gy7y2QavcRb4et5d8k8bJa4wZkfMEdFzwlKQp6TF DirXTwORSiqrsDx/4CeEKBrIj14JlmICTgp8R7vhn0f5++ueaKIz8uTIoI7xO3PPym0K 9SkA== X-Gm-Message-State: AOAM531k+2+UztEogrPgylSAEpkU126BccyYmsa1LHDXyzs/MY4CqE3S lKXE2jF9vzT23qIEyGNod5/Bs8jrr7t3X7ffCa4AFA== X-Received: by 2002:a1c:b388:: with SMTP id c130mr5533839wmf.175.1601398343136; Tue, 29 Sep 2020 09:52:23 -0700 (PDT) MIME-Version: 1.0 References: <20200921132611.1700350-1-elver@google.com> <20200921132611.1700350-4-elver@google.com> <20200921143059.GO2139@willie-the-truck> <20200921174357.GB3141@willie-the-truck> <20200929135355.GA53442@C02TD0UTHF1T.local> In-Reply-To: <20200929135355.GA53442@C02TD0UTHF1T.local> From: Alexander Potapenko Date: Tue, 29 Sep 2020 18:52:11 +0200 Message-ID: Subject: Re: [PATCH v3 03/10] arm64, kfence: enable KFENCE for ARM64 To: Mark Rutland Cc: Marco Elver , Will Deacon , 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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > On x86 we just do `char __kfence_pool[KFENCE_POOL_SIZE] ...;` to > > statically allocate the pool. On arm64 this doesn't seem to work > > because static memory doesn't have struct pages? > > Are you using virt_to_page() directly on that statically-allocated > __kfence_pool? If so you'll need to use lm_alias() if so, as is done in > mm/kasan/init.c. > > Anything statically allocated is part of the kernel image address range > rather than the linear/direct map, and doesn't have a valid virt addr, > but its linear map alias does. > > If you enable CONFIG_DEBUG_VIRTUAL you should get warnings if missing > lm_alias() calls. I just checked that on x86 CONFIG_DEBUG_VIRTUAL prints no warnings on our tests. virt_addr_valid() also returns true for addresses belonging to __kfence_pool declared in BSS. Could this be related to x86 mapping the kernel twice?