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=-0.7 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,UNPARSEABLE_RELAY,URIBL_BLOCKED autolearn=unavailable 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 94DD8C31E45 for ; Fri, 14 Jun 2019 02:32:30 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 46D07205ED for ; Fri, 14 Jun 2019 02:32:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ZPl6aAnV" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 46D07205ED Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-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=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=88KmhaS8qjnll92r9siHf3T9ZkRhAJHWungESQ4PT2I=; b=ZPl6aAnVK1YLfd exT9P0wBg1rg5Q1m01/WEr4spfSzk66ZVqKUFOvbEt40PbvT+VpoUdzwe/eRWDXfvivTZhBz1uhxq i8pNoECo7uJP8MLefyK7ThYteBtKZbJd5RpQ26TACoExTgUsItgsmGZMndClQHJ0D6KqkzAg2G9Jt MT7Ll5udMmSnVCMnapv5aiUE6zUQEMZi6aYhGgZf/Q2O9T3ElKwKABlhqsBosUfc9223EZZ+h453b EnGzMj1+hKJPLPYLFomeeEkeB/xrZZCTsnVuU6Cr8w4y4HqkwfM2W/EZf8lNCGZr5h0qcmMIqJJnH sGuNhjNw9E397oMcQASw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hbc0t-0002Rb-0S; Fri, 14 Jun 2019 02:32:23 +0000 Received: from mailgw01.mediatek.com ([216.200.240.184]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hbc0p-0002DC-4d; Fri, 14 Jun 2019 02:32:20 +0000 X-UUID: 19c69bc2b55a43ba855ba6e14fe55af1-20190613 X-UUID: 19c69bc2b55a43ba855ba6e14fe55af1-20190613 Received: from mtkcas68.mediatek.inc [(172.29.94.19)] by mailgw01.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLS) with ESMTP id 505435386; Thu, 13 Jun 2019 18:32:09 -0800 Received: from mtkmbs08n2.mediatek.inc (172.21.101.56) by MTKMBS62DR.mediatek.inc (172.29.94.18) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 13 Jun 2019 19:32:08 -0700 Received: from mtkcas07.mediatek.inc (172.21.101.84) by mtkmbs08n2.mediatek.inc (172.21.101.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 14 Jun 2019 10:32:00 +0800 Received: from [172.21.84.99] (172.21.84.99) by mtkcas07.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Fri, 14 Jun 2019 10:32:00 +0800 Message-ID: <1560479520.15814.34.camel@mtksdccf07> Subject: Re: [PATCH v3] kasan: add memory corruption identification for software tag-based mode From: Walter Wu To: Andrey Ryabinin Date: Fri, 14 Jun 2019 10:32:00 +0800 In-Reply-To: <1560447999.15814.15.camel@mtksdccf07> References: <20190613081357.1360-1-walter-zh.wu@mediatek.com> <1560447999.15814.15.camel@mtksdccf07> X-Mailer: Evolution 3.2.3-0ubuntu6 MIME-Version: 1.0 X-TM-SNTS-SMTP: C34F4A9FF25B720FA8D264905C1A23CE1B1F2B5A1E4DE450A529D5CDAA5FBF8F2000:8 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190613_193219_189773_CED56027 X-CRM114-Status: GOOD ( 20.56 ) 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: wsd_upstream@mediatek.com, "Jason A . Donenfeld" , Vasily Gorbik , Arnd Bergmann , linux-mm@kvack.org, Andrey Konovalov , linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, Pekka Enberg , Martin Schwidefsky , Miles Chen , Alexander Potapenko , linux-arm-kernel@lists.infradead.org, David Rientjes , Matthias Brugger , linux-mediatek@lists.infradead.org, Christoph Lameter , Joonsoo Kim , Dmitry Vyukov Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, 2019-06-14 at 01:46 +0800, Walter Wu wrote: > On Thu, 2019-06-13 at 15:27 +0300, Andrey Ryabinin wrote: > > > > On 6/13/19 11:13 AM, Walter Wu wrote: > > > This patch adds memory corruption identification at bug report for > > > software tag-based mode, the report show whether it is "use-after-free" > > > or "out-of-bound" error instead of "invalid-access" error.This will make > > > it easier for programmers to see the memory corruption problem. > > > > > > Now we extend the quarantine to support both generic and tag-based kasan. > > > For tag-based kasan, the quarantine stores only freed object information > > > to check if an object is freed recently. When tag-based kasan reports an > > > error, we can check if the tagged addr is in the quarantine and make a > > > good guess if the object is more like "use-after-free" or "out-of-bound". > > > > > > > > > We already have all the information and don't need the quarantine to make such guess. > > Basically if shadow of the first byte of object has the same tag as tag in pointer than it's out-of-bounds, > > otherwise it's use-after-free. > > > > In pseudo-code it's something like this: > > > > u8 object_tag = *(u8 *)kasan_mem_to_shadow(nearest_object(cacche, page, access_addr)); > > > > if (access_addr_tag == object_tag && object_tag != KASAN_TAG_INVALID) > > // out-of-bounds > > else > > // use-after-free > > Thanks your explanation. > I see, we can use it to decide corruption type. > But some use-after-free issues, it may not have accurate free-backtrace. > Unfortunately in that situation, free-backtrace is the most important. > please see below example > > In generic KASAN, it gets accurate free-backrace(ptr1). > In tag-based KASAN, it gets wrong free-backtrace(ptr2). It will make > programmer misjudge, so they may not believe tag-based KASAN. > So We provide this patch, we hope tag-based KASAN bug report is the same > accurate with generic KASAN. > > --- > ptr1 = kmalloc(size, GFP_KERNEL); > ptr1_free(ptr1); > > ptr2 = kmalloc(size, GFP_KERNEL); > ptr2_free(ptr2); > > ptr1[size] = 'x'; //corruption here > > > static noinline void ptr1_free(char* ptr) > { > kfree(ptr); > } > static noinline void ptr2_free(char* ptr) > { > kfree(ptr); > } > --- > We think of another question about deciding by that shadow of the first byte. In tag-based KASAN, it is immediately released after calling kfree(), so the slub is easy to be used by another pointer, then it will change shadow memory to the tag of new pointer, it will not be the KASAN_TAG_INVALID, so there are many false negative cases, especially in small size allocation. Our patch is to solve those problems. so please consider it, thanks. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel