Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp10523626imu; Thu, 6 Dec 2018 02:34:24 -0800 (PST) X-Google-Smtp-Source: AFSGD/WNLQg9x3OiDo2WB3WyVFkChYn/L2ck0ZAJgvQhQOH385I4i19R1JKDH6CvuLWT1QputsAk X-Received: by 2002:a17:902:728c:: with SMTP id d12mr27293750pll.284.1544092464595; Thu, 06 Dec 2018 02:34:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544092464; cv=none; d=google.com; s=arc-20160816; b=lITPlwKb4pfZhaXlo9s2pJbwtRviAXXyUtBmzy0jG2P/NwmsrPsgSa9iLjW8PfogHJ k5w5ClTUFjtzaLwEsEPxYvNp30FiwL2XuOUVAk/vo1OZk4TFadQIq6RyubaFAbG7WStF CI+hO/eTYGeIu0Fcm0ekIiClz1vlaQf5iPNV1GvvOazalAyIelE+4HxnrKMYC9daUQfs 94Wl+96jWRDmwZjpmKkXnqSkMt7ij9FRI4eQN6gR+blfVWx4zFGXE1zw+OMSKzTXnrGK URi+aKueWEnk5G2GbMF3OQYVLT9sAygpo20m7ZxwxzhU6QsAEisLS1MvG0A0Khs635mP NdRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=NjA60Ta70B0BdffOxwLfM6fA5laqa+qcnZ7JQd20IsE=; b=jYY7vkL4H4Tv6JzveBiIDyFlgLW4v5ZtBvgeBBg4vBkyoY37x0D9DMVyArXDLar2Rz uMWrDxHOZYN3JW6XsRJmJjx0tta7OfR3cca4g2bIh7xnkkbv0RhowCAcT0v9z3vz/R4W zVNpHijBjXaJy9WHMTSMTOMz9e8EVdWF+965IEg6/nlisdx8d49Itm8wLE0V2/7MaZOW ZYSFdBWx8zMddzPm7LL/dMzTOpbtVnDQC6vfoLwLUPv8S9wTuZa43D/vp0vbiQTt5p8w GmsVdZ9RlQURN4DtxESabKAEp0ReARvPY136RRbPLrOB87rAzJAndU2U2MGtXQ8jGAH/ 9NdQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=k1HrU0KS; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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. [209.132.180.67]) by mx.google.com with ESMTP id 3si22392279plq.138.2018.12.06.02.34.08; Thu, 06 Dec 2018 02:34:24 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=k1HrU0KS; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 S1729369AbeLFKb7 (ORCPT + 99 others); Thu, 6 Dec 2018 05:31:59 -0500 Received: from mail-io1-f65.google.com ([209.85.166.65]:44910 "EHLO mail-io1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729054AbeLFKb4 (ORCPT ); Thu, 6 Dec 2018 05:31:56 -0500 Received: by mail-io1-f65.google.com with SMTP id r200so19241206iod.11 for ; Thu, 06 Dec 2018 02:31:55 -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=NjA60Ta70B0BdffOxwLfM6fA5laqa+qcnZ7JQd20IsE=; b=k1HrU0KSEVnr9c1TqhF36VcNxLHh3i8j8MK1D8HFHqd7xVR8V/Eni9IWlGvZjptFwQ x035l63fXncSWvOHa1z8Skf3jP60uEjV0WtpVh4VicCsuf5NvYYki80r+UKnfkMoqnc+ /b8TNUjzp/kHjvxAXUl9lrkk9aniDQcMAeZX4yU8GCAlgllhHXgBl7EphuZXsJUHSDKg KV1zrOBHERkYxjAEuk/W/ZIPnTfc+n1pKMzapVxEjyWlJOOOo8tUXTFBkvrp6xU46VT3 LLHauH2FiLuid+CfBIs3heWHRA2NeYspmhyGtVd6rtU55S4OTgZXKlcdByg0wNhdCjP+ zz2A== 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=NjA60Ta70B0BdffOxwLfM6fA5laqa+qcnZ7JQd20IsE=; b=FZ4jvbjzbgVhzKOXICtVsTo/IkSAKpMkzbcj2UJLIXRVWKR+ZDZZVyi0Z5VExuN/Hj FMImSP0xJjVOYuq0nTK4+hmcO+2Nb1AmiJUrdGCd1FELT8bPYFOoIl74Ipeqee0VpC2U UO49PWAFBRfBz9JspusF4eFHt6KZQ+adJyvM9VYcL95wSb0EycgxBui3F/M+mClnJbk9 HTmNIKDuroliImJjia2uOZhKOWoE4q86lN/gDsmPlA1DlwlCFhSH/Aw5Qik0ncH5hvWV LlESy1/W81pRtMovuvAulqT5AX/gwgT8khPNMc8viilgvEXZTbymcZ6vszbWEY2EgMBS 6qDA== X-Gm-Message-State: AA+aEWYhdTjuPlSN6PybfPWJL199SwP9a+WUzmVupjTg6oqMwHmhR/KI BK9/49HSFN28rfZN7HZ/rtAKLhjJunafbcZSYoJm7Q== X-Received: by 2002:a5d:91d7:: with SMTP id k23mr25725066ior.31.1544092314966; Thu, 06 Dec 2018 02:31:54 -0800 (PST) MIME-Version: 1.0 References: <20181129180138.GB4318@arm.com> In-Reply-To: <20181129180138.GB4318@arm.com> From: Andrey Konovalov Date: Thu, 6 Dec 2018 11:31:43 +0100 Message-ID: Subject: Re: [PATCH v12 20/25] kasan, arm64: add brk handler for inline instrumentation To: Will Deacon Cc: Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , Catalin Marinas , Christoph Lameter , Andrew Morton , Mark Rutland , Nick Desaulniers , Marc Zyngier , Dave Martin , Ard Biesheuvel , "Eric W . Biederman" , Ingo Molnar , Paul Lawrence , Geert Uytterhoeven , Arnd Bergmann , "Kirill A. Shutemov" , Greg Kroah-Hartman , Kate Stewart , Mike Rapoport , kasan-dev , "open list:DOCUMENTATION" , LKML , Linux ARM , linux-sparse@vger.kernel.org, Linux Memory Management List , Linux Kbuild mailing list , Kostya Serebryany , Evgenii Stepanov , Lee Smith , Ramana Radhakrishnan , Jacob Bramley , Ruben Ayrapetyan , Jann Horn , Mark Brand , Chintan Pandya , Vishwath Mohan Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 29, 2018 at 7:01 PM Will Deacon wrote: > > On Tue, Nov 27, 2018 at 05:55:38PM +0100, Andrey Konovalov wrote: > > Tag-based KASAN inline instrumentation mode (which embeds checks of shadow > > memory into the generated code, instead of inserting a callback) generates > > a brk instruction when a tag mismatch is detected. > > > > This commit adds a tag-based KASAN specific brk handler, that decodes the > > immediate value passed to the brk instructions (to extract information > > about the memory access that triggered the mismatch), reads the register > > values (x0 contains the guilty address) and reports the bug. > > > > Reviewed-by: Andrey Ryabinin > > Reviewed-by: Dmitry Vyukov > > Signed-off-by: Andrey Konovalov > > --- > > arch/arm64/include/asm/brk-imm.h | 2 + > > arch/arm64/kernel/traps.c | 68 +++++++++++++++++++++++++++++++- > > include/linux/kasan.h | 3 ++ > > 3 files changed, 71 insertions(+), 2 deletions(-) > > > > diff --git a/arch/arm64/include/asm/brk-imm.h b/arch/arm64/include/asm/brk-imm.h > > index ed693c5bcec0..2945fe6cd863 100644 > > --- a/arch/arm64/include/asm/brk-imm.h > > +++ b/arch/arm64/include/asm/brk-imm.h > > @@ -16,10 +16,12 @@ > > * 0x400: for dynamic BRK instruction > > * 0x401: for compile time BRK instruction > > * 0x800: kernel-mode BUG() and WARN() traps > > + * 0x9xx: tag-based KASAN trap (allowed values 0x900 - 0x9ff) > > */ > > #define FAULT_BRK_IMM 0x100 > > #define KGDB_DYN_DBG_BRK_IMM 0x400 > > #define KGDB_COMPILED_DBG_BRK_IMM 0x401 > > #define BUG_BRK_IMM 0x800 > > +#define KASAN_BRK_IMM 0x900 > > > > #endif > > diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c > > index 5f4d9acb32f5..04bdc53716ef 100644 > > --- a/arch/arm64/kernel/traps.c > > +++ b/arch/arm64/kernel/traps.c > > @@ -35,6 +35,7 @@ > > #include > > #include > > #include > > +#include > > > > #include > > #include > > @@ -284,10 +285,14 @@ void arm64_notify_die(const char *str, struct pt_regs *regs, > > } > > } > > > > -void arm64_skip_faulting_instruction(struct pt_regs *regs, unsigned long size) > > +void __arm64_skip_faulting_instruction(struct pt_regs *regs, unsigned long size) > > { > > regs->pc += size; > > +} > > > > +void arm64_skip_faulting_instruction(struct pt_regs *regs, unsigned long size) > > +{ > > + __arm64_skip_faulting_instruction(regs, size); > > /* > > * If we were single stepping, we want to get the step exception after > > * we return from the trap. > > @@ -959,7 +964,7 @@ static int bug_handler(struct pt_regs *regs, unsigned int esr) > > } > > > > /* If thread survives, skip over the BUG instruction and continue: */ > > - arm64_skip_faulting_instruction(regs, AARCH64_INSN_SIZE); > > + __arm64_skip_faulting_instruction(regs, AARCH64_INSN_SIZE); > > Why do you want to avoid the single-step logic here? Given that we're > skipping over the brk instruction, why wouldn't you want that to trigger > a step exception if single-step is enabled? I was asked to do that, see the discussion here: https://www.spinics.net/lists/linux-mm/msg146575.html https://www.spinics.net/lists/linux-mm/msg148215.html https://www.spinics.net/lists/linux-mm/msg148367.html