Re: [PATCH v2] tracing: Add test for user space strings when filtering on string pointers

[Steven Rostedt]

On Wed, 12 Jan 2022 12:13:03 +0800
Pingfan Liu <kernelfans@xxxxxxxxx> wrote:

> Hi Steven,
> 
> Sorry that I am out of office, and not reply in time.

And I've been very sick for the last few days :-p

> 
> On Mon, Jan 10, 2022 at 12:24:36PM -0500, Steven Rostedt wrote:
> > On Mon, 10 Jan 2022 17:11:52 +0000
> > David Laight <David.Laight@xxxxxxxxxx> wrote:
> >   
> > > From: Steven Rostedt  
> > > > Sent: 10 January 2022 16:56
> > > > 
> > > > From: Steven Rostedt <rostedt@xxxxxxxxxxx>
> > > > 
> > > > Pingfan reported that the following causes a fault:
> > > > 
> > > >   echo "filename ~ \"cpu\"" > events/syscalls/sys_enter_openat/filter
> > > >   echo 1 > events/syscalls/sys_enter_at/enable
> > > > 
> > > > The reason is that trace event filter treats the user space pointer
> > > > defined by "filename" as a normal pointer to compare against the "cpu"
> > > > string. If the string is not loaded into memory yet, it will trigger a
> > > > fault in kernel space:    
> 
> For accurate commit log, the swapped-out user page is not the root cause
> of this bug is "supervisor read access in kernel mode". And it is trueth
> that swapped-out user page can trigger a bug here, but it should be a
> different a stack.

Yeah, it's true that the bug that triggered is the supervisor access, but
that's more of a security concern (and an option that triggers this, to
find bugs of this kind :-)  To me, the real bug is the random read of a
pointer. I can update the change log to be a bit more specific.

> 
> > > 
> > > If a userspace pointer can end up the kernel structure then presumably
> > > a 'dodgy' user program can supply an arbitrary kernel address instead?
> > > This may give the user the ability to read arbitrary kernel addresses
> > > (including ones that are mapped to PCIe IO addresses).
> > > Doesn't sound good at all.  
> > 
> > Only root has access to the information read here. All tracing requires
> > root or those explicitly given access to the tracing data, which pretty
> > much allows all access to kernel internals (including all memory). So
> > nothing to worry about here ;-)
> >   
> 
> I am not sure about the opposite way. Since kernel is not allowed to
> access userspace most of the time, then is it an leakage, which looks
> like:
>     use tracepoint as trampoline to uaccess.
>     read out user info from ustring_per_cpu
> 
> But any kernel code can call copy_from_user() function family freely, so
> it is not a problem caused by this patch, right? Or ustring_per_cpu
> should be zeroed out.

And you can use tracing to create a kprobe that can read user space at
almost any place in the kernel. Hence, we have API that allows root to do
this, which is why I'm not concerned about it.

> 
> For V2, feel free to add "Tested-by"
> 
> 

Thanks,

-- Steve