Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH] tracing: do not leak kernel addresses
To:     Steven Rostedt <rostedt@goodmis.org>
Cc:     linux-kernel@vger.kernel.org,
        Nick Desaulniers <ndesaulniers@google.com>,
        Ingo Molnar <mingo@redhat.com>, kernel-team@android.com,
        stable@vger.kernel.org
References: <20180725202238.165314-1-salyzyn@android.com>
 <20180725210717.3b807191@vmware.local.home>
From:   Mark Salyzyn <salyzyn@android.com>
Message-ID: <11437c3e-5131-7190-c496-7b51eb7fcc2a@android.com>
Date:   Thu, 26 Jul 2018 08:14:08 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <20180725210717.3b807191@vmware.local.home>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 07/25/2018 06:07 PM, Steven Rostedt wrote:
> On Wed, 25 Jul 2018 13:22:36 -0700
> Mark Salyzyn <salyzyn@android.com> wrote:
>
>> From: Nick Desaulniers <ndesaulniers@google.com>
>>
>> Switch from 0x%lx to 0x%pK to print the kernel addresses.
>>
>> Fixes: CVE-2017-0630
> Wait!!!! This breaks perf and trace-cmd! They require this to be able
> to print various strings in trace events. This file is root read only,
> as the CVE says.
>
> NAK for this fix. Come up with something that doesn't break perf and
> trace-cmd. That will not be trivial, as the format is stored in the
> ring buffer with an address, then referenced directly. It also handles
> trace_printk() functions that simply point to the string format itself.
>
> A fix would require having a pointer be the same that is referenced
> inside the kernel as well as in this file. Maybe make the format string
> placed in a location that doesn't leak where the rest of the kernel
> exists?
>
> -- Steve
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?

-- Mark