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 155C3C54E67 for ; Wed, 20 Mar 2024 10:13:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 912006B0092; Wed, 20 Mar 2024 06:13:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 89BF66B0096; Wed, 20 Mar 2024 06:13:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 73E4C6B0098; Wed, 20 Mar 2024 06:13:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 5BF9B6B0092 for ; Wed, 20 Mar 2024 06:13:05 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 2364D141211 for ; Wed, 20 Mar 2024 10:13:05 +0000 (UTC) X-FDA: 81917004330.06.1FC06CA Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com [209.85.222.174]) by imf19.hostedemail.com (Postfix) with ESMTP id 5618C1A0021 for ; Wed, 20 Mar 2024 10:13:03 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=aoOxO3EE; spf=pass (imf19.hostedemail.com: domain of glider@google.com designates 209.85.222.174 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=1710929583; 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=tTp075kwbc6LfAaXvHEolsZ8AZN/qxf8o0cgwtL8pnM=; b=iQVvw036NjePtAJPfFBT6sLAZNLWjJ99G8ryfLan9WMmFtyxmxD2V1127EAphfO9JuEFHD zeBW76fGbdRzMvIR4iNyPKwtNYK4rq0vYGOpIyAluHGrRkfqD1Ia8LVPBe6P26RfYk9sKS dqF89t4j1CfJ2i+WhZiA0Q6OBWuYaR4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710929583; a=rsa-sha256; cv=none; b=l9UiLih2+p0LhEGchMnjyklcjKC/rvfcAYll+DX4RBncaKJOzDcG9a+QCkeA/CeuRu536W RcckYcIHhiPNIW2YORJQuP7kFUq23zuslLX9dSsMa2LJuGWebBHvBpEn+OHid34ImBF/bm tGF0UgkcEOtsYM8j5V03J1dMj5kMMkg= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=aoOxO3EE; spf=pass (imf19.hostedemail.com: domain of glider@google.com designates 209.85.222.174 as permitted sender) smtp.mailfrom=glider@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-qk1-f174.google.com with SMTP id af79cd13be357-789e5021703so270032685a.0 for ; Wed, 20 Mar 2024 03:13:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1710929582; x=1711534382; 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=tTp075kwbc6LfAaXvHEolsZ8AZN/qxf8o0cgwtL8pnM=; b=aoOxO3EEU6xNpzS0k7uv3pkhSQpf6k3kgD5ufOXyz809/Mh6qkvnD/eAw5hlsKQGij /vw0NyHQND1NkrdkIj79kZR7ARyQLXobqB95bc8tzZUj+z3vF4d/XgWrWi5uwtnKdKZM r2dxrdkfuUiABraPQy0SySzFd00C2jkTOvBgHJgZelIACuQgNwfAVycCW3sIFdWBUp1E V4EdVRfvUkXQpju9TiHr5iY32UbdyJGXv3XA7bGFC//f2QqWY6hnDnj1c01iSdaa4AuB nwGX2jfPiAbc0PHZ1JIKeym7EcByVvSrj7HDFAVSy1dd6M9TcvYqjgHaZseKCS9A85u4 E3EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710929582; x=1711534382; 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=tTp075kwbc6LfAaXvHEolsZ8AZN/qxf8o0cgwtL8pnM=; b=kypOUQejS7pkgBJ93R6VpMtdVs1Q5hf23rWPk+fatifT4e7HknnwOymAaeXxhmpXrw cBCKbMViDziAJPyN8/HZwHAoaJjnTEAuTY4pAofhdNbV7hYuK3R/UTC5RP5udxlxdTfT bvntRp23oUQAKWKTAvzPZAJcmHJ+1Nq7ppQcTE16FiysAeAqYkrFRflkfm87yF9jT6nG gonZemHZ5wSO3ylMqEn4IzlinHHzoKlfI+5fVo7M7r1MEdDo43/Yl8tEjxUEWUuMgib6 1R5a4tLAOPpPRs2VV4sc5nyKe2bNTZ0/hw9+SHejPx7VKD9EzgQuwnNISHY3RNEVX36O 4+sQ== X-Forwarded-Encrypted: i=1; AJvYcCX6kqHYl1cF+P2EvJOu93Ht3ahHxBEUoHMAc6kykOt2ITOSfWgVCS2VMZIoYK8pvtqf9/nllF0JOPJ3BQHlBHxMAFU= X-Gm-Message-State: AOJu0YxmmbOK3R9qyfJQZlPfxSDSWDeccXzweBJ5fTCtos9ZrDThvkYp 4QL1VcDVcMxUXJdSnwspWJxHI1v22AniBUys4OhrtyJDaZxGAJJLWoKzCgN99F2DXVlViN1s2R1 tV8kBseo8GwKtiH3/7PC/piYTmVvNY4Ysm1l4 X-Google-Smtp-Source: AGHT+IGLI4oQNvj0ZrWfizm7uSaZYg0DWwsg20e7D8kug0TuDxHAh+4D2eaIqN2wxNhaeqBmJNG5Et8TjvmFmBQCIhI= X-Received: by 2002:a0c:f38e:0:b0:691:3ccd:62cc with SMTP id i14-20020a0cf38e000000b006913ccd62ccmr5727614qvk.6.1710929582254; Wed, 20 Mar 2024 03:13:02 -0700 (PDT) MIME-Version: 1.0 References: <20240319163656.2100766-1-glider@google.com> <20240319163656.2100766-3-glider@google.com> In-Reply-To: From: Alexander Potapenko Date: Wed, 20 Mar 2024 11:12:23 +0100 Message-ID: Subject: Re: [PATCH v1 3/3] x86: call instrumentation hooks from copy_mc.c To: Linus Torvalds Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, kasan-dev@googlegroups.com, tglx@linutronix.de, x86@kernel.org, Dmitry Vyukov , Marco Elver , Tetsuo Handa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: ef8a87yr9xkm3jqi3e5inkufypno7oem X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 5618C1A0021 X-Rspam-User: X-HE-Tag: 1710929583-996855 X-HE-Meta: U2FsdGVkX19jsfo8ovSIY5YPxAKnnFUigMfC/130JZ1WS0faCmSK/kOsg78CsUJpWaanzAkwJSsTdQkg6dCROGKQDPa/1HiJ85QgLrKVgeE0dCCaNZTtYowPyVRZ/BbLiTqnT2r526SwY/oWfTcO7e5j/Ah3eAMNBx+waji3fPsKWo96G32hAZ8XyPrDlxyIiyfSP6BP0jpKeiqyT7SrATzKITb3zoAIIwJsTbGuIimgpVS5mFFRmcTYb3B3Z3c8vkPpCMKgOAxoOEi5XXrH54GOCXuzzZgue2P6QvHpiD4HJOYqAtW2t6nJgmrN6g/NUsd439VWxcJcyCUyh4ZibA9dpHHXUdJpsPMZ568uZB+bH9px4EeLHaPdfO2oLMAn1R7orKd2XvULzAl+CAJhlSrrieQiSoGymN256mETUaGae19jCR/M0bRzylGh4/tW3i/lBUaIhLrkAlxx7lrwC6UentkQrIB/7Y58nPOdZMJB3hvgKKSvC4XUqnZYH6ZMKBT4s0e20n/ECEnNP1w0lj/5gayeB+MlrF1J356RaxBMCnvFCsw1Jd/WeYN55wc/gsTe9Y3Sd2De6Ca5ujDuyb7wTsJm0VwayTbrhztnOfPsQgcX5DDhZZ5S3ZMvCwNninnXrArwGtId0dmrYZjvDiYbqZbdDGm/E/uj0X8HsRASwFjHR/4bg8WkTb+wYTh0WZ7TSm+KC+2ZJT8zRtccxkfkLt2U4f0Sqn65H6g8mW6BKRsUWMQVbfw0BM+uu5K1qr48sMmS00x/18zLGxHP+RzhqNYQ8ZoxU4y59sah6RgnXXrUpFLEE0AjCwOtxOt1w1SWhVV8gbY4D6Uh+IsjIx+ZSZhDjKmMOr74wvW5HtEUwVxmkVbz8p+R2uz05pb39ZmQOoxvb1Tj7ISW34CJxNsKpBs9DCYqGtLMsEr9uGn/tzGYToV4LhMqSpXZ5gnrUac+/eaXYf+q3dLUXxr i32+vJXQ g2nwj3n/cnzYEhWuPcp9TepUuCn3zF0AI6kkGZOs43yiEE71VopWFT7HWLrYnSpZThdlmVBIuylsqjF9YWQNhXW+K4WaTzE+HchH9wJrgZHxkhk5pKSNRpCd9NFiXAK580/IHgb7ESruQpS6RhEvQOt07WI2Jq5sh6AILa7gnFe2ffwGiKI/LD3BO1vYujET7V1Hx4ZNpyt+nI5lFnqJVOtGuq61bIBe1eO3nLKESjOKcaT6oHXO8jNeFHSJpqqrFlEiZlgAvvdEKw0cw9BfHFu9ymXRJZ1GZlsCL8O6/qnTu27t3dba293S6vc0FNnjaDSp29H8dBXmGv98wU52Oy+56QrWWWSUyAoCfOFBwLxvkpgxpIqdN3AgL5hHYbNPr+xF1aVoU4CcPynUDcUEZtnxhGDVEaxgKM1jU 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: List-Subscribe: List-Unsubscribe: On Tue, Mar 19, 2024 at 6:58=E2=80=AFPM Linus Torvalds wrote: > > On Tue, 19 Mar 2024 at 09:37, Alexander Potapenko wro= te: > > > > if (copy_mc_fragile_enabled) { > > __uaccess_begin(); > > + instrument_copy_to_user(dst, src, len); > > ret =3D copy_mc_fragile((__force void *)dst, src, len); > > __uaccess_end(); > > I'd actually prefer that instrument_copy_to_user() to be *outside* the > __uaccess_begin. Good point, this is doable. > > In fact, I'm a bit surprised that objtool didn't complain about it in tha= t form. This is because a bunch of KMSAN functions is ignored by objtool: https://elixir.bootlin.com/linux/latest/source/tools/objtool/check.c#L1200 > __uaccess_begin() causes the CPU to accept kernel accesses to user > mode, and I don't think instrument_copy_to_user() has any business > actually touching user mode memory. Ack. > In fact it might be better to rename the function and change the prototyp= e to > > instrument_src(src, len); > > because you really can't sanely instrument the destination of a user > copy, but "instrument_src()" might be useful in other situations than > just user copies. Right now at least for KMSAN it is important to distinguish between a usercopy and e.g. a URB submission: both are checked using the same function, but depending on what is happening the report title is different. The destination parameter is also used by KMSAN to print fancier error repo= rts. For an infoleak we show the target userspace address together with other information, e.g.: BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] ... Bytes 34-35 of 36 are uninitialized Memory access of size 36 starts at ffff8881152e5680 Data copied to user address 00007ffc9a4a12a0 It comes in handy when debugging reproducers locally. Future debugging tools may also need more insight into the semantics of the instrumented accesses.