Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1756621AbcJGOVM (ORCPT <rfc822;w@1wt.eu>);
        Fri, 7 Oct 2016 10:21:12 -0400
Received: from mga03.intel.com ([134.134.136.65]:15797 "EHLO mga03.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1753709AbcJGOVC (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 7 Oct 2016 10:21:02 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.31,308,1473145200"; 
   d="scan'208";a="1061793403"
From: "Roberts, William C" <william.c.roberts@intel.com>
To: Kees Cook <keescook@chromium.org>,
        Christoph Hellwig <hch@infradead.org>
CC: "kernel-hardening@lists.openwall.com" 
        <kernel-hardening@lists.openwall.com>,
        "corbet@lwn.net" <corbet@lwn.net>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] printk: introduce kptr_restrict level 3
Thread-Topic: [PATCH] printk: introduce kptr_restrict level 3
Thread-Index: AQHSHzL4SKECDv3ohUe9odM8/3/liaCb4uuA//+NOECAAHmaAIAAdpqAgACtGBA=
Date: Fri, 7 Oct 2016 14:21:01 +0000
Message-ID: <476DC76E7D1DF2438D32BFADF679FC561CD14B2A@ORSMSX103.amr.corp.intel.com>
References: <1475690686-16138-1-git-send-email-william.c.roberts@intel.com>
 <20161006133147.GA20206@infradead.org>
 <476DC76E7D1DF2438D32BFADF679FC561CD14651@ORSMSX103.amr.corp.intel.com>
 <20161006135612.GA21342@infradead.org>
 <CAGXu5jJsj=4=j1R6aUYiDvdWqY916pJbBdXCEbQFFoyQ0QP4Yw@mail.gmail.com>
In-Reply-To: <CAGXu5jJsj=4=j1R6aUYiDvdWqY916pJbBdXCEbQFFoyQ0QP4Yw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiM2IyNTMwM2MtNmY1Ny00MDA1LTlhN2MtOGE5ODJkY2EzOWUyIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IkUyUFZIamVjQlFcL2docHMwXC9Wa0t3elpuYTBHTjQrdmc5TTNkd3ZnUFo1OD0ifQ==
x-ctpclassification: CTP_IC
x-originating-ip: [10.22.254.140]
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u97ELHsl025315
Content-Length: 985
Lines: 24

<snip>

> 
> As a _singlular_ argument, "it's for out-of-tree code" is weak. As an _additional_
> argument, it has value. Saying "this only helps out-of-tree code" doesn't carry
> much weight. Saying "this helps kernel security, even for out-of-tree code" is
> perfectly valid. And a wrinkle in this is that some day, either that out-of-tree
> code, or brand new code, will land in the kernel, and we don't want to continue
> to require authors be aware of an opt-in security feature. The kernel should
> protect itself (and all of itself, including out-of-tree or future code) by default.
> 

I should have made this more clear in my message, this was in my head and I assumed
that people would just get it. But I shouldn't have made such an assumption.

> And based on my read of this thread, we all appear to be in violent agreement. :)
> "always protect %p" is absolutely the goal, and we can figure out the best way to
> get there.
> 
> -Kees
> 
> --
> Kees Cook
> Nexus Security