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=-10.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable 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 8A478C43468 for ; Mon, 21 Sep 2020 14:31:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4CC5C221EC for ; Mon, 21 Sep 2020 14:31:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600698672; bh=krO8zF0GrOs00mBfRnRzTehlbc7iAKlLH4rzrtRfnqc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=Q2VETtxai3vQvbu2KQvQZW2t4s1rioD0yM9gBMsXFS6cizjvfBTUAgfPg/iVzChJ7 v5yZmwK7kPE3Qesu2dBvDae99loaWQu0ZWecgeydPQyAQnw3556fUDhwKAknh5NBdW s+QFawhcOlbz2md8QnIPL7shjC323V/uM5qtIb5E= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727219AbgIUObL (ORCPT ); Mon, 21 Sep 2020 10:31:11 -0400 Received: from mail.kernel.org ([198.145.29.99]:42576 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726395AbgIUObK (ORCPT ); Mon, 21 Sep 2020 10:31:10 -0400 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 821E721D91; Mon, 21 Sep 2020 14:31:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600698669; bh=krO8zF0GrOs00mBfRnRzTehlbc7iAKlLH4rzrtRfnqc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=w1R8TSnt2fQsxgf5LT0ZPAYzmRGdNdiwFgADCYrRTaz1wiToTEyowHYQJXNP5ZzNz JtZqlGCVDO7fXkQN9g3BMcYql263K3PntOmYEZK7IhNKAkYifPH1Sey8npLsTj/D3p nQCI8p0EgRNpuW7EaQlZVyPY9seG884bExHmNR2U= Date: Mon, 21 Sep 2020 15:31:01 +0100 From: Will Deacon To: Marco Elver Cc: akpm@linux-foundation.org, glider@google.com, hpa@zytor.com, paulmck@kernel.org, andreyknvl@google.com, aryabinin@virtuozzo.com, luto@kernel.org, bp@alien8.de, catalin.marinas@arm.com, cl@linux.com, dave.hansen@linux.intel.com, rientjes@google.com, dvyukov@google.com, edumazet@google.com, gregkh@linuxfoundation.org, hdanton@sina.com, mingo@redhat.com, jannh@google.com, Jonathan.Cameron@huawei.com, corbet@lwn.net, iamjoonsoo.kim@lge.com, keescook@chromium.org, mark.rutland@arm.com, penberg@kernel.org, peterz@infradead.org, sjpark@amazon.com, tglx@linutronix.de, vbabka@suse.cz, x86@kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org Subject: Re: [PATCH v3 03/10] arm64, kfence: enable KFENCE for ARM64 Message-ID: <20200921143059.GO2139@willie-the-truck> References: <20200921132611.1700350-1-elver@google.com> <20200921132611.1700350-4-elver@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200921132611.1700350-4-elver@google.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 21, 2020 at 03:26:04PM +0200, Marco Elver wrote: > Add architecture specific implementation details for KFENCE and enable > KFENCE for the arm64 architecture. In particular, this implements the > required interface in . Currently, the arm64 version does > not yet use a statically allocated memory pool, at the cost of a pointer > load for each is_kfence_address(). > > Reviewed-by: Dmitry Vyukov > Co-developed-by: Alexander Potapenko > Signed-off-by: Alexander Potapenko > Signed-off-by: Marco Elver > --- > For ARM64, we would like to solicit feedback on what the best option is > to obtain a constant address for __kfence_pool. One option is to declare > a memory range in the memory layout to be dedicated to KFENCE (like is > done for KASAN), however, it is unclear if this is the best available > option. We would like to avoid touching the memory layout. Sorry for the delay on this. Given that the pool is relatively small (i.e. when compared with our virtual address space), dedicating an area of virtual space sounds like it makes the most sense here. How early do you need it to be available? An alternative approach would be to patch in the address at runtime, with something like a static key to swizzle off the direct __kfence_pool load once we're up and running. Will 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=-10.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham 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 EAE22C43465 for ; Mon, 21 Sep 2020 14:32:57 +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 9630E21D95 for ; Mon, 21 Sep 2020 14:32:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="r46ea3Wr"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="w1R8TSnt" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9630E21D95 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Zmf4BzY+DS+tRTEweGUmtMlotgJGYtoYbdqdSa/tSc4=; b=r46ea3WrSCiXWT1x+xjek0Ho2 9cLtFN4Jhv5g2AG1dlZiSAtRieRIMSPYC94m6Oj7lO8unkx9SEVra4YMo6qbqNhFf0u7EyCqb5VMo tZFeBTOqNGHSkOGEvbLNNY9r+7Mi8xqWycoS3aEfaZhYhyv5nusPlPc9PTzXfuTiPyXy0BprCJ4pz T4O9JLVf/R3CsLeKZ99ju8hQkn0g3KRuiSR0WtgTwCOWts0Wama8M6yYjQ7oFRMVDsbX8BEg1+Kmw aWjqp92O3JI29+HGuhmcIG7orN6WsJBpWijWBrp/2wLuA8leJsXKmCuN60buDfeQcms+X5ksqdPAt On2tGKJ1Q==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kKMqa-00028E-TK; Mon, 21 Sep 2020 14:31:16 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kKMqU-00024P-VE for linux-arm-kernel@lists.infradead.org; Mon, 21 Sep 2020 14:31:13 +0000 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 821E721D91; Mon, 21 Sep 2020 14:31:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600698669; bh=krO8zF0GrOs00mBfRnRzTehlbc7iAKlLH4rzrtRfnqc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=w1R8TSnt2fQsxgf5LT0ZPAYzmRGdNdiwFgADCYrRTaz1wiToTEyowHYQJXNP5ZzNz JtZqlGCVDO7fXkQN9g3BMcYql263K3PntOmYEZK7IhNKAkYifPH1Sey8npLsTj/D3p nQCI8p0EgRNpuW7EaQlZVyPY9seG884bExHmNR2U= Date: Mon, 21 Sep 2020 15:31:01 +0100 From: Will Deacon To: Marco Elver Subject: Re: [PATCH v3 03/10] arm64, kfence: enable KFENCE for ARM64 Message-ID: <20200921143059.GO2139@willie-the-truck> References: <20200921132611.1700350-1-elver@google.com> <20200921132611.1700350-4-elver@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200921132611.1700350-4-elver@google.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200921_103111_245438_A1741F7D X-CRM114-Status: GOOD ( 17.42 ) 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: mark.rutland@arm.com, hdanton@sina.com, linux-doc@vger.kernel.org, peterz@infradead.org, catalin.marinas@arm.com, dave.hansen@linux.intel.com, linux-mm@kvack.org, edumazet@google.com, glider@google.com, hpa@zytor.com, cl@linux.com, sjpark@amazon.com, corbet@lwn.net, x86@kernel.org, kasan-dev@googlegroups.com, mingo@redhat.com, vbabka@suse.cz, rientjes@google.com, aryabinin@virtuozzo.com, keescook@chromium.org, paulmck@kernel.org, jannh@google.com, andreyknvl@google.com, bp@alien8.de, luto@kernel.org, Jonathan.Cameron@huawei.com, tglx@linutronix.de, akpm@linux-foundation.org, dvyukov@google.com, linux-arm-kernel@lists.infradead.org, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, penberg@kernel.org, iamjoonsoo.kim@lge.com 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 Mon, Sep 21, 2020 at 03:26:04PM +0200, Marco Elver wrote: > Add architecture specific implementation details for KFENCE and enable > KFENCE for the arm64 architecture. In particular, this implements the > required interface in . Currently, the arm64 version does > not yet use a statically allocated memory pool, at the cost of a pointer > load for each is_kfence_address(). > > Reviewed-by: Dmitry Vyukov > Co-developed-by: Alexander Potapenko > Signed-off-by: Alexander Potapenko > Signed-off-by: Marco Elver > --- > For ARM64, we would like to solicit feedback on what the best option is > to obtain a constant address for __kfence_pool. One option is to declare > a memory range in the memory layout to be dedicated to KFENCE (like is > done for KASAN), however, it is unclear if this is the best available > option. We would like to avoid touching the memory layout. Sorry for the delay on this. Given that the pool is relatively small (i.e. when compared with our virtual address space), dedicating an area of virtual space sounds like it makes the most sense here. How early do you need it to be available? An alternative approach would be to patch in the address at runtime, with something like a static key to swizzle off the direct __kfence_pool load once we're up and running. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel