Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp2777520ybl; Mon, 19 Aug 2019 07:23:51 -0700 (PDT) X-Google-Smtp-Source: APXvYqwsSqJ4qEJ9/6X1CQOids9YNZRo17w0Bcbd6kigTR7fPMzBPGq3im1kgTamK93X5I0LLTjh X-Received: by 2002:a17:90a:5288:: with SMTP id w8mr21327859pjh.61.1566224631875; Mon, 19 Aug 2019 07:23:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566224631; cv=none; d=google.com; s=arc-20160816; b=g5ffoChqhNyFEhA4OZmXe6oOlSnmrAMfORrgvUA9KsIu/W2ZAoAOdhd2MKzgvu5Ng/ tiq1IPwIbXjDWjmuV3qXJMxGOMOM6XwSn1feAXnfVxa/dGFXJ5YDTHwVx7z91LIDIXm0 6E6hofmMwjs7AE9bWbQS92favBwAsWLtVQIXrqjz1pRkfhxfEJC8wiHEbq7gr7pBZCj7 s5fPjJ/7gyoRxx/aWY82grD5knwY/rOaDUJ7L72O//Kn3t9keT1xK4QXjkh7NUy2s4+r CPtNWxHujw29TIMny+EBg3+Vem0N601v2ZKIh+Rp/nWMVkA7dIdMGPxmrH2gpPWLJWua iUwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=0bNvdVFvKAFbQ1A2SSTiK4Xb9TTs9IDNzTSnasr7bh8=; b=Xcw22ZdhoJ9sGg1+//kBxbToJgYvBkJdQNNWm9VfQNgNqlhaGC0G5TQ9Gw689jYKWb f8ZhbWczPRaDblTHa4+Yc6xvr3KKLUXQgRO6CvxxRPhvWFrX7PP47ac36QDZoDM0BjcI NBsY5byLXUBXWA68DN54gXXYte+OlqHzaVe+BIjlU8Tt1WYMrl//sBSqg2roRXgoTFCo d7Ro2GaG6OQVIKuFkfe8V/kd6NshymrbvKxBM69m0ao0Ru6pJr2JHWcwPkr4kS95laPe UUL0dce4Ymu/ZX0Ka/Krt4UkQxxpQIC/cKK5HsbqVeK2pJgohkQ1gxVRrwGcJ00NJnQb MYmA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Pj+ZW3B1; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x10si10801507pfj.274.2019.08.19.07.23.36; Mon, 19 Aug 2019 07:23:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Pj+ZW3B1; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727011AbfHSOWp (ORCPT + 99 others); Mon, 19 Aug 2019 10:22:45 -0400 Received: from mail.kernel.org ([198.145.29.99]:34262 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726636AbfHSOWp (ORCPT ); Mon, 19 Aug 2019 10:22:45 -0400 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (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 EAEF820651; Mon, 19 Aug 2019 14:22:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1566224564; bh=cQXXO22L6aHmPQhctizouu0v/8jQD8BerBclLIhADhs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Pj+ZW3B1FvjYhBjkZZBmU0f1b6I51bzFAMFcoEmWoik8acU4kDoOBV4WtaSoNXFr/ viuJWq+U36J79SqIdGqkoCzb+RUy+oubwzyqse6PheLOSyyFfGgUk2vTopm22yf2I5 2nGgjhBlftpHJ3OdpLVVE12DvYw94wsuIuQUFdHY= Date: Mon, 19 Aug 2019 15:22:38 +0100 From: Will Deacon To: Andrey Konovalov Cc: Mark Rutland , Walter Wu , Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , Catalin Marinas , Will Deacon , Matthias Brugger , Andrew Morton , wsd_upstream@mediatek.com, LKML , kasan-dev , linux-mediatek@lists.infradead.org, Linux ARM Subject: Re: [PATCH] arm64: kasan: fix phys_to_virt() false positive on tag-based kasan Message-ID: <20190819142238.2jobs6vabkp2isg2@willie-the-truck> References: <20190819114420.2535-1-walter-zh.wu@mediatek.com> <20190819125625.bu3nbrldg7te5kwc@willie-the-truck> <20190819132347.GB9927@lakrids.cambridge.arm.com> <20190819133441.ejomv6cprdcz7hh6@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 19, 2019 at 04:05:22PM +0200, Andrey Konovalov wrote: > On Mon, Aug 19, 2019 at 3:34 PM Will Deacon wrote: > > > > On Mon, Aug 19, 2019 at 02:23:48PM +0100, Mark Rutland wrote: > > > On Mon, Aug 19, 2019 at 01:56:26PM +0100, Will Deacon wrote: > > > > On Mon, Aug 19, 2019 at 07:44:20PM +0800, Walter Wu wrote: > > > > > __arm_v7s_unmap() call iopte_deref() to translate pyh_to_virt address, > > > > > but it will modify pointer tag into 0xff, so there is a false positive. > > > > > > > > > > When enable tag-based kasan, phys_to_virt() function need to rewrite > > > > > its original pointer tag in order to avoid kasan report an incorrect > > > > > memory corruption. > > > > > > > > Hmm. Which tree did you see this on? We've recently queued a load of fixes > > > > in this area, but I /thought/ they were only needed after the support for > > > > 52-bit virtual addressing in the kernel. > > > > > > I'm seeing similar issues in the virtio blk code (splat below), atop of > > > the arm64 for-next/core branch. I think this is a latent issue, and > > > people are only just starting to test with KASAN_SW_TAGS. > > > > > > It looks like the virtio blk code will round-trip a SLUB-allocated pointer from > > > virt->page->virt, losing the per-object tag in the process. > > > > > > Our page_to_virt() seems to get a per-page tag, but this only makes > > > sense if you're dealing with the page allocator, rather than something > > > like SLUB which carves a page into smaller objects giving each object a > > > distinct tag. > > > > > > Any round-trip of a pointer from SLUB is going to lose the per-object > > > tag. > > > > Urgh, I wonder how this is supposed to work? > > > > If we end up having to check the KASAN shadow for *_to_virt(), then why > > do we need to store anything in the page flags at all? Andrey? > > As per 2813b9c0 ("kasan, mm, arm64: tag non slab memory allocated via > pagealloc") we should only save a non-0xff tag in page flags for non > slab pages. Thanks, that makes sense. Hopefully the patch from Andrey R will solve both of the reported splats, since I'd not realised they were both on the kfree() path. > Could you share your .config so I can reproduce this? This is in the iopgtable code, so it's probably pretty tricky to trigger at runtime unless you have the write IOMMU hardware, unfortunately. Will