From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751317AbdJDQsM (ORCPT ); Wed, 4 Oct 2017 12:48:12 -0400 Received: from mga11.intel.com ([192.55.52.93]:19464 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750966AbdJDQsL (ORCPT ); Wed, 4 Oct 2017 12:48:11 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,478,1500966000"; d="scan'208";a="158824422" From: "Roberts, William C" To: Kees Cook , "Tobin C. Harding" CC: Greg KH , Petr Mladek , Joe Perches , Ian Campbell , "Sergey Senozhatsky" , "kernel-hardening@lists.openwall.com" , LKML , Catalin Marinas , Will Deacon , Steven Rostedt , Chris Fries , Dave Weinstein , Linus Torvalds Subject: RE: [kernel-hardening] [RFC V2 4/6] lib: vsprintf: default kptr_restrict to the maximum value Thread-Topic: [kernel-hardening] [RFC V2 4/6] lib: vsprintf: default kptr_restrict to the maximum value Thread-Index: AQHTPS/XT61GuGxZdEuuLOTMM40QX6LT5jFw Date: Wed, 4 Oct 2017 16:48:08 +0000 Message-ID: <476DC76E7D1DF2438D32BFADF679FC563EAF4D93@ORSMSX103.amr.corp.intel.com> References: <1506816410-10230-1-git-send-email-me@tobin.cc> <1506816410-10230-5-git-send-email-me@tobin.cc> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [10.22.254.138] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id v94GmGcE008908 > -----Original Message----- > From: keescook@google.com [mailto:keescook@google.com] On Behalf Of Kees > Cook > Sent: Wednesday, October 4, 2017 9:43 AM > To: Tobin C. Harding > Cc: Greg KH ; Petr Mladek ; > Joe Perches ; Ian Campbell ; Sergey > Senozhatsky ; kernel- > hardening@lists.openwall.com; LKML ; Catalin > Marinas ; Will Deacon ; > Steven Rostedt ; Roberts, William C > ; Chris Fries ; Dave Weinstein > ; Linus Torvalds > Subject: Re: [kernel-hardening] [RFC V2 4/6] lib: vsprintf: default kptr_restrict to > the maximum value > > On Sat, Sep 30, 2017 at 5:06 PM, Tobin C. Harding wrote: > > Set the initial value of kptr_restrict to the maximum setting rather > > than the minimum setting, to ensure that early boot logging is not > > leaking information. > > > > Signed-off-by: Tobin C. Harding > > --- > > lib/vsprintf.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/lib/vsprintf.c b/lib/vsprintf.c index 0271223..e009325 > > 100644 > > --- a/lib/vsprintf.c > > +++ b/lib/vsprintf.c > > @@ -396,7 +396,7 @@ struct printf_spec { #define FIELD_WIDTH_MAX ((1 > > << 23) - 1) #define PRECISION_MAX ((1 << 15) - 1) > > > > -int kptr_restrict __read_mostly; > > +int kptr_restrict __read_mostly = 4; /* maximum setting */ > > > > /* > > * return non-zero if we should cleanse pointers for %p and %pK specifiers. > > I share Linus's concern that making this the unconditional default will break some > people. The intention here (as stated in the > changelog) is to cover anything leaked during early boot before sysctl settings can > change this value. That shouldn't break perf (which should happen after sysctl > settings), but it _may_ break debugging of early boot. I would hope that nothing > would be needed there, but if we want to make this more configurable, we may > want to consider a Kconfig for the default. Perhaps: > > -int kptr_restrict __read_mostly; > +int kptr_restrict __read_mostly = CONFIG_KPTR_RESTRICT_DEFAULT; > > ... > > +config KPTR_RESTRICT_DEFAULT > + bool "Avoid leaking kernel pointers to userspace" > + default 0 > + range 0 4 > + help > + This specifies the initial value of the kptr_restrict sysctl, which > + controls the level of kernel pointers removed from display > + to userspace. 0 = off, 1 = %pK not visible to non-root, 2 = %pK > + not visible for any user, 3 = %p also not visible, 4 = physical and > + resource addresses also not visible. > > > I'd argue that a default of "1" would be a sensible starting place, but that can be a > separate patch, IMO. > I might be crazy, as often the case, but a command line option might be useful here so you can boot the same kernel with Kptr < 4 if you really need to get at any information hidden by a configure time value of 4. > -Kees > > -- > Kees Cook > Pixel Security