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,URIBL_BLOCKED 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 EF9FEC433DF for ; Thu, 27 Aug 2020 19:16:05 +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 B9FA1207CD for ; Thu, 27 Aug 2020 19:16:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="u8xfb6hQ"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="CzK5MevC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B9FA1207CD 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=oKit98X+MzVcEfdXKGsHEWV8XcwgXy/iKbE8RUpLzfs=; b=u8xfb6hQOW/AXMG3hMA7xi2GZ OwLHE+W0PngW17AW13QbN54hKHF3l7oiDLS5D+Yc7p2+s4t4trBwIWFN4sW63lBX3dUdzMLh4aQAc jMz94LeEQNBbfNyK6AiTIdOiiI/kLwv4ZTQa0sRl2pyGClEg1btV11Vw/WrBL5WCreBDzkvle3uTY IQ8JoyFSBqmkBR69uGjL24zJzffaefyR4iUMUIxnNXZs/zJK4pMciQd1x3urYiduNDrC418gsDKqe 1HvVhaIi8VQhpkKJkdaBliKY/9e2w4dI8n+WbtbMXCYL7Yt/w5UlSM5kF72q6abJdG00XhUf50KRg lnReEO9Dw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kBNMF-00052z-25; Thu, 27 Aug 2020 19:14:47 +0000 Received: from mail-yb1-xb44.google.com ([2607:f8b0:4864:20::b44]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kBNMB-00051h-Tb for linux-arm-kernel@lists.infradead.org; Thu, 27 Aug 2020 19:14:44 +0000 Received: by mail-yb1-xb44.google.com with SMTP id y134so3572209yby.2 for ; Thu, 27 Aug 2020 12:14:40 -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=8EbCOeZ1KrDUva8Qo9ruBWoAtdzcTodwXUPT6QjLJgQ=; b=CzK5MevCoTJjSYEKsR6BXPClIs48eH9pjn6p7fKUCBn5JS6ZcYj7+wuJVw63jDYkJm zWBhJ/lu6AJgQP7W+lQVNnVjfA1GhaNAwSoc/7j4N4ysvalHprcpTMCgTFCsERwCEK3J ZlUkGW7sKCTG7SMpWyt6WwFMcHSZIDUuxWzSSVTJ29v8jeP2+3X070RVHhD2opTeQPIu 5hqe5nAc2dApnbSaGk9LbKUyUgf6e6bDL5xmrdM7Hc0WVjjAQOXFc9/rV2MZYCdAan9+ 0wHMAE7RqUcmSgEQezkLSqEt+nozFbyVnJi0BzlX1QdVJrL37eqS7KWadSAmRYvSk+U/ ZaEg== 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=8EbCOeZ1KrDUva8Qo9ruBWoAtdzcTodwXUPT6QjLJgQ=; b=NorZ0+XGxSZK3+hiGmzkLilq1uuQb9n/zTJs+slRN09dbfNtv35FSyQ8fY6wXVhjfj 4CqywvkciCdZQFLLvPjt5pnZf5LvVR4ddx+JZkFm1kq+rIMZ5JxVPdn4mxSZUCVUFoDz 6e2Ut0Zv0rcQQSeFfEgRcHtLpxo1tcPfjmNBb7LZl1LOtvX4eeQgDqg9Bw3oroFZzhOc OKKVM/wrWRp+R1MTPoMrBDmbJ/VwAyudDrZ2OThHKAsEh7t6AsdyWESC6sbPGJm+30Xj 1KKMBXK6pv4wo9iFGFBdH640msR478qVc/WBv0yUZ8BGnBNYh09PRexz8A71Ri4N1AVO p4Iw== X-Gm-Message-State: AOAM532SF1VLVdR+AOdqilDP93SYU8Bque9vt3Y5N/2F2/QSggZqhPYs 51DxF7nOzne+VMtfQS6HnwIlosSAeeKfwiDy/fnPag== X-Google-Smtp-Source: ABdhPJxkQYG/edhUcGiwy3weZ87oxUfXXeGP9hZPA0qzfNe8+TonDNIFV26AsiWzge2Pm7kQqIj8Thn+X/uM5A/BanI= X-Received: by 2002:a5b:744:: with SMTP id s4mr32088872ybq.26.1598555678461; Thu, 27 Aug 2020 12:14:38 -0700 (PDT) MIME-Version: 1.0 References: <20200827095429.GC29264@gaia> <20200827131045.GM29264@gaia> <20200827145642.GO29264@gaia> In-Reply-To: <20200827145642.GO29264@gaia> From: Evgenii Stepanov Date: Thu, 27 Aug 2020 12:14:26 -0700 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_151443_969075_F5895C82 X-CRM114-Status: GOOD ( 27.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: Marco Elver , Elena Petrova , Andrey Konovalov , Kevin Brodsky , Will Deacon , Branislav Rankov , kasan-dev , LKML , Linux Memory Management List , Alexander Potapenko , Linux ARM , 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 7:56 AM Catalin Marinas wrote: > > On Thu, Aug 27, 2020 at 03:34:42PM +0200, Andrey Konovalov wrote: > > 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. > [...] > > > > 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? > > Either 2 or 3 would be simpler (re-tag the memory location or the > pointer) with the caveats I mentioned. Also, does the slab allocator > need to touch the memory on free with a tagged pointer? Otherwise slab > may hit an MTE fault itself. Changing the memory tag can cause faults in other threads, and that could be very confusing. Probably the safest thing is to retag the register, single step and then retag it back, but be careful with the instructions that change the address register (like ldr x0, [x0]). > > > 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. > > If you want to restrict this to the KASAN tests, just add some > MTE-specific accessors with a fixup entry similar to get_user/put_user. > __do_kernel_fault() (if actually called) will invoke the fixup code > which skips the access and returns an error. This way KASAN tests can > actually verify that tag checking works, I'd find this a lot more > useful. > > -- > Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel