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 CE377C2BA15 for ; Tue, 18 Jun 2024 09:52:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 48DA06B0136; Tue, 18 Jun 2024 05:52:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 43DB06B013C; Tue, 18 Jun 2024 05:52:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 304DD6B0144; Tue, 18 Jun 2024 05:52:44 -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 127A66B0136 for ; Tue, 18 Jun 2024 05:52:44 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id B0F401C13BE for ; Tue, 18 Jun 2024 09:52:43 +0000 (UTC) X-FDA: 82243545006.05.6FD8F3A Received: from mail-yw1-f176.google.com (mail-yw1-f176.google.com [209.85.128.176]) by imf28.hostedemail.com (Postfix) with ESMTP id F1B2AC0015 for ; Tue, 18 Jun 2024 09:52:41 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=wg2MaOlA; spf=pass (imf28.hostedemail.com: domain of glider@google.com designates 209.85.128.176 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=1718704358; 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=/lD+4/1pW5cDhxFei3+MLKsCC6iwlHSFD/OS/9oOq0k=; b=t8eQrFGNZIPGXiRusuqGi2WYa7288KRCtsSDa8tM4Aa9LJwVFJMPy5AwDwGXqG/MSYOKAg aKR5vuA0fJWSxeAQZgwVkUEHWA4/TGkE4AjUdncNpzmdbIMo4tQQx6RE6+eHhoc3fzmNPp ZsNeWiHRo4nQk2095R1HK2Q1NTeyqTY= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=wg2MaOlA; spf=pass (imf28.hostedemail.com: domain of glider@google.com designates 209.85.128.176 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=1718704358; a=rsa-sha256; cv=none; b=quKraD5Jlan4yRhnSuRVgeBA/lPUhQUcfZS8Y44+eEv6KX7Xo7pBAZ6zrM6rnBdNw8nyr9 18gNGRBQ7Qz3hbrwrd8n2bUYW61ggz4PK3O9K0ZtgJA8iv2KX9LXLKPjUevJ3S2xNPD/7h D90VNLjl8YBjurIHUwMzP1HnmS9Cyjg= Received: by mail-yw1-f176.google.com with SMTP id 00721157ae682-630daaec9c7so45363637b3.1 for ; Tue, 18 Jun 2024 02:52:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1718704361; x=1719309161; 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=/lD+4/1pW5cDhxFei3+MLKsCC6iwlHSFD/OS/9oOq0k=; b=wg2MaOlA/3hi/OsebqTnzrRPLhWD4h0ozpRlMWft9CTZlCwjIxC9IW9i6cuyI4B7RL SE3/LrY4xLQNPeJZwUfvbU5tQuRdVadDF8hjnY+e0HJ7LLjVgghisZ2YPCUDp7r5SL84 +Z5HhdxFkJCIn9LwjONqFgD4qfZ9VDiqdOkT2Q3p/p7/35GTifoFRnXkrJPhEk3qqG0T 42PUB1KARO0FFu6Pi8rdpUC62K3dExdLScWGg9hH8CL0fG/zobZsmsqMoGkqgiE1zKnF XjNV4hxzKNYIZfDTMztRQ9ay3vVT7xBezQTaGMtAaGzlodQATBDwrC/yocMNTFkkUHCv SuCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718704361; x=1719309161; 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=/lD+4/1pW5cDhxFei3+MLKsCC6iwlHSFD/OS/9oOq0k=; b=IQ/Y/2l/J4/KBuNphqY3Nz7t71v4bxyHMGk6+HA/OD2ZwuMlkogs52lKeyPrMN1iYi sWDh8KY/0t1Nrsisad3RP6iKXne7oS5TgDDxwHRWary73eLw/GvmlxR++a+qE/9LMtt+ dFUAd4mU6czaL6FEftvsT1ovtaslWjjm0JJHC+8aWZjab0parbGLyOichNbvHq7IMYjc 17dl8DeN3OSD+pqVUs9eMGQO92lVw46blBCPbdchJhWlIHl08eoB9rR2rvUCQrg2VLze IIlMbprkG+358aaEt+ZcR4Jblen9fLNgZqqBtb3/SjBs0tEqcLBeZV7h/9qiZQ859APL g7cw== X-Forwarded-Encrypted: i=1; AJvYcCWLp4qcFtOW9X84o8F0CfWch0fAtUwM78bnoe8Poe7Qy9ouxXX7j3kKYAENMfGxO9gFJvWVLp75ayMMFB7xbpm3Bzw= X-Gm-Message-State: AOJu0YwSbocpzTZBViFfOPkJImJRp0Asa2lcmQPDIvUfkxYzbR0665tr Nm6StRh52hirJ6Oe9+nrr+2KrUlbZ3dBaCSoxRZkRtActD8epYp8oSNSFqvgJ0k4c1pJwEzIuEa eWUUKR0upi6DNRavKUttFF/kCr/73qtITF5Z+ X-Google-Smtp-Source: AGHT+IHXX6s3T5giMDf3tx1b3GNQGpbXZt612lcGTYaBiEl87A/J206Ls33wh8SD7x8kKB2X9MD+tfEpY+oW/2ib5Ck= X-Received: by 2002:a0d:d456:0:b0:632:c442:2316 with SMTP id 00721157ae682-632c44224b4mr101739057b3.3.1718704360687; Tue, 18 Jun 2024 02:52:40 -0700 (PDT) MIME-Version: 1.0 References: <20240613153924.961511-1-iii@linux.ibm.com> <20240613153924.961511-33-iii@linux.ibm.com> In-Reply-To: From: Alexander Potapenko Date: Tue, 18 Jun 2024 11:52:03 +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: F1B2AC0015 X-Stat-Signature: oyqgnden5x91nr9umsunmcomytasfmih X-HE-Tag: 1718704361-724023 X-HE-Meta: U2FsdGVkX1/Nywnqa+OGq8Dl3SoaFqB4Zz3aHT3+6ho0XJRuwzxXAZ9iO6rYVkIPCPy20mJJwraju4/5mY/+vue/LVHcjn28avmIc/zet6DG591Sf3Alibaefrtt5EV6nskgNa7ELLB1Y2+LL7zDRq612515L+kjTgp9pODhVo+KXWeXPW+Ad4cxWirYW1wgW//xgo1J8cjCcomyvFiJmcowunQ7sO5e+Z+Mnxrx4sL2ueUAo9g0L4JSrD/cC3UFVlaGCi81JfC54NQEgZ74d8RaMLZiS2cvvTSDcMfXKoF8ZAq5IMRai/vwBm2shqb4XxFWxet/hVhk+/dr1tTYacpfhd0DadIAtDKH7a9ivN8KmrVDZimTTDJexK6TyhH7E8bVyVe/0Ti+L6eUcERNZJHQpZIJjU49tS3J0rwG3gkELA+Wzs0YHlHrJm9okhJjaOV7FttU7C4rOJBalQi0o4LAxNhjdO5luj9iohGpmnNplUcFC2yL8dL8sYc+bm7N3+bgGwpV8mMajTx6eyvA77bJsXuwhUMKZ7bjbvCdxr4j3Cgar09O8Rlu9xpv1GN1+OKsTJBBPzsLiVKTpqksxdZ0ULV5AVUMFjU5zvffvaNXRDo27GqZV3yzo6waT+GWkLhR2xAzBPbho/c89R7PNU6XfT6VjTgaGRrLuupRW58j6GBdsYCxIjrTA1sfY/bd76S8hro5aq/OcXH43q0e/EUY2Dkz54/Idfj43sYks5KFP8/eaaLbIwbZV270R6xc3V8rTEuRqOoMJxrw5pB2CY10Sur9bn96tJZWC4zNm0LaObu6IIobn0F0VwE4Z+NHL4Dsq+bBR524mH3bu3/7B2NrO/lLWSCMW1Pqz2l+Xdh+EeQDQlaEPZgTWO4jRD6hMgWwS1X5h2KiiMSyfD5fxBh0yuYDXRFEdxNQkdIbfkJY6YPifvtLrcwkg5wGvPMb6jSFC6pcHrxH4Yoxydl x0qDy9kC 2eJI9DsacjV/0DEu+Hq00rW99esyUb7MhjAMn6illd/H4OxsQhs5xqwcFD+DRwug5F9+oqnHrBpIHs3dV8cbogldF0rMseQX/1mHsgfveZoIHvxhHOy9sk9HEyEzDGZAXG+gCvyd94JkzG0a1esrA5ABlhbckos3wIQxWzQWz+C7Yc+lV1UYf+mgFWphRkclO3bWtRP20H4AdpZ1MSUlrFA2CxPa184+lxpzcukeERnTvVUyGadtGIal8VslLl+G2IX95AZ9WBNYQxbvNeC/Ccnq9+k32oIwib39E+pnUxew+qiaHkxzb2rQv3w== X-Bogosity: Ham, tests=bogofilter, spamicity=0.006611, 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 Tue, Jun 18, 2024 at 11:40=E2=80=AFAM Ilya Leoshkevich wrote: > > On Tue, 2024-06-18 at 11:24 +0200, Alexander Potapenko wrote: > > 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? > > Aren't the existing instrument_get_user() / instrument_put_user() calls > sufficient? Oh, sorry, I overlooked them. Yes, those should be sufficient. But you don't include linux/instrumented.h, do you?