Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1599367pxb; Fri, 26 Feb 2021 15:35:06 -0800 (PST) X-Google-Smtp-Source: ABdhPJybvOEstIuuMqY1JD8vpXNW1cAj3HuLPlP3JF0+mMzaCaRooEri7vzfeC+d7lSs4y7LIb3/ X-Received: by 2002:a17:906:2a14:: with SMTP id j20mr5913763eje.88.1614382506792; Fri, 26 Feb 2021 15:35:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614382506; cv=none; d=google.com; s=arc-20160816; b=ZIKLzXu7RNxeDHecaibq3AGIsbsWUD5JakKeXaRGklDiDYR4pJXe0AK3aC15b21zXT nk8IWJejQeIQPWPrBD03tJozdMpaMFb3H59JbD3F3cID9hux/GGAWVjWiV8u46xTZNUW 1tnJCl9USK+n263ZCFs5wyUYLWm9ArZIxbxmeVVtBvNJ00mgk+AVLiCcJbegJwF4yp01 xYLHGW+RfCE1InK8pojUpyxXUrppd+PxgkYDf1qWu7JmOj+DOMkl1cZf1oXauYdZpCXj YDV9bsDxvCKF8K9f1OpUaFrwRzmjXlaNo60qZdISTc+ObLxW8Utfq3VcIWUm6gbDZoEH XdNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=X+AJlKea1wHGi2S8rp7unx01xAbGxd7rp+etIsvo8fI=; b=vedaOYSFgM+Z42EjkJENyi3FY+KQD5q7B6YX47q3RvG+WTmhvcJiDNGdQaZdsW8IBA lJ5Oma6Uao/qxJOIdA71PcR7yXk+HFUkaTv5dfDP9vgECo5vjunSP0fOUlK9k4VJzS18 Sfveevgqm8oObx8T3ilcZnaz+pi0SFcirWSQIHRfA9ENwM7r1Nyb7356lJTZ6YkNtSqS dtHvfcOx+yrR/OUjoy+IVKI5yIrda0ygOLHL0m/sBr8e9wg4BncW7ecLlUV47Rkth5v4 TPDN0pVKLPvxL5cng7IdmB+M1kMxZBvwoFVEFE5Vi/FU3Ycc4M1X0rBlJEZ4GD4U6Ota ZzFg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s12si6813793edd.70.2021.02.26.15.34.31; Fri, 26 Feb 2021 15:35:06 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229885AbhBZXdy (ORCPT + 99 others); Fri, 26 Feb 2021 18:33:54 -0500 Received: from mail.kernel.org ([198.145.29.99]:51076 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229698AbhBZXdw (ORCPT ); Fri, 26 Feb 2021 18:33:52 -0500 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B907764E83; Fri, 26 Feb 2021 23:33:11 +0000 (UTC) Date: Fri, 26 Feb 2021 18:33:09 -0500 From: Steven Rostedt To: Linus Torvalds Cc: Linux Kernel Mailing List , Ingo Molnar , Andrew Morton , Masami Hiramatsu , Jacob Wen Subject: Re: [PATCH 0/2] tracing: Detect unsafe dereferencing of pointers from trace events Message-ID: <20210226183309.0edcc54d@gandalf.local.home> In-Reply-To: References: <20210226185909.100032746@goodmis.org> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 26 Feb 2021 14:21:00 -0800 Linus Torvalds wrote: > > The second patch handles strings "%s" [..] > > Doing this at runtime really feels like the wrong thing to do. > > It won't even protect us from what happened - people like me and > Andrew won't even run those tracepoints in the first place, so we > won't notice. > > It really would be much better in every respect to have this done by > checkpatch, I think. They are not mutually exclusive. We could have both. One thing that's nice about this patch is that it removes the possibility of a real bug. That is, it will catch the dereferencing of a string that is not valid, WARN about it, but it wont try to dereference it (outside of the strcpy_from_kernel_nofault()). And hopefully the warning and lack of data they want, will have this get caught during development. Also, there's cases that %s is allowed to reference data that I don't know if checkpatch would be able to differentiate. As for the other pointer dereferences (the first patch), those get caught at boot up if they are compiled in. That is, you don't need to have the events enabled. The boot up code will do the verification on all events that are loaded (allyesconfig will catch all of them, which I need to try to boot with this code). -- Steve