[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ArOl6I7GkZ912O0tP7uFPe5JRJTftclvQHVtSHw0hsmxk5IJXexp9M3zQPefcGCXcx27lzX7A1s74XFa9gXEA5yRA5hC1BaNqhD7QgN3JRo=@protonmail.ch>
Date: Wed, 04 Oct 2017 14:58:31 -0400
From: Jordan Glover <Golden_Miller83@...tonmail.ch>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: "Tobin C. Harding" <me@...in.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>, Catalin Marinas <catalin.marinas@....com>, Will Deacon <will.deacon@....com>, Steven Rostedt <rostedt@...dmis.org>, William Roberts <william.c.roberts@...el.com>, Chris Fries <cfries@...gle.com>, Dave Weinstein <olorin@...gle.com>
Subject: Re: [RFC V2 0/6] add more kernel pointer filter options
If we knew where those leaks are hiding they will be fixed already. The only thing we knew is that bugs/leaks are there. It's always better to just fix all the code but it isn't realistic. That's what 25 years of kernel development teaches us. Proactive defense is imperfect, obscure, sometimes ugly but it's often best option we have which buy us more time for fixing actual bugs/leaks. Being honest to our users we can't pretend that kernel code is bug/leakfree. They deserve something better.
Yours sincerely,
Jordan
> -------- Original Message --------
> Subject: Re: [kernel-hardening] [RFC V2 0/6] add more kernel pointer filter options
> Local Time: October 4, 2017 3:41 PM
> UTC Time: October 4, 2017 3:41 PM
> From: torvalds@...ux-foundation.org
> To: Tobin C. Harding <me@...in.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>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Catalin Marinas <catalin.marinas@....com>, Will Deacon <will.deacon@....com>, Steven Rostedt <rostedt@...dmis.org>, William Roberts <william.c.roberts@...el.com>, Chris Fries <cfries@...gle.com>, Dave Weinstein <olorin@...gle.com>
>
> On Sat, Sep 30, 2017 at 5:06 PM, Tobin C. Harding <me@...in.cc> wrote:
>> lib: vsprintf: default kptr_restrict to the maximum value
>
> So I"m not convinced about this one.
>
> It removes kernel pointers even for root, which is annoying for things
> like perf.
>
> And the only physical pointers we should print out during boot etc are
> things we *need*.
>
> So kptr_restrict is wrong for that, bercause either we potentially
> need those values for debugging ("why does my kernel not boot"), or
> they shouldn"t be printed at all.
>
> And I think _that_ is the real issue. If there are places that leak,
> we should look at those, rather than just say "kptr_restrict".
>
> Linus
Content of type "text/html" skipped
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.
