[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <476DC76E7D1DF2438D32BFADF679FC563EAF4D93@ORSMSX103.amr.corp.intel.com>
Date: Wed, 4 Oct 2017 16:48:08 +0000
From: "Roberts, William C" <william.c.roberts@...el.com>
To: Kees Cook <keescook@...omium.org>, "Tobin C. Harding" <me@...in.cc>
CC: Greg KH <gregkh@...uxfoundation.org>, Petr Mladek <pmladek@...e.com>, Joe
Perches <joe@...ches.com>, Ian Campbell <ijc@...lion.org.uk>, "Sergey
Senozhatsky" <sergey.senozhatsky@...il.com>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
LKML <linux-kernel@...r.kernel.org>, Catalin Marinas
<catalin.marinas@....com>, Will Deacon <will.deacon@....com>, Steven Rostedt
<rostedt@...dmis.org>, Chris Fries <cfries@...gle.com>, Dave Weinstein
<olorin@...gle.com>, Linus Torvalds <torvalds@...ux-foundation.org>
Subject: RE: [RFC V2 4/6] lib: vsprintf: default
kptr_restrict to the maximum value
> -----Original Message-----
> From: keescook@...gle.com [mailto:keescook@...gle.com] On Behalf Of Kees
> Cook
> Sent: Wednesday, October 4, 2017 9:43 AM
> To: Tobin C. Harding <me@...in.cc>
> Cc: Greg KH <gregkh@...uxfoundation.org>; Petr Mladek <pmladek@...e.com>;
> Joe Perches <joe@...ches.com>; Ian Campbell <ijc@...lion.org.uk>; Sergey
> Senozhatsky <sergey.senozhatsky@...il.com>; kernel-
> hardening@...ts.openwall.com; LKML <linux-kernel@...r.kernel.org>; Catalin
> Marinas <catalin.marinas@....com>; Will Deacon <will.deacon@....com>;
> Steven Rostedt <rostedt@...dmis.org>; Roberts, William C
> <william.c.roberts@...el.com>; Chris Fries <cfries@...gle.com>; Dave Weinstein
> <olorin@...gle.com>; Linus Torvalds <torvalds@...ux-foundation.org>
> 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 <me@...in.cc> 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 <me@...in.cc>
> > ---
> > 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
