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=-14.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_IN_DEF_DKIM_WL 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 CFA6DC4742C for ; Wed, 4 Nov 2020 14:24:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3287E221F8 for ; Wed, 4 Nov 2020 14:24:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="vzJv83fM" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3287E221F8 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 34F796B0036; Wed, 4 Nov 2020 09:24:03 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2FF636B005D; Wed, 4 Nov 2020 09:24:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A0BA6B0068; Wed, 4 Nov 2020 09:24:03 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0200.hostedemail.com [216.40.44.200]) by kanga.kvack.org (Postfix) with ESMTP id E01A36B0036 for ; Wed, 4 Nov 2020 09:24:02 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id B5B9E3628 for ; Wed, 4 Nov 2020 14:24:01 +0000 (UTC) X-FDA: 77446955082.25.curve10_6008558272c1 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin25.hostedemail.com (Postfix) with ESMTP id 8B6AC1804E3A0 for ; Wed, 4 Nov 2020 14:24:01 +0000 (UTC) X-HE-Tag: curve10_6008558272c1 X-Filterd-Recvd-Size: 6324 Received: from mail-oi1-f196.google.com (mail-oi1-f196.google.com [209.85.167.196]) by imf06.hostedemail.com (Postfix) with ESMTP for ; Wed, 4 Nov 2020 14:24:00 +0000 (UTC) Received: by mail-oi1-f196.google.com with SMTP id m143so12986211oig.7 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=EP2qrID8NFDepNAN0W4diDiC7DN1D3aKMpArJTEB64RLl1HvmUY6cYKxe/6cO72pii Btd7K9W8UtXrnCcjggMrtwNw68SI8sj/FEu5bI7zLPEFxWEKtoqrjZmOqcTjvh5LCdgb /+GjnocEGj4Eyq0ex9CtyEjTpoNOXFNXJ3txUWXjlS8Uvw0FcUaYamKIWO7AfEX2RS15 v6cfPiCIA4TSQDeyEkaqlYh1iKqykGXD+9/h1hyp4Bv7smv/m5Kc9ptPapajaHjQ2TfK ImRJDBN+szGby94/o+b4A16gYinIP0T/70CTxFJ1yN82dcLvow2mqO4nBREG5nAitelM 9p3A== X-Gm-Message-State: AOAM531uwcZYy7URzGgnGHRXw4gIXf1ooLoENdimgiXi+rfyzHY9QB7x EgknGDVLUbhQ/bdM7vzO1VGZxpib4OaRXr3MreSUSg== X-Google-Smtp-Source: ABdhPJycEzgB3bjUR4k0OoZFNu8mEdpOh55snmkjf+FCx7MOcdw5evF2B/ftw0zmhNYGTBUFtEs+2BGfaFd8d5vP+lQ= 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" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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