Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp2462028ybh; Mon, 9 Mar 2020 06:24:52 -0700 (PDT) X-Google-Smtp-Source: ADFU+vvhO9+Z0xfmgjyn5aH3a6d0cMTiM1LA/Nt8Pue+XBvoVJyQrmvgBuvprDXQ4l+KIscC5gLm X-Received: by 2002:a54:4f16:: with SMTP id e22mr11626459oiy.170.1583760292306; Mon, 09 Mar 2020 06:24:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1583760292; cv=none; d=google.com; s=arc-20160816; b=pC0HWLhW3Io7W3DVvJcdy/0P7X4rYLNtIenAgpmmgSIIBbbzy8fVx/ulNaYUjQnqH/ svIIK7LSAdwIGdbVLmAQ9TUQxmjr+10b9yu07mfkFDfhqHjM4gMDvh99tAoxxK6eUw8o 4XFmYA14qgan4OyM9N5ZF30SCkdtUJt+JYjFgdVXraNATvt2ES0IFxHHqUl5e4yxzZ8x neAtM/77p8GPF/EqlBkv+Z+GmpRbONZ4Wv0XVNhqGkKMbPz71YOg1UyRKi9G7Hta+u8i C+EECXwen746a58mEdUOrGNRxSK83U+qER5nLVKImNApg4cD/vk7CHBxbgWfL82wqZw9 zNMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=GwViIwI24h8dSfLuARzrTu8GWF259lcMGcWado28tj0=; b=oFLiqG7lXmbKMMqlGPFb3wjz9ZSujmj4TWbplyWK5IgHwI18t2/aF9eko2UFx0zx6P RGVNgoeQEcfuGA8gqat3mcAOeY62VcZEJi39hnCejZE/OBI941xsSZ5oafES58u/wJ7z ckFrWyEE9CbnwQon6SlJF5LxPRgEEwF2u07gKNSfuC0nbM6VmuY1V26BBXrbV42RGV4u S8v6VJ3GgWlN2eAH8li7QnCtdajUSsGcl0y0asMNGT9z/4hhqJ3/fZ+pU+Et7x62qOBF XqdV3fYow0uIWuzKkSUxfAzf3nF6BY6avKpvUkoISL5x/qHC/NfKm+BHdDmXbqH+XBzm zCrg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h11si2524355otg.171.2020.03.09.06.24.38; Mon, 09 Mar 2020 06:24:52 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726461AbgCINXc (ORCPT + 99 others); Mon, 9 Mar 2020 09:23:32 -0400 Received: from mail.kernel.org ([198.145.29.99]:39274 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726384AbgCINXc (ORCPT ); Mon, 9 Mar 2020 09:23:32 -0400 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 0861D20727; Mon, 9 Mar 2020 13:23:30 +0000 (UTC) Date: Mon, 9 Mar 2020 09:23:29 -0400 From: Steven Rostedt To: Tetsuo Handa Cc: Linus Torvalds , Greg Kroah-Hartman , Jiri Slaby , Andrew Morton , Matthew Garrett , Andi Kleen , "Theodore Y . Ts'o" , Alexander Viro , Petr Mladek , Sergey Senozhatsky , Arnd Bergmann , LKML , Dmitry Vyukov Subject: Re: [PATCH v2] Add kernel config option for fuzz testing. Message-ID: <20200309092329.04962c9c@gandalf.local.home> In-Reply-To: <3ee9c586-002b-f504-9e3b-5afa8929209b@i-love.sakura.ne.jp> References: <20200307135822.3894-1-penguin-kernel@I-love.SAKURA.ne.jp> <6f2e27de-c820-7de3-447d-cd9f7c650add@suse.com> <20200308065258.GE3983392@kroah.com> <3ee9c586-002b-f504-9e3b-5afa8929209b@i-love.sakura.ne.jp> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 9 Mar 2020 20:22:47 +0900 Tetsuo Handa wrote: > I think that locking down individual thing using individual switch is an > endless game of maintaining list of switches. When someone adds a code > which should not be fuzzed, the author of that code or the maintainer of > fuzzers will add a new switch for that code, and the maintainer of fuzzers > forever has to follow new switches. I think that it is better to keep number > of switches minimal until we have to split into fine grained switches. Can't we add a "TESTING" or "FUZZING" lockdown switch, that keeps root from executing things that shouldn't be fuzzed? I highly doubt that a kernel developer would even think "this shouldn't be fuzzed" when adding something. It's going to first be reported by the fuzz testing anyway. Don't just push the burden to the kernel developers. -- Steve