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 02A78CEE347 for ; Wed, 9 Oct 2024 20:35:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8BAC76B0083; Wed, 9 Oct 2024 16:35:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 869F26B00A1; Wed, 9 Oct 2024 16:35:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 732BA6B00A2; Wed, 9 Oct 2024 16:35:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 55C4B6B0083 for ; Wed, 9 Oct 2024 16:35:25 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 489E91417B9 for ; Wed, 9 Oct 2024 20:35:22 +0000 (UTC) X-FDA: 82655218968.20.13C03D0 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by imf15.hostedemail.com (Postfix) with ESMTP id 99FCBA0002 for ; Wed, 9 Oct 2024 20:35:22 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=K6+i9Rjh; spf=pass (imf15.hostedemail.com: domain of elver@google.com designates 209.85.214.174 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728506053; a=rsa-sha256; cv=none; b=p8boUo6aXaXdvE5vf5lTw7Khqm0jPHIgUVNRAZTz2F8CpeU2zCwsa0Pini4lwxX8Qpx2Ve GAuX4vE8QDNlbwtM0rPDp2T2WbyaWI85E1Jx0RvQWQw2KrBFyzUahgn3aasnryX+qRHmkb i2igRWbx6TLN2WabdBtPNsDI8IP6kN0= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=K6+i9Rjh; spf=pass (imf15.hostedemail.com: domain of elver@google.com designates 209.85.214.174 as permitted sender) smtp.mailfrom=elver@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=1728506053; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=GXLCkw65d2S++VNyv8Zo9MSqFS1XqxeG9ZueQafHMXY=; b=MeRo7kggDg9l04jQjEdRcYPmcHbw6p3ttgv6Xur6B9yuZ/4JtO5chEUwrXOSXOllXkcxhV /hHw9+o2Df98m11SOkKaI4HlH1eHK9WUIbIllGIpkIGKkzsVh946ZEQX1PHxjUCUrsYrdk PZ94IVYb19vm+sOnyFKDhXLYNLnTubU= Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-20c5a7b2908so1290915ad.1 for ; Wed, 09 Oct 2024 13:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1728506121; x=1729110921; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=GXLCkw65d2S++VNyv8Zo9MSqFS1XqxeG9ZueQafHMXY=; b=K6+i9RjhD2DwEnEwbrBGZrF2kzGupLedLn2FjeR+Gb73PixCG3S8qV1JkCCTZwm2Yj aUJrgWZgYgMKGJaIEt6tNd3UIqsWmhfgbFfSY2hKZPPGGnznZqhlthuNzQP+nBDxAPCn rELnkLeSrf38Mg0cY/n5ocEwLE3bZcK4zA3VQXSwVvNMojBvhVy6Jr8YiAX4r1eECIP6 53wmG9b/sDRMQOM9aR42jAuYpzcQTIwFdXlOIazEeDIpThjc1M5p0voPF8aTH7/Y8nqv IzNhNg9LBrRKSL51eEpa1Hk4OmVKWYjXWConNNqmZ2ENxX1CxrKptwbpRBiNb2NDedhB U1NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728506121; x=1729110921; h=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=GXLCkw65d2S++VNyv8Zo9MSqFS1XqxeG9ZueQafHMXY=; b=DLdGm9lzP6zSINrvQTmjJJ+fOC+cPAbrPv+Y1lMueJ6derYyt5LGU/E7NX1y5BNgnz SRseITFONn1AlmzKplwSD25JjfIYaXfgcOvNwFLRdcEP4Ye6faStKgDmiE8BfEoLGcp9 tH94X/WyukzIyzIk0DtGni+m70z/cz4uh3TOZaunopUYApJbL8DxWZ/6WKcvfvUWTspz Xj4kG7aUL5al5cv/ZdYnEkheCPnn1Uo/2ryiGsesGzKDi6nc94fUjTfE3GhtROkIIugI Y80+f2lyacrvRyWh4L4L5P75RoSBJIbHIWB094BUc7UHRf9/sT7nQWoOJlLfy57Oypao ifhA== X-Forwarded-Encrypted: i=1; AJvYcCW0r2aX8cJliwCBV9Gb4AV41TdBpEe5KuJNTXHZZM4C6CzDPyaAvtm8+fQb/v2iMBH6ena6g2yUrQ==@kvack.org X-Gm-Message-State: AOJu0YzB1EYSM4LTb3qjWsT1C08tFa6cEiyDl0VP4qTZwJHpMTWyeUXp cRMEsv4VQq4MNLu+EyCgzzBme0W06k49sY2kWbptwZRmpGu9S/KAmFR2UVGHJS4o9oSQcQBxtOh ACRg6goZUxwu3faHd2TkJJVBHM/1p0g3p8M1h X-Google-Smtp-Source: AGHT+IH6w0gjsL4Vx8BKOWRoSzBUrC6zu/uKFze01J9tNx7obSdLJkDVbD4YEXLF85AjPB+FzOvy9/ia+//jA3hLRrQ= X-Received: by 2002:a17:902:d490:b0:20b:b48d:698 with SMTP id d9443c01a7336-20c6370bcf0mr51380195ad.17.1728506121152; Wed, 09 Oct 2024 13:35:21 -0700 (PDT) MIME-Version: 1.0 References: <20241008192910.2823726-1-snovitoll@gmail.com> In-Reply-To: From: Marco Elver Date: Wed, 9 Oct 2024 22:34:43 +0200 Message-ID: Subject: Re: [PATCH v4] mm, kasan, kmsan: copy_from/to_kernel_nofault To: Andrey Konovalov Cc: Sabyrzhan Tasbolatov , akpm@linux-foundation.org, bpf@vger.kernel.org, dvyukov@google.com, glider@google.com, kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, ryabinin.a.a@gmail.com, syzbot+61123a5daeb9f7454599@syzkaller.appspotmail.com, vincenzo.frascino@arm.com Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: tg5hqs1xmdi9g9gb9pifeikxfyeuq8e9 X-Rspamd-Queue-Id: 99FCBA0002 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1728506122-740682 X-HE-Meta: U2FsdGVkX1+0UbCzDPtmvyicCKg5rWTyNX61u2ORUX7ILwkyzDrg7Gvepe9kwF5NJNLLbSNNbKUaJw78zETOXxr4eP5Dq84Z8aULXY1bfsetn+mSd9q4d2acYFXpTBS+PmTOSsczo5YuipS4TwU+DxDPebQcpqkVMcJKECuqxn87t2AoqrKMAFjecIqk+ocC9jvjZAMeNVY1F4E+fl9lpJgScTmAlDhcP9qSriRwQdesho1pZ1f1D98oJeSg8Y2/AjoO/ke6/byxo4fWNoqQ1+3oEn8IT+3M4SOnoIBN0Bs7nb6r6/Sh8fIv5M0gQUyjqhuOIVFLQUOs/QTpfwTvTd7KM0BwgktQVN5zCVbAa8Nzj/VAYfCMWZg2LeR5wy3qvt8wanjSppgVRAUBGbwC+bJwMEC3KvMkWpvbcWhQ5TNimAv7e5MPYsCoasEypsS0Oli5FvQjVp5c1ruA0HSu+f+aOAsbBf1KgfuIAmncQfU+t+a04q2Avn4LurZlE5RgBeUbc5ZmgxnXFNOXJk+Ms2Pqqv2Kg6qlVGlcpOqY6dfQTLyLt3VOVvI09izSTHDG0Lqerbm3vEcE9GBr9EJ+BqKq6BP11+t0lQYH3SEd1NCDGqzIp8fou/fyTvCW+1HGgDB3/6obcLaTvkGCnRolV7EBqLavmRavc/roF28vF7W2ENjXtqjQgPwb28zbZoo3iH8rEQBUGX2zFS2EmuQd05+P+D5I1wgJhmnAE8bHPpm6bemxYGziYldFO80mXRtZh/TA7V8zhzZafz+cHWeFFT4R67SvCao+zrrdI9IzciaDMblHBfci1ulDQgyJ0nw5J42ltOt7WZanBPfqtJ6g7MP/EsLD5qEB/6BMNfNH/X4NGINxOqjuIPxh5G4SF8qSPoCB2LWGMA7cTPSq6t6wa2CDTxuVOQd2i7AjEJ7NrdedHiLNhP25wV23c1vvNKggKJZWCqrJrRcrz7om8IC gFIQ1Yjv L1VcttlHj5Lva9HvP3r+IJq+cXj9wV3lGStAhVNElddlbSeWCofc+2fVr1OmgFPijcvhI1ZOwr+0ZD5NnG8uu7SZNkmCCYiIRItYlBzb8o5klFDGeHWJI4BeFv1eZpbCEdVfKhvdEzbTYTn5l1ShUYZQtNoe3Dmh9m0VmjBWhTWW28DbunLFbP8tmT3UinpV4y+9qlRFj9xWPlLMRPG2e5hnvAR7TQ71CDWX5khRD13aQozKOo7YTRvBuk+ZY7yH4XeNmjiyfvodzHvkEEWzIYzzIA6ANtIrH3uluvKsa2XaQRRUovCRAnVJvnyLntW0j2Not8mc+3V0j+Ks= X-Bogosity: Ham, tests=bogofilter, spamicity=0.044454, 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, 9 Oct 2024 at 22:19, Andrey Konovalov wrote: [...] > Please add a comment here explaining why we only check > copy_to_kernel_nofault and not copy_from_kernel_nofault (is this > because we cannot add KASAN instrumentation to > copy_from_kernel_nofault?). Just to clarify: Unless we can prove that there won't be any false positives, I proposed to err on the side of being conservative here. The new way of doing it after we already checked that the accessed location is on a faulted-in page may be amenable to also KASAN instrumentation, but you can also come up with cases that would be a false positive: e.g. some copy_from_kernel_nofault() for a large range, knowing that if it accesses bad memory at least one page is not faulted in, but some initial pages may be faulted in; in that case there'd be some error handling that then deals with the failure. Again, this might be something that an eBPF program could legally do. On the other hand, we may want to know if we are leaking random uninitialized kernel memory with KMSAN to avoid infoleaks. Only copy_to_kernel_nofault should really have valid memory, otherwise we risk corrupting the kernel. But these checks should only happen after we know we're accessing faulted-in memory, again to avoid false positives.