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=-7.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 B893CC433E1 for ; Thu, 27 Aug 2020 12:33:37 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 82A1B2177B for ; Thu, 27 Aug 2020 12:33:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="tzjyNSQx"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="I1epf77j" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 82A1B2177B Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=nQm96kMjpLGkA92G8LBfCM55vCBX6lQgvLjWcXfEWU8=; b=tzjyNSQxQ7XvVJ9uJ7l4CMzkI VjJExeIE31LQRYrC0UAfwcepLn0/E9ljPfDaDIfs5HpM0jSAcJUYAw3dwvAJgVV+orvtQppzU0eJb PlREJAeOYgfEAIV6sA3uYAnwOCtmqix1xgBycdTtT5LS/iH2GgAdHMxxREcIw8IDeeNGhwTTCqf9P /dELYkwjL5P85rrqq6bo8eQP7+kbkaIXuDWFBpmgr/4YpHRBtzyt6SSrfLNaP9iH+Gj8sCpPBZ85H +zjcrLSnDI61gPq0UQXHm0KHDhrQCtZupGy10DR4HhLMBkGcFZSMKP9RYPvCqhi6Ls77yZF2Q0TOz o2AE68YYw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kBH4D-0005TR-2z; Thu, 27 Aug 2020 12:31:45 +0000 Received: from mail-pj1-x1041.google.com ([2607:f8b0:4864:20::1041]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kBH4A-0005SP-PJ for linux-arm-kernel@lists.infradead.org; Thu, 27 Aug 2020 12:31:43 +0000 Received: by mail-pj1-x1041.google.com with SMTP id kx11so2507619pjb.5 for ; Thu, 27 Aug 2020 05:31:36 -0700 (PDT) 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=yQ34VdsT1gZZpD4I8FVa5CTJn00Te78jNd2pA6lLPkY=; b=I1epf77jfolvXZ3lxPPerNV6b8ZR+vAs1jMXJRljeHO4smH2mv2d/HofqXH/7th22j RAuCv5zawN4S0NQp1oMcbV7rprwSgI9inHZv6mH5ztgY0JijkSvpAwvgvIgUuNEz/J7m +h5oynsBLzazcuzTgTdIrP0CLSswcNzISkJ2Dhg+naUoEP7PfnG3dEnEqXF3lwxRjH/k 1HkGx3MrXz0pMyMcOldMH88mE1GlygmVmHBRAC5UtpsHzusbufe4vrn2WbIPqpjnehrD GN4t7ktbeaWZUrIDi3yQuWHZXqVtYYvF6aUj+le8gk/4mQwukcfGQBu0f87Vf1dKd1rh Iiog== 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=yQ34VdsT1gZZpD4I8FVa5CTJn00Te78jNd2pA6lLPkY=; b=NOlhKhfZ/xOG1RIV1iCgXtvsz+ppfRF3dMLQqpxfyyunqtY5Sm1hBRXI8YqXXmiLL9 wA2IgQCS3PT3A7p3ydSF1rDz+oOVxCPzdk0Pzt5rZW1wELzGoiq8/7AraKX02m2/S6+h fQxCwbX0B77FDWgK2bWIMukdTfluHkvb6O4p9bCXtD7yQAr3x81teMoeiGx364E6mWIo i3uHtD6iC54Om6vxDJXWDaXoPP0p+04Sf6PIN7G7TNBsPb/R3WHkjOnIjAJl9fwr1zF2 lWbqaVfKcPnuN0Y4GYLRKP6XRcWIOI+2zbO+Z0ZV/fT2n1e13/YCcAvsGrSCxoCV4EYk tyOg== X-Gm-Message-State: AOAM533IZjrNq1xOg9Q0ELCQA9MeezKNv3b5SZSdRHl0izF2unje306s ahtZiOgtdiUNa4QdKap1VF4dF6gH+DUe38ZZ8Cgirw== X-Google-Smtp-Source: ABdhPJwxzIdT6r9g81onp4MRqvYw7f8GGSwFXswQ6f0+r9QV6hN6QDWWv4HYAZfzDIlvMnb+t7jPZJne+TEwcPQdEZ8= X-Received: by 2002:a17:90a:a791:: with SMTP id f17mr10252307pjq.136.1598531494572; Thu, 27 Aug 2020 05:31:34 -0700 (PDT) MIME-Version: 1.0 References: <20200827095429.GC29264@gaia> In-Reply-To: <20200827095429.GC29264@gaia> From: Andrey Konovalov Date: Thu, 27 Aug 2020 14:31:23 +0200 Message-ID: Subject: Re: [PATCH 21/35] arm64: mte: Add in-kernel tag fault handler To: Catalin Marinas , Vincenzo Frascino X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200827_083142_855713_7276289F X-CRM114-Status: GOOD ( 31.48 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Linux ARM , Marco Elver , Elena Petrova , Kevin Brodsky , Will Deacon , Branislav Rankov , kasan-dev , LKML , Linux Memory Management List , Alexander Potapenko , Dmitry Vyukov , Andrey Ryabinin , Andrew Morton , Evgenii Stepanov Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Aug 27, 2020 at 11:54 AM Catalin Marinas wrote: > > On Fri, Aug 14, 2020 at 07:27:03PM +0200, Andrey Konovalov wrote: > > diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c > > index 5e832b3387f1..c62c8ba85c0e 100644 > > --- a/arch/arm64/mm/fault.c > > +++ b/arch/arm64/mm/fault.c > > @@ -33,6 +33,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > #include > > @@ -222,6 +223,20 @@ int ptep_set_access_flags(struct vm_area_struct *vma, > > return 1; > > } > > > > +static bool is_el1_mte_sync_tag_check_fault(unsigned int esr) > > +{ > > + unsigned int ec = ESR_ELx_EC(esr); > > + unsigned int fsc = esr & ESR_ELx_FSC; > > + > > + if (ec != ESR_ELx_EC_DABT_CUR) > > + return false; > > + > > + if (fsc == ESR_ELx_FSC_MTE) > > + return true; > > + > > + return false; > > +} > > + > > static bool is_el1_instruction_abort(unsigned int esr) > > { > > return ESR_ELx_EC(esr) == ESR_ELx_EC_IABT_CUR; > > @@ -294,6 +309,18 @@ static void die_kernel_fault(const char *msg, unsigned long addr, > > do_exit(SIGKILL); > > } > > > > +static void report_tag_fault(unsigned long addr, unsigned int esr, > > + struct pt_regs *regs) > > +{ > > + bool is_write = ((esr & ESR_ELx_WNR) >> ESR_ELx_WNR_SHIFT) != 0; > > + > > + pr_alert("Memory Tagging Extension Fault in %pS\n", (void *)regs->pc); > > + pr_alert(" %s at address %lx\n", is_write ? "Write" : "Read", addr); > > + pr_alert(" Pointer tag: [%02x], memory tag: [%02x]\n", > > + mte_get_ptr_tag(addr), > > + mte_get_mem_tag((void *)addr)); > > +} > > + > > static void __do_kernel_fault(unsigned long addr, unsigned int esr, > > struct pt_regs *regs) > > { > > @@ -317,12 +344,16 @@ static void __do_kernel_fault(unsigned long addr, unsigned int esr, > > msg = "execute from non-executable memory"; > > else > > msg = "read from unreadable memory"; > > + } else if (is_el1_mte_sync_tag_check_fault(esr)) { > > + report_tag_fault(addr, esr, regs); > > + msg = "memory tagging extension fault"; > > IIUC, that's dead code. See my comment below on do_tag_check_fault(). > > > } else if (addr < PAGE_SIZE) { > > msg = "NULL pointer dereference"; > > } else { > > msg = "paging request"; > > } > > > > + > > Unnecessary empty line. > > > die_kernel_fault(msg, addr, esr, regs); > > } > > > > @@ -658,10 +689,27 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs) > > return 0; > > } > > > > +static int do_tag_recovery(unsigned long addr, unsigned int esr, > > + struct pt_regs *regs) > > +{ > > + report_tag_fault(addr, esr, regs); > > + > > + /* Skip over the faulting instruction and continue: */ > > + arm64_skip_faulting_instruction(regs, AARCH64_INSN_SIZE); > > Ooooh, do we expect the kernel to still behave correctly after this? I > thought the recovery means disabling tag checking altogether and > restarting the instruction rather than skipping over it. The intention is to be able to catch multiple MTE faults without panicking or disabling MTE when executing KASAN tests (those do multiple bad accesses one after another). We do arm64_skip_faulting_instruction() for software tag-based KASAN too, it's not ideal, but works for testing purposes. Can we disable MTE, reexecute the instruction, and then reenable MTE, or something like that? When running in-kernel MTE in production, we'll either panic or disable MTE after the first fault. This was controlled by the panic_on_mte_fault option Vincenzo initially had. > We only skip if we emulated it. I'm not sure I understand this part, what do you mean by emulating? > > > + > > + return 0; > > +} > > + > > + > > static int do_tag_check_fault(unsigned long addr, unsigned int esr, > > struct pt_regs *regs) > > { > > - do_bad_area(addr, esr, regs); > > + /* The tag check fault (TCF) is per TTBR */ > > + if (is_ttbr0_addr(addr)) > > + do_bad_area(addr, esr, regs); > > + else > > + do_tag_recovery(addr, esr, regs); > > So we never invoke __do_kernel_fault() for a synchronous tag check in > the kernel. What's with all the is_el1_mte_sync_tag_check_fault() check > above? > > -- > Catalin > > -- > You received this message because you are subscribed to the Google Groups "kasan-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20200827095429.GC29264%40gaia. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel