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.