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 87325C27C4F for ; Tue, 18 Jun 2024 09:25:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DA4EB6B0332; Tue, 18 Jun 2024 05:25:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D55486B0333; Tue, 18 Jun 2024 05:25:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C43B86B0334; Tue, 18 Jun 2024 05:25:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id A7C8A6B0332 for ; Tue, 18 Jun 2024 05:25:34 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 529891C12BA for ; Tue, 18 Jun 2024 09:25:34 +0000 (UTC) X-FDA: 82243476588.06.D17EB54 Received: from mail-qv1-f47.google.com (mail-qv1-f47.google.com [209.85.219.47]) by imf08.hostedemail.com (Postfix) with ESMTP id 92DFB160019 for ; Tue, 18 Jun 2024 09:25:32 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=fA3hgKeF; spf=pass (imf08.hostedemail.com: domain of glider@google.com designates 209.85.219.47 as permitted sender) smtp.mailfrom=glider@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718702729; 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=V4MXEMKcp5I9XclPQt9HVJ1nbtcnQ61M4kMdjmYxvDU=; b=bKFqfQLWXIWVKrUFQZNvPYshISBEeU7TDDII7IdR0wNpoOSgP7lnY02NY0kxkiC9ZG5Ge8 uZYdt9iOs9puq7l9dbDwMcCzXf91hSnYvFjrry2dfGpnda+pkcOiLqtDheRYqoc8zV9Tmd QAvP4FVYS9dMLOZ4eSY4urgfYQLP0tM= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=fA3hgKeF; spf=pass (imf08.hostedemail.com: domain of glider@google.com designates 209.85.219.47 as permitted sender) smtp.mailfrom=glider@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718702729; a=rsa-sha256; cv=none; b=d4TYM/snu3uWt8CLr5sSdRZQ4c+Snc9UNPltR8mcBRgrjOhJgtYYkFuU9By6AlbFqBF+7O niOG3Q7xiNXrjslQz74wGhyt9f5cAk4AiMf5993IS74t/gEfr0/FYvZLrDAhMKzyFCnuGT /4DO39ddSLEIrkne220ufcD+vx1R9zg= Received: by mail-qv1-f47.google.com with SMTP id 6a1803df08f44-6b065d12e81so25306586d6.0 for ; Tue, 18 Jun 2024 02:25:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1718702731; x=1719307531; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=V4MXEMKcp5I9XclPQt9HVJ1nbtcnQ61M4kMdjmYxvDU=; b=fA3hgKeFrpXTy4Di4G0OFN0cEiWp+JWkAWnLvm2NICITe7m0mrUIx02NoAgVQM8Zhl f7+2autBVBWFfimtvFNuFFVQ1u3o8UW8s5Fi2jVkFXgTpOnHxfEpkeKSAZa/94e9GjCy e4EP2yIb7lGkbUKo+I0c3iQddAmeaWxhtCe9HPFCpxLm+JHn6ubzpUXrsKXfmcNO6bxS aT7wXKlgIcvQEXBXS4l1TVJjgSOI1TMl6u1T0/DBJgYC63EHtnPaERmkcKdkjEJSECcI QmeLreUsH/5kSgAB2z7kVKEygaOP6sIR4ikQxM6McmWobaXaYvQMonp2dpbOI1BjLM+Y UVmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718702731; x=1719307531; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=V4MXEMKcp5I9XclPQt9HVJ1nbtcnQ61M4kMdjmYxvDU=; b=OWSDS2OM9Zw4ElxNfMMs1sxvw9K9z89c1sICZ7tIUQ9/9a6IOBH6yRdyPoP2udRyrj ddyHKe4Z55XWXkHRYKap/EPneL7Z9VvO/LMuANxMLHmSPcqRcOZFHEFB3RnlsHCN8e3E /K43RDTbOaUT+GCKQC23gYBuUa0URT6UeS+A9Y1t5Vzl+r1lZgAm/OH8FrdFW0ydO1Lc OC10HFsEFEbk4ZtGshm+DX2LRpUl9dBPELwUl0CZ6RhFNnw45tLEdNX6H2V7umnnv+UG SztAIUSBlpC5bTQfJdZ/+SvX0HnMyxinIvUxHpt68iEyDKHM9y9o0nysRegd3BsM5Chd l3mA== X-Forwarded-Encrypted: i=1; AJvYcCVyoKICeTg6mwkp06CIkZpSEcZUWZmtVQtXin1DrVdzlHCu8SgF5Ao58d56SJ3J7kj/rzu2nUTtCuZYwTLS9yzdpIk= X-Gm-Message-State: AOJu0Yzs72+/VQUwHcRBOZr4of95VUX+qakUya4wVYnXDvJPq2iz7U5Y QsAyGkic/3UE1eFBZKfF6Tc+IaOwnbCK+4jXwwKSvHGWtD+jOfj0qqx9lVEdDCFkm/0fxbCr8JG j/bGzJEOIT5sibFQsRMk3C8GMlndoU4nv4VXK X-Google-Smtp-Source: AGHT+IFRfUNJYndL8wAjatn8zq6n+Qt93BmmyIN+4VFyPbObVSvS4+erMVXHgpMv+VY+5qiKm1XXOgO0W2m66i2IHQI= X-Received: by 2002:a0c:c607:0:b0:6b2:9c01:86b7 with SMTP id 6a1803df08f44-6b2afc76589mr116376566d6.5.1718702731438; Tue, 18 Jun 2024 02:25:31 -0700 (PDT) MIME-Version: 1.0 References: <20240613153924.961511-1-iii@linux.ibm.com> <20240613153924.961511-33-iii@linux.ibm.com> In-Reply-To: <20240613153924.961511-33-iii@linux.ibm.com> From: Alexander Potapenko Date: Tue, 18 Jun 2024 11:24:50 +0200 Message-ID: Subject: Re: [PATCH v4 32/35] s390/uaccess: Add KMSAN support to put_user() and get_user() To: Ilya Leoshkevich 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 92DFB160019 X-Stat-Signature: kwktmey9wmo1pp8japn1n8tmd1fyjs9z X-HE-Tag: 1718702732-378531 X-HE-Meta: U2FsdGVkX1/bZKIb3K0xn/PKf1tEpqcz920uadVm8wYWeFOOoqSjv3wNmwhrgt5n9EIFUKeAhP51eCwLmvvt/93+wDIN0Jc3zIoryv6u7QO7bCkdYcchtubvVOY4gyWffo7GSUx32PAjF89AJiQAVScC8LIOZxe2zzahp6ytf4at7qEKTBgL2yZpBV7ii9X2+Cu/zw4Mba/ScDbcuUigblTbLu+jF9sga22j2lPQHpM8D9jTJqYA6sXgredsmMxQplIZPhTt4FzLSPyeBn3+T2bbASXqfZlIn1I71pNO62rwLr+ZBHTONi/3flYYMKrKP8kRa6ffjBo+hQ0SXaat31BxLYH9Ox0I61xgRVHfWUtxqh7Q8+EoG62cnejKnGA5inQwVeTJJGbPBsb0xSjQs+rBXTOCdtjp8yVRKm8UZjU2HmYVPE1olygl0Y2n5H0b2PXzS3CBN6dhxTG+q5IFSi6bABsb3kp5EhnVfQaT+6Qgxd9zMtL6a9E3zVcxeSun47/8yC4ZfuY5qv50dKMT6uBqywyf1swt+LKOjbME1GDXvgT6EMEspWo+RpzFSgcT1p3Y1egxLqdJWTnmeZHapNgc6NNSd4U6IGgU5L8nrq7AxjraiKkq0jrnidPgsCHT17YWh3C1jhx9E5lRYYA3CBBhsWMquJGRSCqYuc5+vIQ1RLmrTK6bK6j6/R0fcUG6eZWyGX7n49T5YFVondPqOiCto2LkmfShN52A5DiTdpoc39GfR2VeFsNFw/4Y1a/vnGR33Vk5nA8/yX5KrFBb+jOn2bcAarmRHDcqzOtKeihR2S0Y51Thy77grH0VOMwVd9serE9+DQ2bDuss67wiFwraEETEyVUGrdQ/59p+Pkzbg9ZsDQ+t3SD1mRuxjNqXPU1E8axDkUK004fjVYDq8nCcj8jOge3wKYW6JQ+1LT84R09KDsdr17je9WEogEN95aJrj7VSdTIpbOLgyWY yJ+h2B8D /2RCqyyCW4/9YQNT7GAko39wBXIrP0YxDIdpuhu8OCoimPusm4P+6Ts4/eq8IUjQDGyVgQzNIHcTyAM9POOH6pOC+mUuk/zarYVAwL0mXCrMNjt5oLeBbHOExJqM2qfcoanFu/T4IscdkbSAygBXU9XZPhVuAgXKH+u6/eWoY5T6VTixUbGdMfDUUO4Tdgx3XOfyGgY1TPk9kZTJFAgA6iWS0tnuY81yU/h4n5+vXs8R1Dp/W/wK//JJvhjuIlwUqOUE7/9ulX2p1mjq5fsVg382e8dN/oWkoc5sJ2K4mpA5jceTem0/wrSmKHw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.260416, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Jun 13, 2024 at 5:39=E2=80=AFPM Ilya Leoshkevich wrote: > > put_user() uses inline assembly with precise constraints, so Clang is > in principle capable of instrumenting it automatically. Unfortunately, > one of the constraints contains a dereferenced user pointer, and Clang > does not currently distinguish user and kernel pointers. Therefore > KMSAN attempts to access shadow for user pointers, which is not a right > thing to do. > > An obvious fix to add __no_sanitize_memory to __put_user_fn() does not > work, since it's __always_inline. And __always_inline cannot be removed > due to the __put_user_bad() trick. > > A different obvious fix of using the "a" instead of the "+Q" constraint > degrades the code quality, which is very important here, since it's a > hot path. > > Instead, repurpose the __put_user_asm() macro to define > __put_user_{char,short,int,long}_noinstr() functions and mark them with > __no_sanitize_memory. For the non-KMSAN builds make them > __always_inline in order to keep the generated code quality. Also > define __put_user_{char,short,int,long}() functions, which call the > aforementioned ones and which *are* instrumented, because they call > KMSAN hooks, which may be implemented as macros. I am not really familiar with s390 assembly, but I think you still need to call kmsan_copy_to_user() and kmsan_copy_from_user() to properly initialize the copied data and report infoleaks. Would it be possible to insert calls to linux/instrumented.h hooks into uaccess functions?