On Thu, 26 Jul 2018 09:32:07 -0700 Nick Desaulniers ndesaulniers@google.com wrote:
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?
Is that what governs the output of kallsyms?
-- Steve