Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp1379884ybk; Thu, 14 May 2020 07:36:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwnLYd0sh3HAkV2LooQCk+oGVBCpnmjxMwVz5b6dR1Ckv9gy209O6Ooyn1vyrYyznPB3RmY X-Received: by 2002:aa7:d492:: with SMTP id b18mr4362792edr.28.1589467003049; Thu, 14 May 2020 07:36:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589467003; cv=none; d=google.com; s=arc-20160816; b=sWZKvd0ugJPfXS2QX19xIoLDsoCJp83qf0ap+eWrsvWQzzG/3D89xAILy5tjv3TVV3 EJjkiYK9wORy6KV+0JEg2w2C7vVUWMC+6eM0AdG3MI6a5oAhmLqsXSxP6X8rUKKFPfpI 4iE6XjzU5ibr6vSE73PEBS7KFT6xVyfkbtIrb6UTOxAUrE4n/dX/TTifMoCHVUnCwuYl pMW6n9rLBtqZ6adbUFFfy6szkG8poXU7qdyqrGq+KaPUZRFNweAOoo2ypdQ2S0Jm5lvg 6q2AlyLalVuoQBuvU+94BjqrDln5AMcRj8VZGAhtDUtHgAPgnpwtuntW696GL89e2Pqm u5Eg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=Ckm+0+kvDbWTLDuUpHAR4S5EGLFyqYk/xfMWw73TCVI=; b=zCSyZ53EPmaFWhGFlxjhEJ8RIGG9jKCVvCaG9IlnN9UHexjf65l1gVoUdIu0ZqWGig 5yb0yqYO6cVTZ/kpXrs5PM2WyikRhAO+O9xVAYWCADRslzwyEFykC5J0gelrbpzUlV+P 6Tjh2ySsWGAhrw4UT0rXmCzSWGUkyAWIu5bVqovcHJlV0H1zj1fhuvA7WzqlVu/zyAUo iC0US8YpldzIEWuVjXU35khjjToiJt5UVOYEmQgoA60sX8txZlt4eDg3spfYB8bGmhXC u5rZVON4iar7O5xTFmQWP3aOSyiEf+TQeZq/AlxXz2jRSre2uibJTGeshA/UrRjRdfNQ stPg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dr15si2522710ejc.315.2020.05.14.07.36.20; Thu, 14 May 2020 07:36:43 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728061AbgENOda (ORCPT + 99 others); Thu, 14 May 2020 10:33:30 -0400 Received: from foss.arm.com ([217.140.110.172]:37692 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726582AbgENOct (ORCPT ); Thu, 14 May 2020 10:32:49 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DEA7311B3; Thu, 14 May 2020 07:32:48 -0700 (PDT) Received: from seattle-bionic.arm.com.Home (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id F17AE3F71E; Thu, 14 May 2020 07:32:47 -0700 (PDT) From: Oliver Swede To: Will Deacon , Catalin Marinas Cc: Robin Murphy , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 02/13] arm64: kprobes: Drop open-coded exception fixup Date: Thu, 14 May 2020 14:32:16 +0000 Message-Id: <20200514143227.605-3-oli.swede@arm.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200514143227.605-1-oli.swede@arm.com> References: <20200514143227.605-1-oli.swede@arm.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Robin Murphy The short-circuit call to fixup_exception() from kprobe_fault_handler() poses a problem now that the former wants to consume the fault address too, since the common kprobes API offers us no way to pass it through. Fortunately, however, it works out to be unnecessary: - uaccess instructions themselves are not probeable, so at most we should only ever expect to take a fixable fault from the pre or post handlers. - the pre and post handler run with preemption disabled, thus for any fault they may cause, an unhandled return from kprobe_page_fault() will proceed directly to __do_kernel_fault() thanks to the faulthandler_disabled() check. - __do_kernel_fault() will immediately call fixup_exception() unless we're in an EL1 instruction abort, and if we've somehow taken one of those on what we think is the middle of a uaccess routine, then the world is already very on fire. Thus we can reasonably drop the call from kprobe_fault_handler() and leave uaccess fixups to the regular flow. Signed-off-by: Robin Murphy Signed-off-by: Oliver Swede --- arch/arm64/kernel/probes/kprobes.c | 7 ------- 1 file changed, 7 deletions(-) diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c index d1c95dcf1d78..771635360110 100644 --- a/arch/arm64/kernel/probes/kprobes.c +++ b/arch/arm64/kernel/probes/kprobes.c @@ -334,13 +334,6 @@ int __kprobes kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr) */ if (cur->fault_handler && cur->fault_handler(cur, regs, fsr)) return 1; - - /* - * In case the user-specified fault handler returned - * zero, try to fix up. - */ - if (fixup_exception(regs)) - return 1; } return 0; } -- 2.17.1