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=-11.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 EE80DC433E1 for ; Thu, 27 Aug 2020 13:34:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id ACC8222BF5 for ; Thu, 27 Aug 2020 13:34:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="VFTQz853" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ACC8222BF5 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 44B968E001A; Thu, 27 Aug 2020 09:34:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3D51C8E0006; Thu, 27 Aug 2020 09:34:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 29C458E001A; Thu, 27 Aug 2020 09:34:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0064.hostedemail.com [216.40.44.64]) by kanga.kvack.org (Postfix) with ESMTP id 10E0E8E0006 for ; Thu, 27 Aug 2020 09:34:56 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id BCE53824556B for ; Thu, 27 Aug 2020 13:34:55 +0000 (UTC) X-FDA: 77196444150.07.nose94_2806b882706d Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin07.hostedemail.com (Postfix) with ESMTP id 8D9FF1803F9AB for ; Thu, 27 Aug 2020 13:34:55 +0000 (UTC) X-HE-Tag: nose94_2806b882706d X-Filterd-Recvd-Size: 6807 Received: from mail-pf1-f196.google.com (mail-pf1-f196.google.com [209.85.210.196]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Thu, 27 Aug 2020 13:34:54 +0000 (UTC) Received: by mail-pf1-f196.google.com with SMTP id k15so3502401pfc.12 for ; Thu, 27 Aug 2020 06:34:54 -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=pesgnO2rhM+dQIT6yn3KZ/0S5tU65JuAnZMJt3x8NInNmuxfrOgyGb4OpAv+HXD/5h fdqyKSRXvJBYPJ1MNvSmRzQzSOpEJykfoBcKXAa19mpQRI677n7j+xoZBk9oJIukqwKl PU95IMFilcUtX3sFA03gSR6usSyA6FI8MscQY0DgGH8ObSVeuIQJHKCIcvummSq3r6Im zxcqrOvjcQNJb/PPNbQfKqlh+Zf+yn4GmoDdvM7gZpj97raUWOsvQx2BoibMlj/ZOn7N X9ufByR7qcWB+nrnk5L1cIfD+W7XBpOExg68SBQ0p44OtDVodSZCkJ3i0nZntHDQi7MN KbCA== X-Gm-Message-State: AOAM533tH2pJDatNvO3uyelXuFj9CU1sQQKfGS3OfnN5Wpclx0vhLeQz 2J3Kzz6DB/F4MxcOBP61pZDPlM817oOTMI4QQoRdUQ== 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 Cc: Vincenzo Frascino , Dmitry Vyukov , kasan-dev , Andrey Ryabinin , Alexander Potapenko , Marco Elver , Evgenii Stepanov , Elena Petrova , Branislav Rankov , Kevin Brodsky , Will Deacon , Andrew Morton , Linux ARM , Linux Memory Management List , LKML Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 8D9FF1803F9AB X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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