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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 226FAEDE989 for ; Fri, 15 Sep 2023 03:06:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BB7758D000B; Thu, 14 Sep 2023 23:06:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B67868D0001; Thu, 14 Sep 2023 23:06:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A2ECB8D000B; Thu, 14 Sep 2023 23:06:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 5EDE68D0001 for ; Thu, 14 Sep 2023 23:06:48 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 274761A0761 for ; Fri, 15 Sep 2023 03:06:48 +0000 (UTC) X-FDA: 81237344496.04.B6A5314 Received: from mailgw01.mediatek.com (mailgw01.mediatek.com [216.200.240.184]) by imf03.hostedemail.com (Postfix) with ESMTP id 9C8AE20013 for ; Fri, 15 Sep 2023 03:06:44 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=mediatek.com header.s=dk header.b=LGetPjaM; dmarc=pass (policy=quarantine) header.from=mediatek.com; spf=pass (imf03.hostedemail.com: domain of haibo.li@mediatek.com designates 216.200.240.184 as permitted sender) smtp.mailfrom=haibo.li@mediatek.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694747205; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=RK7ek7Jr01ODZjowTcUOfcKbHQxnH1wn+srDfh3q4PM=; b=5oPe1Z66jXxiFKkgavS91aXEwsBmGXskk/UpFO2Wz7AMd6iTfcXeUYkSZ//KaCVHwVEm4w SKHlCqvoVn3G94lErwew+Bb8iEHLVRbI020mzbvZqQlbX8t4Y3G8lZns/AqHF2yOkE5q0c 5CkuP5HHQs2dnuxnAl+Oc1sy8N30vx4= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=mediatek.com header.s=dk header.b=LGetPjaM; dmarc=pass (policy=quarantine) header.from=mediatek.com; spf=pass (imf03.hostedemail.com: domain of haibo.li@mediatek.com designates 216.200.240.184 as permitted sender) smtp.mailfrom=haibo.li@mediatek.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694747205; a=rsa-sha256; cv=none; b=iWpzkk+yjPrEYKyBV9xtt+7qfg71Q2O9K5cBolpsNQZrxtOWhP3jpj5xSiUcF6LCMQGW6x NBQ5/3S1cnBTGUOPfwUyizVTvRPfJZoUm2KDWxnCrVRFrEKuMvSQMcnUMbbEgBkn+9agE/ IAhyUxPKFZMKLzCt3T7PK+5uikmbKe0= X-UUID: e1f2927c537411ee9b7791016c24628a-20230914 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Type:Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:CC:To:From; bh=RK7ek7Jr01ODZjowTcUOfcKbHQxnH1wn+srDfh3q4PM=; b=LGetPjaMUK0joxLxCjbDO9u8IWPp7eotdlQVUpeS6d7kStozRklNHH8QXwvWv6+gcKMvfal1nv/F5nAi1Z1SYdeHN4NcIgcFgNZ5yis6es304PvYb0LAYp/2qDQgtle7KnTuFgbNdAraSG+iXvlE9qe4VDm/FjCdoxw8Z8y1kwg=; X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.1.31,REQID:ad008adb-2cb6-44bd-a45a-f96cf5ae7b84,IP:0,U RL:0,TC:0,Content:0,EDM:0,RT:0,SF:0,FILE:0,BULK:0,RULE:Release_Ham,ACTION: release,TS:0 X-CID-META: VersionHash:0ad78a4,CLOUDID:0a91b8ef-9a6e-4c39-b73e-f2bc08ca3dc5,B ulkID:nil,BulkQuantity:0,Recheck:0,SF:817|102,TC:nil,Content:0|-5,EDM:-3,I P:nil,URL:0,File:nil,Bulk:nil,QS:nil,BEC:nil,COL:0,OSI:0,OSA:0,AV:0,LES:1, SPR:NO,DKR:0,DKP:0,BRR:0,BRE:0 X-CID-BVR: 1,FCT|NGT X-CID-BAS: 1,FCT|NGT,0,_ X-CID-FACTOR: TF_CID_SPAM_SNR X-UUID: e1f2927c537411ee9b7791016c24628a-20230914 Received: from mtkmbs11n1.mediatek.inc [(172.21.101.185)] by mailgw01.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256/256) with ESMTP id 1469157894; Thu, 14 Sep 2023 20:06:36 -0700 Received: from mtkmbs13n2.mediatek.inc (172.21.101.194) by MTKMBS14N1.mediatek.inc (172.21.101.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.26; Fri, 15 Sep 2023 10:46:00 +0800 Received: from mszsdtlt101.gcn.mediatek.inc (10.16.4.141) by mtkmbs13n2.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.2.1118.26 via Frontend Transport; Fri, 15 Sep 2023 10:46:00 +0800 From: Haibo Li To: CC: , , , , , , , , , , , , , , , Subject: Re: [PATCH] kasan:fix access invalid shadow address when input is illegal Date: Fri, 15 Sep 2023 10:45:59 +0800 Message-ID: <20230915024559.32806-1-haibo.li@mediatek.com> X-Mailer: git-send-email 2.34.3 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain X-TM-AS-Product-Ver: SMEX-14.0.0.3152-9.1.1006-23728.005 X-TM-AS-Result: No-10--26.184700-8.000000 X-TMASE-MatchedRID: +f/wAVSGjug4HKI/yaqRmya1MaKuob8PfjJOgArMOCaCsBeCv8CM/aaZ f1+j//eOkOti/7QqGXUh5AyXWmAqpmu2g5s6p8lPW7gz/Gbgpl6hi9MC6OBOwruqk4cq52pzvb4 +3z1qe65wj5BBW++UfCbtuknoGANVmGpYaWdk09LhqJ6oLOc8QW3eqxoVjgMEzsQ8iRVyD44DsB KNVu8yHSHQK8Uc9fmXaqMgKdVUqQ9sGQsY/Fc7u6XD9CBSVyH8WPJn4UmMuVLJYIv7y0tu9u69j M3AtKAfmapKR6Enamd1VhrfJVJ6xDfVJKfK+bRO2x93SnoxhVeeimGtNywjtslk/SMg0CpQo8WM kQWv6iVkvICuNJteaI2j49Ftap9EkGUtrowrXLg= X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--26.184700-8.000000 X-TMASE-Version: SMEX-14.0.0.3152-9.1.1006-23728.005 X-TM-SNTS-SMTP: 31D8B882395646096EE4B3E748433B78DBB106D4F0ADFA8A05354A6A0A2C39E52000:8 X-MTK: N X-Rspamd-Queue-Id: 9C8AE20013 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 3hyu4jnb88gfyxnb9us76wxykbrgiyf1 X-HE-Tag: 1694747204-194768 X-HE-Meta: U2FsdGVkX19T2B3zNjoX5Azhay4kn/yJgZWRqD1KqZ8TdDUxffXzEZlugMM4clsb5KfHyzHzB8hZIeE0UROZ3yEJoS94THt92wZOiwa6sZe3gBLxnyK5Krue9REG6nKXY66A++ez+qT7WnUFC35V58S64cJKSDbRNQUO9UwblACNVujru5pIPfTF5wKpioN1Pio3DYRylyWeXNGsHOcHFLz9cJLAaPiE1mS9PauOIJJR9v1IRPL8Ni6wBZtpZMbAZ2YShDbZgjZjr9YITgFhZ0EVsj6kKZeH/E8NOqLc62m7RaHuiiIKq4zKCD2Qee1HEXRwD3c3lzAg6x2YWUTTJeyzhxL6PonvYU0AzoiN7NTIIESsYonQeOJ6C9wgiQfz0HCrMU2l7E62cKwD9Ov23r8UefJ0KYAqfPfMABc6ZU09Kw3SaeuJp6mmUlBRlXP5oiNdXyvcB645UcAYkKFCSqAu7jaXV4i//xLauahEZ/zY+EFoVyOUp8ciPEN7jOu3sVSZcz/QYCWbJBT8/IdGKR4zfHwDfC2ZGdBqwaYW/ovMaTkqLvAS/HZtbV+WCrlTq4SdGMw++WXH/0ZYDEA/zldaqYaPcnJJbUso/O3+qxmXlJ7l/YOE8/cvsNLNoSRIZgjbEqyqT1Ohkvkcgza2xSZowvZU1fcyLjdnV+NUbGzenn2XwiCSHLgVhiKribkfZ7rtJGh/U+Mi4np675lcCyS2hEi/eU3i17Er3gGpzaluPIQ+A5OY9Bi2+qaZ4LTd3tXXWs9vW9um1Qb75inXOvlyIPV/95Sr0AvZt5YgZjLUyzh/ki9dKPc6aphlbSjT1N2358VYMC5VFP7qrfmnjyVVYCfZORJptZTJ46REhdYQiopmoOdeCPquzulEDkP9ErJZgmlyp21yRNBQFM0UwAFlavA0E25e6yFz+qth2M+hDig5tZozx6GDRCHepHlaGlUpHfDdpa+qHHjMfAE IjwQ6+zA UG0jRJTAoJnJ7LPxo9UqoS1q27MnbFO1BemBzDanpSDTFYIFhdj7UOOPaTYaqyMVMbXbXlugihpEOpip8xN5LYk4UlhGGbOATKWeS+ahwe5M7SU9COo5MG4LEZDgWDP1PbyezUgdqFcnlphRtkXnBJCB/TQu0OcuxhYtZZBcCpa3mR65VeJvofPC/ZB6MJeZvavjAvwkMggBW9DypVUBXnL4Q8JC7K1HGlOftnp92fBPWRvsETRBVVMFcuLuvLOIJYzmR0KmDkD53CrffMy6ctqVFrQ== 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, Sep 14, 2023 at 10:41=E2=80=AFPM Jann Horn wro= te:=0D > >=0D > > > Accessing unmapped memory with KASAN always led to a crash when=0D > > > checking shadow memory. This was reported/discussed before. To improv= e=0D > > > crash reporting for this case, Jann added kasan_non_canonical_hook an= d=0D > > > Mark integrated it into arm64. But AFAIU, for some reason, it stopped= =0D > > > working.=0D > > >=0D > > > Instead of this patch, we need to figure out why=0D > > > kasan_non_canonical_hook stopped working and fix it.=0D > > >=0D > > > This approach taken by this patch won't work for shadow checks added= =0D > > > by compiler instrumentation. It only covers explicitly checked=0D > > > accesses, such as via memcpy, etc.=0D > >=0D > > FWIW, AFAICS kasan_non_canonical_hook() currently only does anything=0D > > under CONFIG_KASAN_INLINE;=0D > =0D > Ah, right. I was thinking about the inline mode, but the patch refers=0D > to the issue with the outline mode.=0D > =0D > However, I just checked kasan_non_canonical_hook for SW_TAGS with the=0D > inline mode: it does not work when accessing 0x42ffffb80aaaaaaa, the=0D > addr < KASAN_SHADOW_OFFSET check fails. It appears there's something=0D > unusual about how instrumentation calculates the shadow address. I=0D > didn't investigate further yet.=0D > =0D > > I think the idea when I added that was that=0D > > it assumes that when KASAN checks an access in out-of-line=0D > > instrumentation or a slowpath, it will do the required checks to avoid= =0D > > this kind of fault?=0D > =0D > Ah, no, KASAN doesn't do it.=0D > =0D > However, I suppose we could add what the original patch proposes for=0D > the outline mode. For the inline mode, it seems to be pointless, as=0D > most access checks happen though the compiler inserted code anyway.=0D > =0D > I also wonder how much slowdown this patch will introduce.=0D > =0D > Haibo, could you check how much slower the kernel becomes with your=0D > patch? If possible, with all GENERIC/SW_TAGS and INLINE/OUTLINE=0D > combinations.=0D > =0D > If the slowdown is large, we can just make kasan_non_canonical_hook=0D > work for both modes (and fix it for SW_TAGS).=0D =0D Thanks.=0D The patch checks each shadow address,so it introduces extra overhead.=0D Now kasan_non_canonical_hook only works for CONFIG_KASAN_INLINE.=0D And CONFIG_KASAN_OUTLINE is set in my case.=0D Is it possible to make kasan_non_canonical_hook works for both =0D INLINE and OUTLINE by simply remove the "#ifdef CONFIG_KASAN_INLINE"?=0D Since kasan_non_canonical_hook is only used after kernel fault,it =0D is better if there is no limit.=0D =0D