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 E7EA8CFA74C for ; Fri, 4 Oct 2024 06:55:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7C5E36B0417; Fri, 4 Oct 2024 02:55:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 776B96B0418; Fri, 4 Oct 2024 02:55:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 63E036B041A; Fri, 4 Oct 2024 02:55:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 43A8B6B0417 for ; Fri, 4 Oct 2024 02:55:44 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id B669E16109B for ; Fri, 4 Oct 2024 06:55:43 +0000 (UTC) X-FDA: 82635009366.18.5DD4733 Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) by imf06.hostedemail.com (Postfix) with ESMTP id DB81118000B for ; Fri, 4 Oct 2024 06:55:41 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=H9CtBeQD; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf06.hostedemail.com: domain of elver@google.com designates 209.85.214.182 as permitted sender) smtp.mailfrom=elver@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728024846; a=rsa-sha256; cv=none; b=4Etznm4wEMO9hYql3i6kcOdPkRjouAbSyXPhw2oxqytWufzyLrVGXSygm6VtLBkHPSVRHs G9XQ/HDoCpbmFRr4gN2WShVzmnM18KM8PwnsNVEfbHYD/PvC6ZfAvRUc+zfghMnj83X4P/ BlRVtO+8NIheXI0nyiTm/5jhIRr/GKw= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=H9CtBeQD; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf06.hostedemail.com: domain of elver@google.com designates 209.85.214.182 as permitted sender) smtp.mailfrom=elver@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728024846; 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=q7o2gtlpEVASHHeeVwEYiWWRZirGk2x9V5M6y6RZYrM=; b=m2a5QkTi7qHnEcNX+GwIdjgUnQLiH77lIWw6gAL4KSaA7i7earGvkY9HnLQId82KLcXBKe 9/4SK89VJX2xRFwBMrRkw1dERGqxkMfCqY9ibrjkIpNAZ4L4CPqpK0QjeAnaDevoeXvxC/ ebLFsocmKju091Y67VnU9yn0gz95iHM= Received: by mail-pl1-f182.google.com with SMTP id d9443c01a7336-20b9b35c7c7so12299565ad.1 for ; Thu, 03 Oct 2024 23:55:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1728024940; x=1728629740; 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=q7o2gtlpEVASHHeeVwEYiWWRZirGk2x9V5M6y6RZYrM=; b=H9CtBeQDckeXP6QpJizHsYNl2KOTB4KIbJIKvBCp18TzORou1Rhqv8jGZSO2VoNahg XNHT68p9s8rsVcUE/BmE+9rf4HFBvXOl7TvBOjUs4m1orExKu1kJobs4LW4q4BYfBIje H1X5QNEiI3gQooygsm34NsKNwb4xhYTvcTXOW9DR+tDsmHHG1N1KscfOZDYu8dXmCf/B KC9THFWaW9l2v1VqZ6rZ1Zrsf8B+twjFvC95XXF2pSf9uYOzEbIy3JElqRv1xem3tUVv lE7Zw4Iivo/Tvja7foVO6q8r+5go8Y414c1NuljlnQyV5vl2wP4+iz4ndB0uXbBY00iv hSCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728024940; x=1728629740; 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=q7o2gtlpEVASHHeeVwEYiWWRZirGk2x9V5M6y6RZYrM=; b=ImucsAFh2WJ3lCPyx2sXZ+XegbDHZLIwlemcWo5qsT1JtEkq34zmW3Fbtu/c2soxSM sf7wrWyxV6zl7CAuRR5HSlETWD3ZbHkdZQEHKRNHeklqwcXfw5T6dtmdbR5wyZpLyV4R 8eVilDtSLkt7D1KpJ+/nuPpx395H8RODVI964tp3Fhj4njgHMfUeesN22FAH4cenWhtN SisPeetz4a2XDCJ5QRmGRHfVTW6x/XzS7pAkReaHO0yxRaiMljwdZmZ6tLaMb3s6E/e9 AkSRxcFHKxor3AsXpKtkz9HqW1PpqwXGH+8pTiOE2PNvslHEpM42P2GkGkJFxRH88vPW 1eww== X-Forwarded-Encrypted: i=1; AJvYcCV1QVU+nbD7d93nISjLGXVst3egoyoDZVqS/HTwGxC+U6Q/Zrgb8Imh9o2M+DCRhWRhVK0iwABMGg==@kvack.org X-Gm-Message-State: AOJu0YztW9/AeDzfubcvtwUDRjXbypoZJtVezZzF9EW/vBaMfa/yQuwu SF2UiMb5LEcpfmzB+Uk2J5Li6GQp4R5GbKjvAp0R/nUPgE6MHjGC2XjXHK3sgDYwfYcudz2qk/Y iNpEciOIBOoEWP7mbJrYAisSFWPakcEeMMxZI X-Google-Smtp-Source: AGHT+IER5/6RPqS5sXqaB50mfC5zJHEF1jn+rq4VXuAuewfa+zz/1/ON7+EV2E3ZuD/AA7eQOpg5VU+3NhbqwVMdjp8= X-Received: by 2002:a17:903:11c7:b0:20b:9f77:e8bd with SMTP id d9443c01a7336-20bfe04aca9mr24574365ad.36.1728024940031; Thu, 03 Oct 2024 23:55:40 -0700 (PDT) MIME-Version: 1.0 References: <20240927151438.2143936-1-snovitoll@gmail.com> In-Reply-To: From: Marco Elver Date: Fri, 4 Oct 2024 08:55:03 +0200 Message-ID: Subject: Re: [PATCH] mm: instrument copy_from/to_kernel_nofault To: Sabyrzhan Tasbolatov Cc: ryabinin.a.a@gmail.com, glider@google.com, andreyknvl@gmail.com, dvyukov@google.com, vincenzo.frascino@arm.com, akpm@linux-foundation.org, kasan-dev@googlegroups.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: DB81118000B X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 9ucfne3td884gq97ym5b9959c1qwpwew X-HE-Tag: 1728024941-301000 X-HE-Meta: U2FsdGVkX1+LlL5XCCn77Et8PLE4MYKjfANdNtJzxvhpqUNMvbewT+qSK+dFh+sQrqgooCvAUZuDMnMbXPnkJr1GiXrKa1yefDt8X/LkF3b33E0Eic4r/zAKqa9y6odFjI5ajdngU4M0K+GQ4u8AwodVl6pLfu9DuULBqrlzluEdkMyU0ay42iuDFplVoDnk1XwEQ1hlkeSO4tMBkYEVzW7q71PLkimEYTTijDBSByobF9ITEMrVplwmvHyCigMbPevPJHLCNIZ/Fir5we8afVnnZsBZfPSx/10Qtt1K0GxNTJsWURWZlUBN8PRjejtnOVbAf3bbS6mK1AYL86BLyYwQ0ogaVva/2Ci+gF/4EzaA2X9B0tPa06+t0mPDGBLfnQYcV938VpwRETc9Zub2QyR7Jd2Xgek2Yj9gNtHCew1Ex3pDbrQB55bN9GHoZTOR8HneFE+9YEvOlz/AU/ZxFzW2sSsqh4RQAz7qjZqd4EyiYXdiZU+6bfRUieLYvRIyBsbODqMr/xwv6gPG6WqZAMCyhntTfqv2U0It39SI/ip6wy45tsGybXJFoCWUt25/FlFxKTfL3OGsZGZZMbONNGJgHfbr6UBoE6C7tjFXqQWZ9QQMqhm2+6f8SqR4FB+6ILhoDMDb/NP71bPRwETYd3nM92ufYWGxK27AHUJB0q1o5wl7bjKdYjwqd6aKMH1OTdDTcAHzpSKcvaBnPYAfWMXWVTAd0s3QR6S6q8X3iZe0mD2+wjjk5JipC577jINjxabdxw1MC7uwjYZVLgXKnCNB1DUvsgnQr6xU+qb2CY0gO5laeu4Yhfeo7vBfyc4GnQ5wEfnPxjbQSGVwUMGUA/T9zM4xS8bfkoiZIjKjkEsPy48ynX1f95B54UHBbjMNqqbqYEEG748firvz/3k1NHE/l2pRLczAoAY4VzT8NL2YZbYfpLZiiE458q5oYBdhK5P3JWrMfHrYl4gfVGi VfOHaV4M TUNG0rqtQu1OSZNvHqk61m1OqGorKFRMbhGLoI6mVpQFxhppPrD402Zc+a8yaxTpE2HoB7m/axEcwF6vHyF1ELtSvJJYg4YNWVNJPJpm4oZ8oTb8E8D+V95XnkFQy54flLKb4NJPGNLzdtbVwUVDWj3T2dYEwNE03csnt7UdfOUey+HfGWXRfbq/C3VfIPrIQV9wCmAMviHr9NweF9tgueep88lVF9+k+cdwWYZZcTYAHYN9AtrFI1V4CzN/afVYhKnKx1Bqy3O+TZjZpIVMPnwk23casplBOHdd8TtjSWbitGu9Sm1z8Li89iyGNwQlGxqW7avvLodaXIc1c0jMw/Cm6KhXUsR0mA/QANv+cG2hr4BU= X-Bogosity: Ham, tests=bogofilter, spamicity=0.001559, 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, 2 Oct 2024 at 18:40, Sabyrzhan Tasbolatov wro= te: > > On Wed, Oct 2, 2024 at 9:00=E2=80=AFPM Marco Elver wro= te: > > > > On Fri, 27 Sept 2024 at 17:14, Sabyrzhan Tasbolatov wrote: > > > > > > Instrument copy_from_kernel_nofault(), copy_to_kernel_nofault() > > > with instrument_memcpy_before() for KASAN, KCSAN checks and > > > instrument_memcpy_after() for KMSAN. > > > > There's a fundamental problem with instrumenting > > copy_from_kernel_nofault() - it's meant to be a non-faulting helper, > > i.e. if it attempts to read arbitrary kernel addresses, that's not a > > problem because it won't fault and BUG. These may be used in places > > that probe random memory, and KASAN may say that some memory is > > invalid and generate a report - but in reality that's not a problem. > > > > In the Bugzilla bug, Andrey wrote: > > > > > KASAN should check both arguments of copy_from/to_kernel_nofault() fo= r accessibility when both are fault-safe. > > > > I don't see this patch doing it, or at least it's not explained. By > > looking at the code, I see that it does the instrument_memcpy_before() > > right after pagefault_disable(), which tells me that KASAN or other > > tools will complain if a page is not faulted in. These helpers are > > meant to be usable like that - despite their inherent unsafety, > > there's little that I see that KASAN can help with. > > Hello, thanks for the comment! > instrument_memcpy_before() has been replaced with > instrument_read() and instrument_write() in > commit 9e3f2b1ecdd4("mm, kasan: proper instrument _kernel_nofault"), > and there are KASAN, KCSAN checks. > > > What _might_ be useful, is detecting copying faulted-in but > > uninitialized memory to user space. So I think the only > > instrumentation we want to retain is KMSAN instrumentation for the > > copy_from_kernel_nofault() helper, and only if no fault was > > encountered. > > > > Instrumenting copy_to_kernel_nofault() may be helpful to catch memory > > corruptions, but only if faulted-in memory was accessed. > > If we need to have KMSAN only instrumentation for > copy_from_user_nofault(), then AFAIU, in mm/kasan/kasan_test.c Did you mean s/copy_from_user_nofault/copy_from_kernel_nofault/? > copy_from_to_kernel_nofault_oob() should have only > copy_to_kernel_nofault() OOB kunit test to trigger KASAN. > And copy_from_user_nofault() kunit test can be placed in mm/kmsan/kmsan_t= est.c. I think in the interest of reducing false positives, I'd proceed with making copy_from_kernel_nofault() KMSAN only.