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 EA192C54E58 for ; Wed, 20 Mar 2024 10:40:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1FFE86B008A; Wed, 20 Mar 2024 06:40:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1B0746B008C; Wed, 20 Mar 2024 06:40:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 078266B0092; Wed, 20 Mar 2024 06:40:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id EDCEE6B008A for ; Wed, 20 Mar 2024 06:40:17 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id BF8FC1C157C for ; Wed, 20 Mar 2024 10:40:17 +0000 (UTC) X-FDA: 81917072874.27.426FEB5 Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by imf02.hostedemail.com (Postfix) with ESMTP id 46A3E8000F for ; Wed, 20 Mar 2024 10:40:14 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf02.hostedemail.com: domain of penguin-kernel@I-love.SAKURA.ne.jp designates 202.181.97.72 as permitted sender) smtp.mailfrom=penguin-kernel@I-love.SAKURA.ne.jp ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710931216; 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; bh=+71EL7yHyPxbE5mLWlDHn0FGrnDSG2rmWvmbU7hrWMI=; b=7KhRgWexzIt13xvr0Pv7CGU7oD8fj6/4A217BEEw2oQPkYI0cErhqO6f4v7+NLnDpoIYtH ttaxi6PYNfYSAiIx0l7m+VJw/9H5pihZ1VosORYennqhsu/p2wGVZVNdYTR53Z1zzrE5HF 0cj4opYclnSOGfXHCWztWyrtiP8Dwrs= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf02.hostedemail.com: domain of penguin-kernel@I-love.SAKURA.ne.jp designates 202.181.97.72 as permitted sender) smtp.mailfrom=penguin-kernel@I-love.SAKURA.ne.jp ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710931216; a=rsa-sha256; cv=none; b=u+7nZYJN/xmqjJtxJnTTPVRyFxDbfqoWzyFNG9tECwsCiWTt5z/It/IElBoD/kyQG/a3KU Y1b39bk+Xg1JhK6P38ZlEqutnNywYlk0NkwNXSQVMRGHeEeHyTUK4rZ3JVsaniYU4fP7j3 xV4ztzhKpRzMJr14OR0g7BPN/cgFkk8= Received: from fsav313.sakura.ne.jp (fsav313.sakura.ne.jp [153.120.85.144]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 42KAdo0k048716; Wed, 20 Mar 2024 19:39:50 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav313.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav313.sakura.ne.jp); Wed, 20 Mar 2024 19:39:50 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav313.sakura.ne.jp) Received: from [192.168.1.6] (M106072142033.v4.enabler.ne.jp [106.72.142.33]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id 42KAdoUV048713 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Wed, 20 Mar 2024 19:39:50 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Message-ID: Date: Wed, 20 Mar 2024 19:39:49 +0900 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 3/3] x86: call instrumentation hooks from copy_mc.c Content-Language: en-US To: Alexander Potapenko 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 References: <20240319163656.2100766-1-glider@google.com> <20240319163656.2100766-3-glider@google.com> From: Tetsuo Handa In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 46A3E8000F X-Stat-Signature: 46jzje6mpsyb9mxu6uwpgt857qmdf4ri X-HE-Tag: 1710931214-457315 X-HE-Meta: U2FsdGVkX18Nd08/lEEFSCVOIDSkbmzqc+5TPghCpx5IUIQms6eGhB64KNIdxMkQIR3IyHOheX1pGkTHmvqkHYOKJk8mt2EM1DGuDpxcza4WmgxsyT7ZzlH9Gdgc3A3sIK8FmJ4Yul2a2YOPvgqn3DAuHZWLwWYyDJcf6DV32iMLHRzrWjbVhxhMc3sQTrGSp4j7itHE/ruTwmsmti3f/D1/TarZnxOtxknRT9R0sU5l8S1NVJydXGsAwGv02Yq2QCV2d8dsE4/BjfEhG4XbDYFZ6GZJmMOSMWhkaDNCcGK7Ccd/wc5rk0enghUbwx8Lr1h9dipDTdOFeJCt/t05N29D+T+KnWiK79+V7MB9t2ukXGTOMyEPPEeBRVR2XzHprIB0QGR2ciat+Zs5yu+FB2sWv8Ui265WafWx8gOLJHdEOrO6czpO62kOE+hVzSCz5ZL+Jem0Hyl7og4QxpQ3in5bJZjmD1mhbcpgejz+4vJ8WtNdP/n1QQki89ORbwqubw7MtXvxlkHwie31WeQWNDwIjPJGnCxkWerj/hCS5TafUqaUppxOUsoI+fIVZEiS/GnN9aSHarx4ZSomqrKxQRagI0mI3s8myhMTWuz/9DGKylvr4tq5VmF1WokwIAFiPMcVD8qH66cu4Z1AjV2imhInwuEqR5QoQCKBS21JR5n/MAMHeyY9c7RE8CaqBhQXAiditqKiD/w9XK2qQfqnOdY3LGcXMcfZ70DSqCNGmRBe3Kkh1ZuzvaUxoXhz9ug6BO0hONw0z+5ehl8P5anFEt88danzJ7e8OPK2+52aepscPKQ4sL+aKy6k4vp/ZUS9C9VUsLxs7joAf3EbI/KFRqRfQXpc4v4OowJl3zd0To8vKU38wcNZGlLl+9EC7gEJQ6JFDD8HvIPoVuq1EB+g3CaK9HEgqBQjjNEfX/kIkSc= 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 2024/03/20 18:29, Alexander Potapenko wrote: > 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. KASAN/KCSAN care about whether the requested address range is accessible but do not care about whether the requested address range was actually accessed? By the way, we have the same problem for copy_page() and I was thinking about https://lkml.kernel.org/r/1a817eb5-7cd8-44d6-b409-b3bc3f377cb9@I-love.SAKURA.ne.jp . But given that instrument_memcpy_{before,after} are added, how do we want to use instrument_memcpy_{before,after} for copy_page() ? Should we rename assembly version of copy_page() so that we don't need to use tricky wrapping like below? diff --git a/arch/x86/include/asm/page_64.h b/arch/x86/include/asm/page_64.h index cc6b8e087192..b9b794656880 100644 --- a/arch/x86/include/asm/page_64.h +++ b/arch/x86/include/asm/page_64.h @@ -9,6 +9,7 @@ #include #include +#include /* duplicated to the one in bootmem.h */ extern unsigned long max_pfn; @@ -59,6 +60,13 @@ static inline void clear_page(void *page) } void copy_page(void *to, void *from); +#define copy_page(to, from) do { \ + void *_to = (to); \ + void *_from = (from); \ + instrument_memcpy_before(_to, _from, PAGE_SIZE); \ + copy_page(_to, _from); \ + instrument_memcpy_after(_to, _from, PAGE_SIZE, 0); \ +} while (0) #ifdef CONFIG_X86_5LEVEL /*