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.8 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 D6BE2C433E7 for ; Wed, 14 Oct 2020 19:15:17 +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 6192A20757 for ; Wed, 14 Oct 2020 19:15:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ntk8UYzJ"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="QoXiKIK/" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6192A20757 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=Po7/D+WCYa3nOs0wrARifNJhhlvMicWJ87YJZGEp50w=; b=ntk8UYzJILSf8hJ5YYzcDfhgt F3ex56Kw73uF8dxZZZpOOwmTmHHCDOj9cM4HA8APx1y3gB8tD8Dx/iYzLuBefPm9BSafj+RX891ao aifZXw/RY7E3c/385R+5pEu7P82FPurl0G3Ibj9MIFySJlUXv28T8JgKeSZXmt2DhdzMRGW7C7d8s nNify2INQDGzi5TWUrLCPYoi87+2lhVvxTEKvTYXi47jKuepRFZFKGByVtkcPhr16RoBDkzbaYjku KoWwgNnA8x0MxL4BZoB7gBnZ+HZfJmnoQ/3VR7oNznWsn4MH+xiND5gzHKrHGZUb6bMJPWw3lnkUF ealKocIvw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kSmDX-0001FA-NW; Wed, 14 Oct 2020 19:13:43 +0000 Received: from mail-oi1-x241.google.com ([2607:f8b0:4864:20::241]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kSmCk-0000rS-5U for linux-arm-kernel@lists.infradead.org; Wed, 14 Oct 2020 19:12:55 +0000 Received: by mail-oi1-x241.google.com with SMTP id c13so342557oiy.6 for ; Wed, 14 Oct 2020 12:12:51 -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=ZeIyBZH1DlMazqL3WPQEWDzdrz72p5JAZek4MEGZox0=; b=QoXiKIK/b6kRcW6PeofIscaKrIR52aRKjK4qvKq8aq8FfwkJyBRTC0ZEcPvRccLrhQ u+FpbklPzt4CeRTorbjIFdSCfLOkMOflGkHc8h4q1COYv3UEi+R3nUAjbveX5cXR2V+p wCE7CgcPvaOdVfjawROqxRJ7rqWpmE5mbP3mPrTxWm8PrpDc5KuzQKTsrTsz1O27Csog KFs0ESSPZ2TcgNQ0ZsN3PYi4798fLNTOv9c63rkDZFfqUNSPRyVsOvlzYgs40HlLtSFs kgRH3yS4GXzfnqQaLDPtJF1yLg233FCVeq6yhxM4LWENkAIt6KpBXFiQVKjApYHQqAIV s10A== 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=ZeIyBZH1DlMazqL3WPQEWDzdrz72p5JAZek4MEGZox0=; b=VHhdk+pPL7IiUaH3uyeW5guuLHWw1/8sryT5EPIWlikcn+DoFHZCEgA03rIRZhvzgd apX3PJSd+cb8iNMDnJDf8V2K6cpqyjCTVK8keauh23vExZbZWBkmln3hHj6cOG5FEAx+ v4pT2kLxSe50COqc04n2Wl4PcGyxIYBgk6yDqwk4BvHL/bEBBbJN6zrqgSeyFiY/NnjS sbn6yp/oE2aaTJHlYpbAiIcaBQ1gg7Bn3rxNcgLvOK+GvGfhxyRmiAfnuGvvaSOz0c4K RZ3oo6sKW2nO/AZNyaqX1e291wPGeQ2+NVAAeezWD6fpJqG3TA2ftpLmndCFIrrPy59j m6WQ== X-Gm-Message-State: AOAM532U2Lm4/YnhGjkDFNXefc8ED94nGbwrlBrz+IsZAmSflc5lY/Q+ Z/DA7uYg7xz/PcaJ3/1QnraUiI5L46efIN5TRJrCNg== X-Google-Smtp-Source: ABdhPJxI0rp8pxtj3cUByNFiFU6rolm7IayLQiq14hVoYtiHEk/OXGhVI9evgkFYJ4/Vus6tK95a5TvDzRsE+g22i1M= X-Received: by 2002:aca:3d07:: with SMTP id k7mr537643oia.172.1602702769984; Wed, 14 Oct 2020 12:12:49 -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> <20201001175716.GA89689@C02TD0UTHF1T.local> <20201008104501.GB72325@C02TD0UTHF1T.local> In-Reply-To: <20201008104501.GB72325@C02TD0UTHF1T.local> From: Marco Elver Date: Wed, 14 Oct 2020 21:12:37 +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-20201014_151254_259676_DC4156D0 X-CRM114-Status: GOOD ( 33.17 ) 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 , Alexander Potapenko , "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 , Kees Cook , "Paul E. McKenney" , Jann Horn , Andrey Konovalov , Borislav Petkov , Andy Lutomirski , Jonathan Cameron , Thomas Gleixner , Andrew Morton , Dmitriy Vyukov , Linux ARM , Greg Kroah-Hartman , LKML , Pekka Enberg , Joonsoo Kim 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 On Thu, 8 Oct 2020 at 12:45, Mark Rutland wrote: > On Thu, Oct 08, 2020 at 11:40:52AM +0200, Marco Elver wrote: > > On Thu, 1 Oct 2020 at 19:58, Mark Rutland wrote: > > [...] > > > > > If you need virt_to_page() to work, the address has to be part of the > > > > > linear/direct map. > > [...] > > > > > > What's the underlying requirement here? Is this a performance concern, > > > codegen/codesize, or something else? > > > > It used to be performance, since is_kfence_address() is used in the > > fast path. However, with some further tweaks we just did to > > is_kfence_address(), our benchmarks show a pointer load can be > > tolerated. > > Great! > > I reckon that this is something we can optimize in futue if necessary > (e.g. with some form of code-patching for immediate values), but it's > good to have a starting point that works everywhere! > > [...] > > > > I'm not too worried about allocating this dynamically, but: > > > > > > * The arch code needs to set up the translation tables for this, as we > > > cannot safely change the mapping granularity live. > > > > > > * As above I'm fairly certain x86 needs to use a carevout from the > > > linear map to function correctly anyhow, so we should follow the same > > > approach for both arm64 and x86. That might be a static carevout that > > > we figure out the aliasing for, or something entirely dynamic. > > > > We're going with dynamically allocating the pool (for both x86 and > > arm64), since any benefits we used to measure from the static pool are > > no longer measurable (after removing a branch from > > is_kfence_address()). It should hopefully simplify a lot of things, > > given all the caveats that you pointed out. > > > > For arm64, the only thing left then is to fix up the case if the > > linear map is not forced to page granularity. > > The simplest way to do this is to modify arm64's arch_add_memory() to > force the entire linear map to be mapped at page granularity when KFENCE > is enabled, something like: > [...] > > ... and I given that RODATA_FULL_DEFAULT_ENABLED is the default, I > suspect it's not worth trying to only for that for the KFENCE region > unless someone complains. We've got most of this sorted now for v5 -- thank you! The only thing we're wondering now, is if there are any corner cases with using memblock_alloc'd memory for the KFENCE pool? (We'd like to avoid page alloc's MAX_ORDER limit.) We have a version that passes tests on x86 and arm64, but checking just in case. :-) Thanks, -- Marco _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel