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 084A0C54E58 for ; Wed, 20 Mar 2024 09:29:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7243D6B008C; Wed, 20 Mar 2024 05:29:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6D3BF6B0093; Wed, 20 Mar 2024 05:29:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 59BE86B0096; Wed, 20 Mar 2024 05:29:47 -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 4C68D6B008C for ; Wed, 20 Mar 2024 05:29:47 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 059FC1A1293 for ; Wed, 20 Mar 2024 09:29:47 +0000 (UTC) X-FDA: 81916895214.24.4468744 Received: from mail-qk1-f172.google.com (mail-qk1-f172.google.com [209.85.222.172]) by imf25.hostedemail.com (Postfix) with ESMTP id 22DB3A001E for ; Wed, 20 Mar 2024 09:29:44 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=VXiX5zim; spf=pass (imf25.hostedemail.com: domain of glider@google.com designates 209.85.222.172 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=1710926985; 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=bLyoCiqbHiSdNZKr0m0tptqhq/5sVBW4PAT9ynMrYdw=; b=YrYsBoC1D2JC3CrT4DNiWXRCYxSSOw7y1OoBZHqwn1U7LzbULfGkGnXyJH1MLObL3f4ENE DVIW1VYWEqWmWopK+T6JjO2B4/zu6rpc49CP2wdIg8MVvW2n6Vh6RLP2mMkw+b8i8q5BZa +VpUxPwq5QfsGK5urtuQEbE4vx+m3k4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710926985; a=rsa-sha256; cv=none; b=dui1WvtB5NA2dKicsSVDbiykoQf3FbLt9qULCuvLVkSZdl6zuBROC0ne3cfZ9ooZVGxj8H NQ7BwJtZ5wojvdO29w/TY2SSHKSQiLheH7QeuhX4+PSWpcli1s+YqjAqa31KHaCy6lE1UK r9GClhhIb+NtI35pbdue0xVAEIWYEks= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=VXiX5zim; spf=pass (imf25.hostedemail.com: domain of glider@google.com designates 209.85.222.172 as permitted sender) smtp.mailfrom=glider@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-qk1-f172.google.com with SMTP id af79cd13be357-789dbd9a6f1so441681785a.1 for ; Wed, 20 Mar 2024 02:29:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1710926984; x=1711531784; 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=bLyoCiqbHiSdNZKr0m0tptqhq/5sVBW4PAT9ynMrYdw=; b=VXiX5zimXxuXqjUlNOuXLph0fh6XbkdkRU51Ec3dZ35wC0CDd4ZQmAHm2Ppd6H6Tpw zOpvDLxKhauRoNYe88VXmjws93LzBZApwtDHsOPuJDtyvUBWnE2X6wBJTtkKnt59WRKW aJ51j3ae0mtEmw3yqPtOjoRZBcfbEtDLCZHFMAZbZHQoJaZjPqMqgooC8po07Nq/mDBV hq1MGoYPOT89yD2qH1FfeO2P8msCcjkjvn3aghhhaWL/KRs89hWfh3DdJhzIjm9WG0c/ q6sjVPtq8tZhG7uAGSOCJ16jL1mM/iAjTj7cCmbuslOWBGfwGc4J4j4IzdGb34e0kxXE uRBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710926984; x=1711531784; 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=bLyoCiqbHiSdNZKr0m0tptqhq/5sVBW4PAT9ynMrYdw=; b=GYUxsPZU0cLKSfG4/M9CvQ7w7DOfDyRi6vyBnRajMHZ1JfV/PJFigJc4sfJ52fsYyZ NfOiXOFiKFJPbeZc+fA093ikXHxwHa+4xaoLd1or+vcfv1tWXSp/KCRm6DghYt/Dtu52 l34BRJYnV5A/Nq0Z80n8Sy+rqvhd/VH9MVZ28uR/3LvQnJe7XTEV11qZ7CXnUwklWdhj tSneoPibtb55wx/2Pq/gnBBHayXR5srqsiTDfWv1g4FdnaWmXm6Qs/26Tcu5FwTcG1Cv qxh8izj93VHANhrYVOJ8du10Rfe8MThbI7vHF2gXKwp7zGUfL3be9lCguGqDeJ3KVNin LS0g== X-Forwarded-Encrypted: i=1; AJvYcCWpVAowB845BgiGDXid+mzppIXgGcEnYMvsnqD7dN2QYpX5KhP1s+BIPW+GPV1aswVfrL9kA+f9Uei0DQVFGQBtwV8= X-Gm-Message-State: AOJu0YxM5PqHGSk3t59Iqii+ANpIJUkXExGNICoFNRzbxpez1d+frDoW Epms6AlXsnPYiFi0528OqhWrTYE2jr4m1vt1zCINJVfReByp8/VePmebcM0R6nQ7U9f6zwHlnDG oZGG/ZKdQqnTS7/hMUNomONZZgYcZzOFVVKQx X-Google-Smtp-Source: AGHT+IEWCL5NACsTa3NVpSQB5eIX0UlfZkWAmrIj1tIqtW/2Ztw3IFXs62zk0mbaPLCfBgv7avANKn3cXU8SDwZl3/Q= X-Received: by 2002:ad4:5bef:0:b0:691:641a:7bbb with SMTP id k15-20020ad45bef000000b00691641a7bbbmr22395757qvc.28.1710926984060; Wed, 20 Mar 2024 02:29:44 -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 10:29:03 +0100 Message-ID: Subject: Re: [PATCH v1 3/3] x86: call instrumentation hooks from copy_mc.c To: Tetsuo Handa Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, kasan-dev@googlegroups.com, tglx@linutronix.de, x86@kernel.org, Linus Torvalds , Dmitry Vyukov , Marco Elver Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: gcu3dytx7dm16d5m3cbwko6mordj5e8p X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 22DB3A001E X-Rspam-User: X-HE-Tag: 1710926984-491851 X-HE-Meta: U2FsdGVkX1/fvlhU9i5HEUrPgVSYasYzSby0ukGWDlFw0csPJzTU/m7JXALxjTBXZJW3vuZlpORXIzr3QVC+c6/e3hCiEB/ZEQGd2qxx+YFtDkgHtR7dN/LjLmHAGpoWEa2Rg3xRvuAUPNCPt/Sw2HHjxcubCUpuk1KRh2D2FxhCeG6EPZtjldx66Qyn3zUEvKd5oeyK8yMoML/Eni4kFhvFYnj2a5OEHi3KfPNa0ARp3egfY4/2/IP/v9eD5OjLhEchav5bCvE25qLVrlAxMxU3TUkhI3Qdi/2N7jYvM6LIXZpqFAqrA8UoLsGFo3NNgyhmSrm5Fxp29U7/k5FBXjFt2Q3d++Tdcd7g+IIQMRJzKpKC0SEyEa58hhPhJr27fXpHPc5d2fsjYWS1Ta78a9NQ65SvkajlwvPopsdPpkBcIHxtj2EYhWnbICq0dwDgAyC7bPOHh4j+Y7+EgaAjQutc0XyNbdDOveJ5zGas94u6jmrdO60HWsxm9gVvzNf9W6KStSre24UkqoY7ILTgTZ2+j7ckBXMU86bcyqaNethZli7sybolAiT88+uJQolHzFhvtX8fzTjjR+K1zraxAhgzJlahec11PablfjwB2aSKqbfhrQYq8ZoZXtAncMp62JIZdV+WzACEjin+7x3yptkdN1dP1RWnJgLdYRKDGlWqjG+h5pn367QnDJbLYwR32QiPFmn5U5/mA7SKftNzGVqiSwngUs63TZlBODp4hloRTmXZU1xhWfWgcpkZiKWVyeGdqGp3PedbbqJVF3ZKBdBrPU8IJp4T+ZeBTlFknf5Mq4qVR6zR/avV91Og90sHYQrUlDhZOpxiguVYVbQus/ONi8b4dY/I8ghMvVwVX6wXWJglDOeclzM11v4kwfB5VGWP2jZYC3XdMG0mTs0WtnpHPC7CTZCEvltTgge1zAvXu/tNWiZgTfWaf0MhQTE9fu2WIzL+en6f3eMM5l7 fLZ0QCvo kUqhVL7AEr0Y1qTR8RwvNG8GHM+HTKENDHev3hlihkzLdMw8X4hjuCHAmXWZwGW9qt6tIoUDictGum9wlcv34Ua44poOEd9fGfSZY/vXD/L662DHI4JER6SESdTFzpJpQywAOkLP4r+ENuGePZSrFTc89bG4qKOgvBkZhpG5h0smt1KvLj3yxctGWRhWxRa6W5qw7J0lxfX7s5IZmVdZ/GgD3c3/YyKteBn4B7Ao/PqChFr7a0mXYPLPu0LiP8B159RBJm7UjgGMb6YZqFjmMuL4ebg== 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 Wed, Mar 20, 2024 at 4:54=E2=80=AFAM Tetsuo Handa wrote: > > On 2024/03/20 1:36, Alexander Potapenko wrote: > > @@ -61,10 +62,20 @@ unsigned long copy_mc_enhanced_fast_string(void *ds= t, const void *src, unsigned > > */ > > unsigned long __must_check copy_mc_to_kernel(void *dst, const void *sr= c, unsigned len) > > { > > - if (copy_mc_fragile_enabled) > > - return copy_mc_fragile(dst, src, len); > > - if (static_cpu_has(X86_FEATURE_ERMS)) > > - return copy_mc_enhanced_fast_string(dst, src, len); > > + unsigned long ret; > > + > > + if (copy_mc_fragile_enabled) { > > + instrument_memcpy_before(dst, src, len); > > I feel that instrument_memcpy_before() needs to be called *after* > copy_mc_fragile() etc. , for we can't predict how many bytes will > copy_mc_fragile() etc. actually copy. That's why we have both _before() and _after(). We can discuss what checks need to be done before and after the memcpy call, but calling instrument_memcpy_before() after copy_mc_fragile() is counterintuitive. For KMSAN it is indeed important to only handle `len-ret` bytes that were actually copied. We want the instrumentation to update the metadata without triggering an immediate error report, so the update better be consistent with what the kernel actually did with the memory. But for KASAN/KCSAN we can afford more aggressive checks. First, if we postpone them after the actual memory accesses happen, the kernel may panic on the invalid access without a decent error report. Second, even if in a particular case only `len-ret` bytes were copied, the caller probably expected both `src` and `dst` to have `len` addressable bytes. Checking for the whole length in this case is more likely to detect a real error than produce a false positive.