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=-6.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 0BA25C433E1 for ; Thu, 27 Aug 2020 13:12:13 +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 CA4A5206F0 for ; Thu, 27 Aug 2020 13:12:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="KOioY8hV" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CA4A5206F0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.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:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=oh0yHkRhPT32q1w8eW24jm2NtfBNI3oMSBngSlhhBJM=; b=KOioY8hVXbFDCCPpSh6tMVyjw QQGtxZHUJFBb0wF3CNPgaw+B5reAU2CyJU26SnJ2kaZgg+vwox6DY30mnG9BqjpdlAIvD+Nte42/4 pWDQH3cp+fG79E3fj3zSbot5nCXtLF/JH9gcSNzM18YU0k1evDLIVZE5wp02xIOW8cWKlTfWN5VlZ /el4zgCtMcYQ+78okWMoVKd4lIl0XwuAr2aTeCanBMJ1oDhV2uGJi2HiMXEKLEl2xwH+uSpsN6WTt yvgbXOn22N25becQABBzCJi5Hrh+xIshQfnp8jYItM7zCRIxe1fupONlH8Bq1C3G5r4Un+Q1BhFuc 0j1f5JqoA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kBHg6-0002EO-6d; Thu, 27 Aug 2020 13:10:54 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kBHg3-0002Dc-A4 for linux-arm-kernel@lists.infradead.org; Thu, 27 Aug 2020 13:10:52 +0000 Received: from gaia (unknown [46.69.195.127]) (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 10065206F0; Thu, 27 Aug 2020 13:10:47 +0000 (UTC) Date: Thu, 27 Aug 2020 14:10:45 +0100 From: Catalin Marinas To: Andrey Konovalov Subject: Re: [PATCH 21/35] arm64: mte: Add in-kernel tag fault handler Message-ID: <20200827131045.GM29264@gaia> References: <20200827095429.GC29264@gaia> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200827_091051_481430_01FEDC4B X-CRM114-Status: GOOD ( 24.98 ) 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 , Evgenii Stepanov , Andrey Ryabinin , Andrew Morton , Vincenzo Frascino , Dmitry Vyukov 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 02:31:23PM +0200, Andrey Konovalov wrote: > 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: > > > +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). The problem is that for MTE synchronous tag check faults, the access has not happened, so you basically introduce memory corruption by skipping the access. > We do arm64_skip_faulting_instruction() for software tag-based KASAN > too, it's not ideal, but works for testing purposes. IIUC, KASAN only skips over the brk instruction which doesn't have any other side-effects. Has the actual memory access taken place when it hits the brk? > Can we disable MTE, reexecute the instruction, and then reenable MTE, > or something like that? If you want to preserve the MTE enabled, you could single-step the instruction or execute it out of line, though it's a bit more convoluted (we have a similar mechanism for kprobes/uprobes). Another option would be to attempt to set the matching tag in memory, under the assumption that it is writable (if it's not, maybe it's fine to panic). Not sure how this interacts with the slub allocator since, presumably, the logical tag in the pointer is wrong rather than the allocation one. Yet another option would be to change the tag in the register and re-execute but this may confuse the compiler. > 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. I prefer to disable MTE, print something and continue, but no panic. > > We only skip if we emulated it. > > I'm not sure I understand this part, what do you mean by emulating? Executing it out of line or other form of instruction emulation (see arch/arm64/kernel/probes/simulate-insn.c) so that the access actually takes place. But you can single-step or experiment with some of the other tricks above. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel