Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1028416imm; Thu, 31 May 2018 13:53:04 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJqiAA78c+sTPzcy91jJROe/wg7D4SzZso3Rw1q+2P2BweAJSgKDpjYvnFI4g9gvqq21gMQ X-Received: by 2002:a17:902:8f93:: with SMTP id z19-v6mr8301164plo.166.1527799984496; Thu, 31 May 2018 13:53:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527799984; cv=none; d=google.com; s=arc-20160816; b=oWXOH07SE9Ugwo0SN6ZrIs9a6Ymc+YprQVFiEMP/hWiEKg1uW/aRmsKcvgM0Xa1tC1 /V07vmav/82QKAm9KfNNFsfQ3yAClpsQ6A2XaVQdjuW5IX+b9MtJGE2QtXXQoBEJ74/B m0zLlOr/5b/fWqitAjJkMGG5R7B9DkByyZ5pFyIjdaUWaCdXwipSAPmH3GxosnA/bn2B a4swm3h9ajSceTSKmpyEYrrKC3v8RfvIyu4sfgIS2mHcIfVzcseghuecfauqjHUXSdvs VMwG4ji/tWcxtuGXtCAFhk6ofYqBU1RaPlKQ9f9QK9OqTmQoC4sDmWNU6v5AwYIszUxq /0Zg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:from:cc:to:subject :content-transfer-encoding:mime-version:references:in-reply-to :user-agent:date:arc-authentication-results; bh=fknIZ5nohT4lgPaxAHkA/VE6i1q/iajfLL2gbYQo1Us=; b=ro+mpdi0x1au6UUtyVGoYgCHOoQ7xF1lMut5NKKyDnN8UIFtshbRiuSgM++pyKHccs SEfk3Sa9J3H0RQwhBJDh4b6PCqvVj5BQd27UiGMx0epaLjtYVfvEyAkO3q1xWy2FjXA/ zM/ZW7UHE3AEYP4NGbHeL/u2w0kIjSYh9gyaxPdTBeXIG0QyPCiFO5NOIbC2kf2yZvQj BInP0ZqmMFrVuXiTOdAO+ydJjqZ96HFDE9buEBUOzj3uSPC+P/aKWJXwT58s+gxnV5Cq KzBK0CXS75vDh1LM0p1uaebgAerNPV0KqO5hDzep0UPm7UJxv7rw5EwGF2qaliUTNafe qfOw== 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 l4-v6si38087913plb.213.2018.05.31.13.52.49; Thu, 31 May 2018 13:53:04 -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 S1754695AbeEaUus convert rfc822-to-8bit (ORCPT + 99 others); Thu, 31 May 2018 16:50:48 -0400 Received: from terminus.zytor.com ([198.137.202.136]:42099 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754434AbeEaUuh (ORCPT ); Thu, 31 May 2018 16:50:37 -0400 Received: from HyperionMobile (108-226-165-29.lightspeed.sntcca.sbcglobal.net [108.226.165.29]) (authenticated bits=0) by mail.zytor.com (8.15.2/8.15.2) with ESMTPSA id w4VKoUth3709872 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 31 May 2018 13:50:31 -0700 Date: Thu, 31 May 2018 13:50:23 -0700 User-Agent: K-9 Mail for Android In-Reply-To: References: <1527789525-8857-1-git-send-email-chang.seok.bae@intel.com> <1527789525-8857-7-git-send-email-chang.seok.bae@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Subject: Re: [PATCH V2 06/15] taint: Add taint for insecure To: Andy Lutomirski , "Bae, Chang Seok" CC: Andrew Lutomirski , Thomas Gleixner , Ingo Molnar , Andi Kleen , Dave Hansen , "Metzger, Markus T" , "Ravi V. Shankar" , LKML From: hpa@zytor.com Message-ID: <60869EFF-9C2E-4415-B538-0826FA26B698@zytor.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On May 31, 2018 1:25:39 PM PDT, Andy Lutomirski wrote: >On Thu, May 31, 2018 at 10:58 AM Chang S. Bae > wrote: >> >> When adding new feature support, patches need to be >> incrementally applied and tested with temporal parameters. >> For such testing (or root-only) purposes, the new flag >> will serve to tag the kernel taint state properly. > >I'm okay with this, I guess, but I'm not at all convinced we need it. This was my idea. It isn't the only thing that may want it, and I think it is critical that we give the system a way to flag that the system contains experimental code that is known to break security. Sometimes that kind of experimental code is useful (I have written some myself, e.g. to treat SMAP), but it is a good idea to be able to flag such a kernel permanently, even if it's a module that can be removed. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.