On Thu, Jul 26, 2018 at 8:22 AM Steven Rostedt rostedt@goodmis.org wrote:
On Thu, 26 Jul 2018 08:14:08 -0700 Mark Salyzyn salyzyn@android.com wrote:
Thank you Steve, much appreciated feedback, I have asked the security developers to keep this in mind and come up with a correct fix.
The correct fix that meets your guidelines would _not_ be suitable for stable due to the invasiveness it sounds, only for the latest will such a rework make sense. As such, the fix proposed in this patch is the only one that meets the bar for stable patch simplicity, and merely(!) needs to state that if the fix is taken, perf and trace are broken.
Posting this patch publicly on the lists, that may never be applied, may be the limit of our responsibility for a fix to stable kernel releases, to be optionally applied by vendors concerned with this CVE criteria?
The patch breaks the code it touches. It makes it useless.
Doesn't that depend on kptr_restrict, or would it be broken if kptr_restrict was set to 0?
If you want something for stable, add a command line parameter that just disables the creation of that file. Otherwise you will break usespace and that will be a definitely NAK from Linus, and for stable itself. This is a very minor security issue, and does not justify breaking userspace applications. I would be very upset if a new stable release broke both perf and trace-cmd's ability to read certain trace events.
I don't disagree.