From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="eGWDd3WI" Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1C97410F1; Fri, 8 Dec 2023 06:12:26 -0800 (PST) Received: from pps.filterd (m0353724.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3B8DKRqj015375; Fri, 8 Dec 2023 14:11:59 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : subject : from : to : cc : date : in-reply-to : references : content-type : content-transfer-encoding : mime-version; s=pp1; bh=pjb+6VN84nea2uIjeiseJx3tuY2waiFgw1F0aqU0WUc=; b=eGWDd3WI351P7umaXgcIL+KPI+l1eeb3m8E/DSIPbCllByEtG4jSrlve1AhQz+8bduCt rOFaIfmt2Iam4b+pb48PZbVChPJpwqSprFPjzJE4HLxsnKeqAXVJ8nHCvi903W6jq+6N 6kjehPRKhJuwWQSulQ04yfEw8gXVgcyLFwq0Gf07jXZKJJgSYUrPcL5FJVKcZooRO/0E vyvzNQwh7dM2m9nA2FZk63/mx/QkYlhVpK5cAfVkooPuxiZef9rMaw1OPzhhUn/zCg2Z ZNJvauT4oEwwc9wj1/f6b/+GKew0YNJsa4PYFZ6RQ3CcVyUKzmoGriyT1zJ3iRI8qGI5 Gg== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3uv0cu81a5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 08 Dec 2023 14:11:58 +0000 Received: from m0353724.ppops.net (m0353724.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 3B8EBvMb024578; Fri, 8 Dec 2023 14:11:57 GMT Received: from ppma11.dal12v.mail.ibm.com (db.9e.1632.ip4.static.sl-reverse.com [50.22.158.219]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3uv0cu80cj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 08 Dec 2023 14:11:57 +0000 Received: from pps.filterd (ppma11.dal12v.mail.ibm.com [127.0.0.1]) by ppma11.dal12v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 3B8DNTP9027021; Fri, 8 Dec 2023 14:07:12 GMT Received: from smtprelay06.fra02v.mail.ibm.com ([9.218.2.230]) by ppma11.dal12v.mail.ibm.com (PPS) with ESMTPS id 3utav39vds-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 08 Dec 2023 14:07:12 +0000 Received: from smtpav07.fra02v.mail.ibm.com (smtpav07.fra02v.mail.ibm.com [10.20.54.106]) by smtprelay06.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 3B8E79bX35062116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 8 Dec 2023 14:07:09 GMT Received: from smtpav07.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 851C020040; Fri, 8 Dec 2023 14:07:09 +0000 (GMT) Received: from smtpav07.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 94BE320043; Fri, 8 Dec 2023 14:07:08 +0000 (GMT) Received: from [9.171.76.38] (unknown [9.171.76.38]) by smtpav07.fra02v.mail.ibm.com (Postfix) with ESMTP; Fri, 8 Dec 2023 14:07:08 +0000 (GMT) Message-ID: <69e7bc8e8c8a38c429a793e991e0509cb97a53e1.camel@linux.ibm.com> Subject: Re: [PATCH v2 13/33] kmsan: Introduce memset_no_sanitize_memory() From: Ilya Leoshkevich To: Alexander Potapenko Cc: Alexander Gordeev , Andrew Morton , Christoph Lameter , David Rientjes , Heiko Carstens , Joonsoo Kim , Marco Elver , Masami Hiramatsu , Pekka Enberg , Steven Rostedt , Vasily Gorbik , Vlastimil Babka , Christian Borntraeger , Dmitry Vyukov , Hyeonggon Yoo <42.hyeyoo@gmail.com>, kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-s390@vger.kernel.org, linux-trace-kernel@vger.kernel.org, Mark Rutland , Roman Gushchin , Sven Schnelle Date: Fri, 08 Dec 2023 15:07:08 +0100 In-Reply-To: References: <20231121220155.1217090-1-iii@linux.ibm.com> <20231121220155.1217090-14-iii@linux.ibm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) Precedence: bulk X-Mailing-List: linux-trace-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-Proofpoint-GUID: mSCq_lYucee2O1CVB9SBy2svcmxdcZAg X-Proofpoint-ORIG-GUID: WlHzW7-H3uATOo0XFfgqaql_BSNz1z1A X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.997,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-12-08_09,2023-12-07_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 mlxscore=0 mlxlogscore=999 spamscore=0 clxscore=1015 phishscore=0 suspectscore=0 impostorscore=0 bulkscore=0 lowpriorityscore=0 adultscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000 definitions=main-2312080117 On Fri, 2023-12-08 at 14:48 +0100, Alexander Potapenko wrote: > On Tue, Nov 21, 2023 at 11:06=E2=80=AFPM Ilya Leoshkevich > wrote: > >=20 > > Add a wrapper for memset() that prevents unpoisoning. >=20 > We have __memset() already, won't it work for this case? A problem with __memset() is that, at least for me, it always ends up being a call. There is a use case where we need to write only 1 byte, so I thought that introducing a call there (when compiling without KMSAN) would be unacceptable. > On the other hand, I am not sure you want to preserve the redzone in > its previous state (unless it's known to be poisoned). That's exactly the problem with unpoisoning: it removes the distinction between a new allocation and a UAF. > You might consider explicitly unpoisoning the redzone instead. That was my first attempt, but it resulted in test failures due to the above. > ... >=20 > > +__no_sanitize_memory > > +static inline void *memset_no_sanitize_memory(void *s, int c, > > size_t n) > > +{ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return memset(s, c, n); > > +} >=20 > I think depending on the compiler optimizations this might end up > being a call to normal memset, that would still change the shadow > bytes. Interesting, do you have some specific scenario in mind? I vaguely remember that in the past there were cases when sanitizer annotations were lost after inlining, but I thought they were sorted out? And, in any case, if this were to happen, would not it be considered a compiler bug that needs fixing there, and not in the kernel?