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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT 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 66F47C433E1 for ; Tue, 23 Jun 2020 20:51:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4430620675 for ; Tue, 23 Jun 2020 20:51:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592945498; bh=xVcMwRcZOs9nllUUvgVRYPKnljVcY/QurHMY3v/zMn4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=G08osqupI4O/31qQTT7n3r4cRDr9KHjMzWmaI/T5CZUoZ1WvxqK8Ar5dQe4gVXCuU YYD8QzPIVAiC6c8KhJu7wcsmnxiJBYFo0zGLg6wzU7qUQpIllqDLiekiafHUss78lX ieErl2pnbaleZ94d9McAOAgFbh2+Pt8/b+5XIHvk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404083AbgFWUr6 (ORCPT ); Tue, 23 Jun 2020 16:47:58 -0400 Received: from mail.kernel.org ([198.145.29.99]:46740 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404081AbgFWUr6 (ORCPT ); Tue, 23 Jun 2020 16:47:58 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (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 C218021548; Tue, 23 Jun 2020 20:47:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592945278; bh=xVcMwRcZOs9nllUUvgVRYPKnljVcY/QurHMY3v/zMn4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ISju+LuQa5r7Qc3R2WnCKJiwfW9kpqYlB8cK30l76AxfCld76Dsc2kdh2kjeuQ26R 2esmPL7v2OSq4y7qy7lG8QIxy8YZr8DucfoiSPmMVL0boc39X2E9eDJof80fxxmTnH 5SZgVV17EFB+vQZcZMLoDjiUvS42sD8VzQYwF0qA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Catalin Marinas , James Morse , Luis Machado , Will Deacon , Sasha Levin Subject: [PATCH 4.14 109/136] arm64: hw_breakpoint: Dont invoke overflow handler on uaccess watchpoints Date: Tue, 23 Jun 2020 21:59:25 +0200 Message-Id: <20200623195309.158032743@linuxfoundation.org> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20200623195303.601828702@linuxfoundation.org> References: <20200623195303.601828702@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Will Deacon [ Upstream commit 24ebec25fb270100e252b19c288e21bd7d8cc7f7 ] Unprivileged memory accesses generated by the so-called "translated" instructions (e.g. STTR) at EL1 can cause EL0 watchpoints to fire unexpectedly if kernel debugging is enabled. In such cases, the hw_breakpoint logic will invoke the user overflow handler which will typically raise a SIGTRAP back to the current task. This is futile when returning back to the kernel because (a) the signal won't have been delivered and (b) userspace can't handle the thing anyway. Avoid invoking the user overflow handler for watchpoints triggered by kernel uaccess routines, and instead single-step over the faulting instruction as we would if no overflow handler had been installed. (Fixes tag identifies the introduction of unprivileged memory accesses, which exposed this latent bug in the hw_breakpoint code) Cc: Catalin Marinas Cc: James Morse Fixes: 57f4959bad0a ("arm64: kernel: Add support for User Access Override") Reported-by: Luis Machado Signed-off-by: Will Deacon Signed-off-by: Sasha Levin --- arch/arm64/kernel/hw_breakpoint.c | 44 ++++++++++++++++++------------- 1 file changed, 26 insertions(+), 18 deletions(-) diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c index 95697a9c12451..6e96cea99a4ec 100644 --- a/arch/arm64/kernel/hw_breakpoint.c +++ b/arch/arm64/kernel/hw_breakpoint.c @@ -738,6 +738,27 @@ static u64 get_distance_from_watchpoint(unsigned long addr, u64 val, return 0; } +static int watchpoint_report(struct perf_event *wp, unsigned long addr, + struct pt_regs *regs) +{ + int step = is_default_overflow_handler(wp); + struct arch_hw_breakpoint *info = counter_arch_bp(wp); + + info->trigger = addr; + + /* + * If we triggered a user watchpoint from a uaccess routine, then + * handle the stepping ourselves since userspace really can't help + * us with this. + */ + if (!user_mode(regs) && info->ctrl.privilege == AARCH64_BREAKPOINT_EL0) + step = 1; + else + perf_bp_event(wp, regs); + + return step; +} + static int watchpoint_handler(unsigned long addr, unsigned int esr, struct pt_regs *regs) { @@ -747,7 +768,6 @@ static int watchpoint_handler(unsigned long addr, unsigned int esr, u64 val; struct perf_event *wp, **slots; struct debug_info *debug_info; - struct arch_hw_breakpoint *info; struct arch_hw_breakpoint_ctrl ctrl; slots = this_cpu_ptr(wp_on_reg); @@ -785,25 +805,13 @@ static int watchpoint_handler(unsigned long addr, unsigned int esr, if (dist != 0) continue; - info = counter_arch_bp(wp); - info->trigger = addr; - perf_bp_event(wp, regs); - - /* Do we need to handle the stepping? */ - if (is_default_overflow_handler(wp)) - step = 1; + step = watchpoint_report(wp, addr, regs); } - if (min_dist > 0 && min_dist != -1) { - /* No exact match found. */ - wp = slots[closest_match]; - info = counter_arch_bp(wp); - info->trigger = addr; - perf_bp_event(wp, regs); - /* Do we need to handle the stepping? */ - if (is_default_overflow_handler(wp)) - step = 1; - } + /* No exact match found? */ + if (min_dist > 0 && min_dist != -1) + step = watchpoint_report(slots[closest_match], addr, regs); + rcu_read_unlock(); if (!step) -- 2.25.1