Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1336968pxb; Wed, 4 Nov 2020 06:26:15 -0800 (PST) X-Google-Smtp-Source: ABdhPJyfgbeBwNFqsqHue+ZEneRE4YIASkr5BUJ5MLHbzo9g9it8TQRAxthSr3h2Qr1OUmRPn14z X-Received: by 2002:a17:906:cc4c:: with SMTP id mm12mr11901864ejb.141.1604499975288; Wed, 04 Nov 2020 06:26:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604499975; cv=none; d=google.com; s=arc-20160816; b=vDI46wAdiPMF5m2gLg30yT69dN5x+45RdMW6WxXux2q81aus96b+DNBvAziKM1nEMm bDvwIkCWFXnCs+qn8Ac8OICLGpiHZ1aGwdiV4CQeP5YG+ELD4oo1icBxGJcioQdihKFX E3fcKCAWKNWLZRpwKYKKao1DeZAkzcdwHremD8z/EE/GOPi9offAYvGC4LyluClo8m1X Z7zrKif5p7NNM/0fCvepRlFdOjXktijAqXnFfS200IfIcy0EOy2LCIUKF7pVbzhS9NDi Db4jc1TOc4/g8/TVwMTpelVaDrZtz9gnKAvSI5ik/hpLFAvM3HYMYy/CcR21jViCj//I VZPg== 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=QR9P889TV6Fm+64MkqBDR3Qv0vkmxXCe4guOWfntHO8=; b=UQ7U+sBV5yCJ7MaJU+CyKP/VjzCL7pUpsKIPyWxcES5RKADnCh/bqnhN9z1TK/oSUs FiSLGO3l5NWS+FK2Y+RWD4R411zYOSWzC9Nym2CEWkjfUcheYTkxYcQUpqLnxQ0NOdzw xVPk4WJy8O3wuSt+Cyas7XbicZU4aI+rhDcBRoLneRdNcQF3vZYV0F3lKoCerHYrNm+R jaPLLPHw7E0A5x0Dl6xeMX9m8Gy16l3UIX0XfB6GCN552QXWZIftfprBf4d2MDl33siX 1LkEvSknMcyc5x9mK7TXHcM6tm9fDdL6ef0x99SNI0W2v02UtvqQ0MRWP8qUmpO093xH mAIA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=vzJv83fM; 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 t21si1297442edq.546.2020.11.04.06.25.49; Wed, 04 Nov 2020 06:26:15 -0800 (PST) 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=vzJv83fM; 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 S1726984AbgKDOYB (ORCPT + 99 others); Wed, 4 Nov 2020 09:24:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43888 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726787AbgKDOYA (ORCPT ); Wed, 4 Nov 2020 09:24:00 -0500 Received: from mail-oi1-x241.google.com (mail-oi1-x241.google.com [IPv6:2607:f8b0:4864:20::241]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C1D1DC0613D3 for ; Wed, 4 Nov 2020 06:24:00 -0800 (PST) Received: by mail-oi1-x241.google.com with SMTP id c80so10814064oib.2 for ; Wed, 04 Nov 2020 06:24:00 -0800 (PST) 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=QR9P889TV6Fm+64MkqBDR3Qv0vkmxXCe4guOWfntHO8=; b=vzJv83fMFFUoT2sV52CFQ+1ZEHCw68cWjSWuUVH5eM87Dicq8EfGtuZtTZZnbnaAHd 7U0EYmLE55esvbCscgNLIbOVPeNLSOQTvjOroXj69HUW92jqyJkbmPrhHsOvH4gKQfqr xnvXn+jbNVB5r9AL2pWKbwZr5ceqx9Snrm05aofLik3QQ0gSiLpM/281wXcTWu7o1xdR 9R38+RsoWIYIR5//fgjSO4b/T7cmef/6Zb3ZSGgE95rpUnmQ0GM/CfgfSMaptUlxnJZP jwV8jQl2lh3dyF7LLBY7dvF3y1VjeJGnQgoepgZ4VjW2kHPkdHySKARqwAoCVgICXGG8 Gyjw== 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=QR9P889TV6Fm+64MkqBDR3Qv0vkmxXCe4guOWfntHO8=; b=Cb35pRBQLGzcqb9R0pGNUMqmxejdGRmZYpuovAaNOzl3wc1+H/XMndD90SCCbY3JtR WCxwxza6MbnfsmM/7XoB+PLWgjG4cjEjt2PNcGfpuPxoyzKBzxb3JopO6LHrebmmX4Uf gvjmw25zIOLUHZTTPH7wgfxtCr+uDo0vbe9T36xCTyMUoQd/jf0eJ659NnHtU6UHl8gf Ql7yHP9NstJDY2uZmz1NbPVTw7R+1Ykt0Lh+GmD6NIzBSgu/s2ubu2oaJHSqKnIAd7ch 259e6I7YwNP7cYQqixEy7YJpH9ChW6fQk2Devr/SVxdujpRRzsy7/3q18GfAv8LcoLTR fVLQ== X-Gm-Message-State: AOAM530KDzTK4mFjkaa6+NqGunc1pzLgVstTgK5einIAPT5XnDEwbqPr VWPlVgDXtjpjmAdw/5f56HipDh/l9zQrEPV5Fa6VxQ== X-Received: by 2002:aca:a988:: with SMTP id s130mr2710278oie.172.1604499839884; Wed, 04 Nov 2020 06:23:59 -0800 (PST) MIME-Version: 1.0 References: <20201103175841.3495947-1-elver@google.com> <20201103175841.3495947-4-elver@google.com> <20201104130111.GA7577@C02TD0UTHF1T.local> In-Reply-To: <20201104130111.GA7577@C02TD0UTHF1T.local> From: Marco Elver Date: Wed, 4 Nov 2020 15:23:48 +0100 Message-ID: Subject: Re: [PATCH v7 3/9] arm64, kfence: enable KFENCE for ARM64 To: Mark Rutland Cc: Andrew Morton , Alexander Potapenko , "H. Peter Anvin" , "Paul E. McKenney" , Andrey Konovalov , Andrey Ryabinin , Andy Lutomirski , Borislav Petkov , Catalin Marinas , Christoph Lameter , Dave Hansen , David Rientjes , Dmitry Vyukov , Eric Dumazet , Greg Kroah-Hartman , Hillf Danton , Ingo Molnar , Jann Horn , Jonathan Cameron , Jonathan Corbet , Joonsoo Kim , =?UTF-8?Q?J=C3=B6rn_Engel?= , Kees Cook , Pekka Enberg , Peter Zijlstra , SeongJae Park , Thomas Gleixner , Vlastimil Babka , Will Deacon , "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 Wed, 4 Nov 2020 at 14:06, Mark Rutland wrote: > On Tue, Nov 03, 2020 at 06:58:35PM +0100, 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 . > > > > KFENCE requires that attributes for pages from its memory pool can > > individually be set. Therefore, force the entire linear map to be mapped > > at page granularity. Doing so may result in extra memory allocated for > > page tables in case rodata=full is not set; however, currently > > CONFIG_RODATA_FULL_DEFAULT_ENABLED=y is the default, and the common case > > is therefore not affected by this change. > > > > Reviewed-by: Dmitry Vyukov > > Co-developed-by: Alexander Potapenko > > Signed-off-by: Alexander Potapenko > > Signed-off-by: Marco Elver > > Thanks for dilligently handling all the review feedback. This looks good > to me now, so FWIW: > > Reviewed-by: Mark Rutland Thank you! > There is one thing that I thing we should improve as a subsequent > cleanup, but I don't think that should block this as-is. > > > +#define KFENCE_SKIP_ARCH_FAULT_HANDLER "el1_sync" > > IIUC, the core kfence code is using this to figure out where to trace > from when there's a fault taken on an access to a protected page. Correct. > It would be better if the arch code passed the exception's pt_regs into > the kfence fault handler, and the kfence began the trace began from > there. That would also allow for dumping the exception registers which > can help with debugging (e.g. figuring out how the address was derived > when it's calculated from multiple source registers). That would also be > a bit more robust to changes in an architectures' exception handling > code. Good idea, thanks. I guess there's no reason to not want to always skip to instruction_pointer(regs)? In which case I can prepare a patch to make this change. If this should go into a v8, please let me know. But it'd be easier as a subsequent patch as you say, given it'll be easier to review and these patches are in -mm now. Thanks, -- Marco