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 BFF1EEE644D for ; Fri, 15 Sep 2023 09:40:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 57BFF6B032A; Fri, 15 Sep 2023 05:40:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 52BCC6B032C; Fri, 15 Sep 2023 05:40:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 41AC56B032D; Fri, 15 Sep 2023 05:40:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 326846B032A for ; Fri, 15 Sep 2023 05:40:53 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 06FBAA0FFE for ; Fri, 15 Sep 2023 09:40:53 +0000 (UTC) X-FDA: 81238337586.29.AD91D04 Received: from mailgw01.mediatek.com (mailgw01.mediatek.com [216.200.240.184]) by imf05.hostedemail.com (Postfix) with ESMTP id EE88F100009 for ; Fri, 15 Sep 2023 09:40:48 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=mediatek.com header.s=dk header.b=MM3euV1t; dmarc=pass (policy=quarantine) header.from=mediatek.com; spf=pass (imf05.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=1694770850; 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=1OuoRlRhal85zHHNkvOTaN3Ke5AHVAChxHwJa2fHozc=; b=OH/Z/lm+GiPTXSOW/hWnQAmd+0afMIBexnHnhvcxq5xLoyCt6mBIHgdbfaNmGBlXkR/Sh9 zPIGWLqx5cP7iX2w2Z0Gj5SbnHsIoH71pwqlGHrLaqelc+vHuHynYTUIeXa5pyLj0fXaLK gSZZ1vwiIddtk3FpdyBWm5qUgLh5JFI= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=mediatek.com header.s=dk header.b=MM3euV1t; dmarc=pass (policy=quarantine) header.from=mediatek.com; spf=pass (imf05.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=1694770850; a=rsa-sha256; cv=none; b=npA9RiGm2f0fnwfORCu+NlXiLEebGQwXQgSR3ZVGMIiZO3Hw0dwq1vpUYOq71yeP9mRITx qHHWMtuuGINULUXNNVfa4MTuDOYfoA0uZST6d2+/5ZFPoFqE1nPfewp+6aNcIuPVZcmFyz AzNmL1cBouvAjJ9mrthQsXVlinOanmE= X-UUID: efa5b43a53ab11ee9b7791016c24628a-20230915 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=1OuoRlRhal85zHHNkvOTaN3Ke5AHVAChxHwJa2fHozc=; b=MM3euV1tUKPXUIldHSEbYRgltH5vlWwr9PKwDcZsZ93Y58hIBDgqc8rENDFbkwXO+ceBSA77MybzU3AMAim1adN077HVNbgjNPIh8lQ605HiFQH5brtv68RiPv6ae75O4HIXXjIXvDfVSNnfzoBqMfzOhdzOiTL4mDx0JETFaNE=; X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.1.31,REQID:8094830c-3d9b-49b5-b2d3-c6b0dcfc3a0b,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:697511c3-1e57-4345-9d31-31ad9818b39f,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: efa5b43a53ab11ee9b7791016c24628a-20230915 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 1576458382; Fri, 15 Sep 2023 02:40:42 -0700 Received: from mtkmbs13n1.mediatek.inc (172.21.101.193) by mtkmbs13n2.mediatek.inc (172.21.101.108) 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 17:40:04 +0800 Received: from mszsdtlt101.gcn.mediatek.inc (10.16.4.141) by mtkmbs13n1.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.2.1118.26 via Frontend Transport; Fri, 15 Sep 2023 17:40:04 +0800 From: Haibo Li To: CC: , , , , , , , , , , , , , , , Subject: Re: [PATCH] kasan:fix access invalid shadow address when input is illegal Date: Fri, 15 Sep 2023 17:40:04 +0800 Message-ID: <20230915094004.113104-1-haibo.li@mediatek.com> X-Mailer: git-send-email 2.34.3 In-Reply-To: <20230915024559.32806-1-haibo.li@mediatek.com> References: <20230915024559.32806-1-haibo.li@mediatek.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain X-MTK: N X-Rspamd-Queue-Id: EE88F100009 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: cx6qhqg9gi76m4es5nfsqtfwupqw196r X-HE-Tag: 1694770848-417086 X-HE-Meta: U2FsdGVkX1+kL4ypoW8YY23g1GSRKtXRfY7QoHaiGgVpCRwDMTyH/ranPZHdngVDsyazjyAT0FNTydThI1mdNtO8WutVH26y3G60vfACXPpzVxnDkyKxywZVDZf6wklWkvio+V+jTDCv1R1ksPJWcvOLWBfQLvTq59rIdZFMKmrDal3D6YsUWYJY/n5gy9Rqw7XkPWRaN94nOCG8/w+m9aJkW4zAJBxlSVWcqEC+VUuOI39NG1rTK0bqc+CDvFgL3rEdDhevdxgTroCTXa+Sl8TkHSokNKurVpuYFq6+VYP9MnLvq1vzN4Z7tWvAg7D8YX1a2OjgA7cf1CYD9r0Bv+1bOMNrLLEuoCNC8qqinflCJ1GDXoYnLtqoGiG0j99TqRovvHEw1yGIuEKJQWWtTsogK736ZOoBq9g2adHiBSDlXQ0be9KDLFoTQlQoLHqoe7EXySI8EoJho0tdBMyf9zAcEUAAVyXvqI6cOSlDBjWJTOKc7ApCq9FaxuGhY9XP8qhUvaM8rLhCx5aLcPiDAN3OfxM3eCgpWiowhkqCwXslcfoy2aCPWJB/G9McfCTK6bVBHIKyxA6SF4XFCIFIs8MzX70TF3R0v2XhkCXmplooijxZRV6tnERINmT9lTiYw1KmB4MhUaVhta7LnscwtUy+/KNUdmV6IkR9SXpMhgyJ6qLJ7cH0AS1l1K4RZdCRhd8kve3B5xCCuifQaSM0LrUyCScWgEwxX8zr2Kabscgrk2dH/wkbaJ1GI642LN05ZRlKrBkV4TdnJXb60TYR3/xWGILOMyrXOuFlnuR45tVtYirqSonFT+umVKrWgCaKemTbsLWvujYlz7sjlv/W0DZR8KOr8nR1+teMS0D+H9vsmE8fNR757Ty2r/IFN1xXMoMlTN72npPQzRbJRTaDTVkxrcvFVXj1EPVBWAPSh4EVz3SuVK9pU9BwHFgpZYh629DI/vsU/QzcXv5iVfS B6Jb0aL7 M9pxr2Hj3sAtUY7fTP8dLDdQ9cyogl3AnBi95cQQTMEtkfjkHSuwe7TmpS4qM5hLGZqIqF9imnzEHg6zO14HVT0q5mzW80Ff/2VyXMQ7p3B+oTwqknL6/ahBCQcsQvfDztfv49zIkYJbl/akOBC6jDqXZHOK9EB3p50zpl3z/OIgPxwxMNSIvZGCFg/LpIghgbfGHcr6N0RvS1B52aDYh1Xow8/t9Ug+rzXN+eT1n87BXUPelUaiG8sHEZdjiKYteklojRRa0ddHiZ0Q3VnqLhR3Ulg== 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=C3=A2=E2=82=AC=C2=AFPM Jann Horn wrote:=0D > > >=0D > > > > Accessing unmapped memory with KASAN always led to a crash when=0D > > > > checking shadow memory. This was reported/discussed before. To impr= ove=0D > > > > crash reporting for this case, Jann added kasan_non_canonical_hook = and=0D > > > > Mark integrated it into arm64. But AFAIU, for some reason, it stopp= ed=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 adde= d=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 Sorry to miss this message.=0D I checked inline mode just now.kasan_non_canonical_hook can print =0D something like below:=0D Unable to handle kernel paging request at virtual address ffffffb80aaaaaaa= =0D KASAN: maybe wild-memory-access in range [0xffffff80aaaaaaa0-0xffffff80aaaa= aaaf]=0D ...=0D [ffffffb80aaaaaaa] pgd=3D000000005d3d6003, p4d=3D000000005d3d6003, pud=3D00= 0000005d3d6003,=0D pmd=3D0000000000000000=0D ...=0D pc : __hwasan_check_x20_67043363+0x4/0x34=0D lr : do_ib_ob+0x108/0x114=0D ...=0D Call trace:=0D __hwasan_check_x20_67043363+0x4/0x34=0D die_selftest+0x68/0x80=0D param_attr_store+0xec/0x164=0D module_attr_store+0x34/0x4c=0D sysfs_kf_write+0x78/0x8c=0D kernfs_fop_write_iter+0x154/0x214=0D vfs_write+0x36c/0x4c4=0D ksys_write+0x98/0x110=0D __arm64_sys_write+0x3c/0x48=0D invoke_syscall+0x58/0x154=0D el0_svc_common+0xe8/0x120=0D do_el0_svc_compat+0x2c/0x38=0D el0_svc_compat+0x34/0x84=0D el0t_32_sync_handler+0x78/0xb4=0D el0t_32_sync+0x194/0x198=0D =0D When addr < KASAN_SHADOW_OFFSET meets,the original addr_has_metadata should= return false=0D and trigger kasan_report in kasan_check_range.=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 avoi= d=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