[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5j+R0-_k0jWHMWxxytEUgmJDxKyifjj5gC13dMebSLQ3Vw@mail.gmail.com>
Date: Wed, 4 Oct 2017 17:35:42 -0700
From: Kees Cook <keescook@...omium.org>
To: Daniel Micay <danielmicay@...il.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
"Roberts, William C" <william.c.roberts@...el.com>, Tejun Heo <tj@...nel.org>,
Jordan Glover <Golden_Miller83@...tonmail.ch>, "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>, Chris Fries <cfries@...gle.com>,
Dave Weinstein <olorin@...gle.com>
Subject: Re: [RFC V2 0/6] add more kernel pointer filter options
On Wed, Oct 4, 2017 at 5:29 PM, Daniel Micay <danielmicay@...il.com> wrote:
> On Wed, 2017-10-04 at 16:52 -0700, Linus Torvalds wrote:
>> On Wed, Oct 4, 2017 at 2:58 PM, Roberts, William C
>> <william.c.roberts@...el.com> wrote:
>> >
>> > I agree with you 100% kptr restrict is odd, and I don't think anyone
>> > should have had to opt in to be
>> > cleansed via kptr_restrict value via %pK. Opt-in never works. One
>> > nice thing now, is that checkpatch
>> > has checking of %p usages and warns.
>>
>> Yeah, the checkpatch thing may help for future patches.
>>
>> > As far as broken things, I can't comment on desktop systems where I
>> > think it's harder to make that claim.
>> > I see value in embedded systems where I am shipping the whole image,
>> > So I know when/what will
>> > break.
>> >
>> > If this was in-tree, Android would be setting this to 4 immediately
>> > FWIW.
>>
>> Does android set it to 2 right now?
>
> Yes, as the universal baseline.
>
> On Google Pixels it's set to this 4 level since August (Android 8.0)
> which indicates they plan on moving to that universally.
Yup, which is what triggered working to upstream a solution. (As
mentioned in the changelogs, this series has gone through a number of
hands including Intel and Google folks.)
> They only allow dmesg access for core system services so I think their
> concern is with formatted strings leaking it elsewhere, not to dmesg.
One of the paths is via seq_file and it's many outputs in procfs,
debugfs, etc etc. The %x issue exists there too, but it's relatively
rare compared to %p and family.
Just looking at the %p case, an alternative might be to follow
grsecurity's method here, which is to examine where v*printf is
writing. They perform the censorship in the case of seq_file buffers,
or memory destined for userspace.
-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.
