Date: Wed, 04 Oct 2017 20:29:15 -0400 From: Daniel Micay <danielmicay@...il.com> To: Linus Torvalds <torvalds@...ux-foundation.org>, "Roberts, William C" <william.c.roberts@...el.com>, Tejun Heo <tj@...nel.org> Cc: 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, 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. They only allow dmesg access for core system services so I think their concern is with formatted strings leaking it elsewhere, not to dmesg. These are the only services they allow to read dmesg: private/system_server.te: allow system_server kernel:system syslog_read; public/dumpstate.te:allow dumpstate kernel:system syslog_read; public/init.te:allow init kernel:system syslog_read; public/logd.te:allow logd kernel:system syslog_read; public/recovery.te: allow recovery kernel:system syslog_read; logd doesn't read it in production builds, but even when it does in engineering builds it only gives out access to privileged apps with READ_LOGS which isn't something a third party app can obtain.
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.