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=-4.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, 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 1A54DC433DF for ; Thu, 27 Aug 2020 13:36:25 +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 B5BB3207CD for ; Thu, 27 Aug 2020 13:36:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="wLEt9l6E"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="VFTQz853" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B5BB3207CD 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=9XbHCxczBwbG7uDmp05VfjvQmTtMNwb9UncWhHwyQQQ=; b=wLEt9l6EpmhhJwr/0RxCzIiq4 ziRqA+haKj9c5LyW4NpmnsdfdJGJw6bekY2gqfJLNHNa8HPMXLzTyn06mf577fNELPMdj9lXNDJ34 Pq2WwjubFcIsB/KJpWKJF3GkU4OyzN4X7XQ7Ix4GvINoRlQam3XkFihKIyC4VFqZ9QXUuvWEp0Fqs z/YfwScOTtuLxj9cz0llwY5susDzg7s3W6N3O0RByioiK960SJDoDlshzuhnbNpxQwpJypWpeboC8 ezRBLIZsNyvT4TOMDAX7akG0oRCYX4GCJGQlRka2AtoxF8PmCb2dyASPCgMZTQXRcVkpu6RzMyFVC TCrfC+EnA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kBI3P-00042e-TB; Thu, 27 Aug 2020 13:34:59 +0000 Received: from mail-pf1-x443.google.com ([2607:f8b0:4864:20::443]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kBI3N-00041P-88 for linux-arm-kernel@lists.infradead.org; Thu, 27 Aug 2020 13:34:58 +0000 Received: by mail-pf1-x443.google.com with SMTP id x143so3519789pfc.4 for ; Thu, 27 Aug 2020 06:34:55 -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=fOtOQwtAMnsiuZkel6P+QKLSzAWGFcwbvl4MhWbUo1c=; b=VFTQz853WO4K2b97Gw8Vq+2NCsRZgwv1PoyWPiyF79O4L1GRoHXehFI0hrHO5E+3L7 nrLw54vjbmJAxJfu7iwZojsuLgK1EkXhuuF5hJg/zw7PF1ifJG/xBnl50S06cC19W/gq i8v8c7i9DpklX0WWeUhuKJ027ioHReA6qzTwjXZQmmsBYH86hl6lvvvHIdQI5xUCw35n djVrMOcEzNUHZDX9Q0JRJ+54DxyZ3qczuN01T1vEaxVf6TNlY1JzVpxVurEPofRICLTQ sehOfUQssBoXDLpPl5PGDtsh+7wUv7SMNBwZa5CtaOi0/dpNOGbR+wxV8VZ0akl3pAEH TFSg== 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=fOtOQwtAMnsiuZkel6P+QKLSzAWGFcwbvl4MhWbUo1c=; b=feDiehvcJ4FsTP2uEscEYmR3j8chQfSvyPlRzRh8J6n/QQ9ifrPgJQtPsXU7MHQY2a Y8A7CtcA1UoSMD33a1fK3IlHBwMkMz4Mn+rlVunDqVAvHu21OjrkyZFZO/WKwFdtjkEd h0FYZPFO4y7SNHSK3sHNh3+3UjB6+uNosoVw4QGWG4VdoBz0HLZ6YAEBLeen8HRN2KG0 ImQ0m9YoorLeojoW7AX9Uu8SLYLzZRcMSJe4pVImwWW9loZNhknROwzx+VMfu3SF4T1h 6mMplkv5s4m+8X4Us0XZJzhn9dsDuTztlm3TK7hoS35Xo8X8PEUvGy6MgV4c3ATv3ETs m6bA== X-Gm-Message-State: AOAM531YJBcfx57Y8PQoe6/lM9IzELDvuUNnkdFbntA2gvw6ScAPml+1 i+DT0VYHqknd9iALJITcBJFr9e5QWms7oWBfj3ohXA== X-Google-Smtp-Source: ABdhPJwZDZ1YWgPOElrp9s/sDw0FY/M9AwCUa4WE07eW6R7ae8uB2U5pgCBMXEphtljLWo5s8MA4P1VEg3eAT76xSLQ= X-Received: by 2002:a17:902:b589:: with SMTP id a9mr15940749pls.98.1598535293587; Thu, 27 Aug 2020 06:34:53 -0700 (PDT) MIME-Version: 1.0 References: <20200827095429.GC29264@gaia> <20200827131045.GM29264@gaia> In-Reply-To: <20200827131045.GM29264@gaia> From: Andrey Konovalov Date: Thu, 27 Aug 2020 15:34:42 +0200 Message-ID: Subject: Re: [PATCH 21/35] arm64: mte: Add in-kernel tag fault handler To: Catalin Marinas X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200827_093457_328109_1526BD49 X-CRM114-Status: GOOD ( 31.17 ) 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 3:10 PM Catalin Marinas wrote: > > 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. Yes, you're right. > > 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. Oh, yes, indeed. For some reason I confused myself thinking that we also skip the access for software KASAN. > Has the actual memory access taken place when it > hits the brk? IIRC, no, but it will be executed right after we skip 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. Which one of these would be simpler to implement? Perhaps we could somehow only skip faulting instructions that happen in the KASAN test module?.. Decoding stack trace would be an option, but that's a bit weird. Overall, this feature is not essential, but will make testing simpler. > > 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. OK, we can do this. > > > 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