Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1403047 > unrolled thread

Re: [PATCH v6 2/8] debugfs: prevent access to removed files' private data

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v6 2/8] debugfs: prevent access to removed files' private  data Sasha Levin <sasha.levin@oracle.com> - 2016-05-18 16:50 +0200
    Re: [PATCH v6 2/8] debugfs: prevent access to removed files' private data Nicolai Stange <nicstange@gmail.com> - 2016-05-18 17:10 +0200
      Re: [PATCH v6 2/8] debugfs: prevent access to removed files' private  data Sasha Levin <sasha.levin@oracle.com> - 2016-05-18 17:20 +0200
        Re: [PATCH v6 2/8] debugfs: prevent access to removed files' private  data Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-18 18:10 +0200
          Re: [PATCH v6 2/8] debugfs: prevent access to removed files' private  data Sasha Levin <sasha.levin@oracle.com> - 2016-05-20 19:00 +0200
            Re: [PATCH v6 2/8] debugfs: prevent access to removed files' private data Nicolai Stange <nicstange@gmail.com> - 2016-05-21 20:00 +0200
              Re: [PATCH v6 2/8] debugfs: prevent access to removed files' private data Nicolai Stange <nicstange@gmail.com> - 2016-05-22 15:30 +0200
        Re: [PATCH v6 2/8] debugfs: prevent access to removed files' private data Nicolai Stange <nicstange@gmail.com> - 2016-05-18 18:40 +0200
          Re: [PATCH v6 2/8] debugfs: prevent access to removed files' private  data Sasha Levin <sasha.levin@oracle.com> - 2016-05-20 19:00 +0200

#1403047 — Re: [PATCH v6 2/8] debugfs: prevent access to removed files' private data

On 03/22/2016 09:11 AM, Nicolai Stange wrote:
> Upon return of debugfs_remove()/debugfs_remove_recursive(), it might
> still be attempted to access associated private file data through
> previously opened struct file objects. If that data has been freed by
> the caller of debugfs_remove*() in the meanwhile, the reading/writing
> process would either encounter a fault or, if the memory address in
> question has been reassigned again, unrelated data structures could get
> overwritten.
> 
> However, since debugfs files are seldomly removed, usually from module
> exit handlers only, the impact is very low.
> 
> Currently, there are ~1000 call sites of debugfs_create_file() spread
> throughout the whole tree and touching all of those struct file_operations
> in order to make them file removal aware by means of checking the result of
> debugfs_use_file_start() from within their methods is unfeasible.
> 
> Instead, wrap the struct file_operations by a lifetime managing proxy at
> file open:
> - In debugfs_create_file(), the original fops handed in has got stashed
>   away in ->d_fsdata already.
> - In debugfs_create_file(), install a proxy file_operations factory,
>   debugfs_full_proxy_file_operations, at ->i_fop.
> 
> This proxy factory has got an ->open() method only. It carries out some
> lifetime checks and if successful, dynamically allocates and sets up a new
> struct file_operations proxy at ->f_op. Afterwards, it forwards to the
> ->open() of the original struct file_operations in ->d_fsdata, if any.
> 
> The dynamically set up proxy at ->f_op has got a lifetime managing wrapper
> set for each of the methods defined in the original struct file_operations
> in ->d_fsdata.
> 
> Its ->release()er frees the proxy again and forwards to the original
> ->release(), if any.
> 
> In order not to mislead the VFS layer, it is strictly necessary to leave
> those fields blank in the proxy that have been NULL in the original
> struct file_operations also, i.e. aren't supported. This is why there is a
> need for dynamically allocated proxies. The choice made not to allocate a
> proxy instance for every dentry at file creation, but for every
> struct file object instantiated thereof is justified by the expected usage
> pattern of debugfs, namely that in general very few files get opened more
> than once at a time.
> 
> The wrapper methods set in the struct file_operations implement lifetime
> managing by means of the SRCU protection facilities already in place for
> debugfs:
> They set up a SRCU read side critical section and check whether the dentry
> is still alive by means of debugfs_use_file_start(). If so, they forward
> the call to the original struct file_operation stored in ->d_fsdata, still
> under the protection of the SRCU read side critical section.
> This SRCU read side critical section prevents any pending debugfs_remove()
> and friends to return to their callers. Since a file's private data must
> only be freed after the return of debugfs_remove(), the ongoing proxied
> call is guarded against any file removal race.
> 
> If, on the other hand, the initial call to debugfs_use_file_start() detects
> that the dentry is dead, the wrapper simply returns -EIO and does not
> forward the call. Note that the ->poll() wrapper is special in that its
> signature does not allow for the return of arbitrary -EXXX values and thus,
> POLLHUP is returned here.
> 
> In order not to pollute debugfs with wrapper definitions that aren't ever
> needed, I chose not to define a wrapper for every struct file_operations
> method possible. Instead, a wrapper is defined only for the subset of
> methods which are actually set by any debugfs users.
> Currently, these are:
> 
>   ->llseek()
>   ->read()
>   ->write()
>   ->unlocked_ioctl()
>   ->poll()
> 
> The ->release() wrapper is special in that it does not protect the original
> ->release() in any way from dead files in order not to leak resources.
> Thus, any ->release() handed to debugfs must implement file lifetime
> management manually, if needed.
> For only 33 out of a total of 434 releasers handed in to debugfs, it could
> not be verified immediately whether they access data structures that might
> have been freed upon a debugfs_remove() return in the meanwhile.
> 
> Export debugfs_use_file_start() and debugfs_use_file_finish() in order to
> allow any ->release() to manually implement file lifetime management.
> 
> For a set of common cases of struct file_operations implemented by the
> debugfs_core itself, future patches will incorporate file lifetime
> management directly within those in order to allow for their unproxied
> operation. Rename the original, non-proxying "debugfs_create_file()" to
> "debugfs_create_file_unsafe()" and keep it for future internal use by
> debugfs itself. Factor out code common to both into the new
> __debugfs_create_file().
> 
> Signed-off-by: Nicolai Stange <nicstange@gmail.com>

Hey,

I'm seeing a hang on boot which was bisected (twice) to this commit. I don't
see any lockup messages, but everything just seems to stop.


Thanks,
Sasha

[toc] | [next] | [standalone]

#1403068 — Re: [PATCH v6 2/8] debugfs: prevent access to removed files' private data

Hi Sasha,

Sasha Levin <sasha.levin@oracle.com> writes:

> On 03/22/2016 09:11 AM, Nicolai Stange wrote:
>> Upon return of debugfs_remove()/debugfs_remove_recursive(), it might
>> still be attempted to access associated private file data through
>> previously opened struct file objects. If that data has been freed by
>> the caller of debugfs_remove*() in the meanwhile, the reading/writing
>> process would either encounter a fault or, if the memory address in
>> question has been reassigned again, unrelated data structures could get
>> overwritten.
>> 
>> However, since debugfs files are seldomly removed, usually from module
>> exit handlers only, the impact is very low.
>> 
>> Currently, there are ~1000 call sites of debugfs_create_file() spread
>> throughout the whole tree and touching all of those struct file_operations
>> in order to make them file removal aware by means of checking the result of
>> debugfs_use_file_start() from within their methods is unfeasible.
>> 
>> Instead, wrap the struct file_operations by a lifetime managing proxy at
>> file open:
>> - In debugfs_create_file(), the original fops handed in has got stashed
>>   away in ->d_fsdata already.
>> - In debugfs_create_file(), install a proxy file_operations factory,
>>   debugfs_full_proxy_file_operations, at ->i_fop.
>> 
>> This proxy factory has got an ->open() method only. It carries out some
>> lifetime checks and if successful, dynamically allocates and sets up a new
>> struct file_operations proxy at ->f_op. Afterwards, it forwards to the
>> ->open() of the original struct file_operations in ->d_fsdata, if any.
>> 
>> The dynamically set up proxy at ->f_op has got a lifetime managing wrapper
>> set for each of the methods defined in the original struct file_operations
>> in ->d_fsdata.
>> 
>> Its ->release()er frees the proxy again and forwards to the original
>> ->release(), if any.
>> 
>> In order not to mislead the VFS layer, it is strictly necessary to leave
>> those fields blank in the proxy that have been NULL in the original
>> struct file_operations also, i.e. aren't supported. This is why there is a
>> need for dynamically allocated proxies. The choice made not to allocate a
>> proxy instance for every dentry at file creation, but for every
>> struct file object instantiated thereof is justified by the expected usage
>> pattern of debugfs, namely that in general very few files get opened more
>> than once at a time.
>> 
>> The wrapper methods set in the struct file_operations implement lifetime
>> managing by means of the SRCU protection facilities already in place for
>> debugfs:
>> They set up a SRCU read side critical section and check whether the dentry
>> is still alive by means of debugfs_use_file_start(). If so, they forward
>> the call to the original struct file_operation stored in ->d_fsdata, still
>> under the protection of the SRCU read side critical section.
>> This SRCU read side critical section prevents any pending debugfs_remove()
>> and friends to return to their callers. Since a file's private data must
>> only be freed after the return of debugfs_remove(), the ongoing proxied
>> call is guarded against any file removal race.
>> 
>> If, on the other hand, the initial call to debugfs_use_file_start() detects
>> that the dentry is dead, the wrapper simply returns -EIO and does not
>> forward the call. Note that the ->poll() wrapper is special in that its
>> signature does not allow for the return of arbitrary -EXXX values and thus,
>> POLLHUP is returned here.
>> 
>> In order not to pollute debugfs with wrapper definitions that aren't ever
>> needed, I chose not to define a wrapper for every struct file_operations
>> method possible. Instead, a wrapper is defined only for the subset of
>> methods which are actually set by any debugfs users.
>> Currently, these are:
>> 
>>   ->llseek()
>>   ->read()
>>   ->write()
>>   ->unlocked_ioctl()
>>   ->poll()
>> 
>> The ->release() wrapper is special in that it does not protect the original
>> ->release() in any way from dead files in order not to leak resources.
>> Thus, any ->release() handed to debugfs must implement file lifetime
>> management manually, if needed.
>> For only 33 out of a total of 434 releasers handed in to debugfs, it could
>> not be verified immediately whether they access data structures that might
>> have been freed upon a debugfs_remove() return in the meanwhile.
>> 
>> Export debugfs_use_file_start() and debugfs_use_file_finish() in order to
>> allow any ->release() to manually implement file lifetime management.
>> 
>> For a set of common cases of struct file_operations implemented by the
>> debugfs_core itself, future patches will incorporate file lifetime
>> management directly within those in order to allow for their unproxied
>> operation. Rename the original, non-proxying "debugfs_create_file()" to
>> "debugfs_create_file_unsafe()" and keep it for future internal use by
>> debugfs itself. Factor out code common to both into the new
>> __debugfs_create_file().
>> 
>> Signed-off-by: Nicolai Stange <nicstange@gmail.com>

Thanks a million for reporting!

1.) Do you have lockdep enabled?

2.) Does this happen before or after userspace init has been spawned,
    i.e. does the lockup happen at debugfs file creation time or
    possibly at usage time?

Thank you,

Nicolai

[toc] | [prev] | [next] | [standalone]

#1403080

On 05/18/2016 11:01 AM, Nicolai Stange wrote:
> Thanks a million for reporting!
> 
> 1.) Do you have lockdep enabled?

Yup, nothing there.

> 2.) Does this happen before or after userspace init has been spawned,
>     i.e. does the lockup happen at debugfs file creation time or
>     possibly at usage time?

So I looked closer, and it seems to happen after starting syzkaller, which
as far as I know tries to open many different debugfs files.

Is there debug code I can add it that'll help us figure out what's up?


Thanks,
Sasha

[toc] | [prev] | [next] | [standalone]

#1403117

On Wed, May 18, 2016 at 11:18:16AM -0400, Sasha Levin wrote:
> On 05/18/2016 11:01 AM, Nicolai Stange wrote:
> > Thanks a million for reporting!
> > 
> > 1.) Do you have lockdep enabled?
> 
> Yup, nothing there.
> 
> > 2.) Does this happen before or after userspace init has been spawned,
> >     i.e. does the lockup happen at debugfs file creation time or
> >     possibly at usage time?
> 
> So I looked closer, and it seems to happen after starting syzkaller, which
> as far as I know tries to open many different debugfs files.
> 
> Is there debug code I can add it that'll help us figure out what's up?

Trying to figure out _which_ debugfs file is causing this would be
great, if at all possible.  strace?

[toc] | [prev] | [next] | [standalone]

#1404616

On 05/18/2016 12:05 PM, Greg Kroah-Hartman wrote:
> On Wed, May 18, 2016 at 11:18:16AM -0400, Sasha Levin wrote:
>> On 05/18/2016 11:01 AM, Nicolai Stange wrote:
>>> Thanks a million for reporting!
>>>
>>> 1.) Do you have lockdep enabled?
>>
>> Yup, nothing there.
>>
>>> 2.) Does this happen before or after userspace init has been spawned,
>>>     i.e. does the lockup happen at debugfs file creation time or
>>>     possibly at usage time?
>>
>> So I looked closer, and it seems to happen after starting syzkaller, which
>> as far as I know tries to open many different debugfs files.
>>
>> Is there debug code I can add it that'll help us figure out what's up?
> 
> Trying to figure out _which_ debugfs file is causing this would be
> great, if at all possible.  strace?

What seems to be failing is syzkaller's attempt to mmap the coverage
debugfs file. So this isn't actually a kernel deadlock but syzkaller
misbehaves when that scenario happens.

Either way, it only fails to mmap with that commit that I've pointed
out.

	th->cover_fd = open("/sys/kernel/debug/kcov", O_RDWR);
	if (th->cover_fd == -1)
		fail("open of /sys/kernel/debug/kcov failed");
	if (ioctl(th->cover_fd, KCOV_INIT_TRACE, kCoverSize))
		fail("cover enable write failed");
	th->cover_data = (uintptr_t*)mmap(NULL, kCoverSize * sizeof(th->cover_data[0]), PROT_READ | PROT_WRITE, MAP_SHARED, th->cover_fd, 0);
	if ((void*)th->cover_data == MAP_FAILED)
		fail("cover mmap failed");

And it's the mmap() that fails with -ENODEV.


Thanks,
Sasha

[toc] | [prev] | [next] | [standalone]

#1404876 — Re: [PATCH v6 2/8] debugfs: prevent access to removed files' private data

Sasha Levin <sasha.levin@oracle.com> writes:

> On 05/18/2016 12:05 PM, Greg Kroah-Hartman wrote:
>> On Wed, May 18, 2016 at 11:18:16AM -0400, Sasha Levin wrote:
>>> On 05/18/2016 11:01 AM, Nicolai Stange wrote:
>>>> Thanks a million for reporting!
>>>>
>>>> 1.) Do you have lockdep enabled?
>>>
>>> Yup, nothing there.
>>>
>>>> 2.) Does this happen before or after userspace init has been spawned,
>>>>     i.e. does the lockup happen at debugfs file creation time or
>>>>     possibly at usage time?
>>>
>>> So I looked closer, and it seems to happen after starting syzkaller, which
>>> as far as I know tries to open many different debugfs files.
>>>
>>> Is there debug code I can add it that'll help us figure out what's up?
>> 
>> Trying to figure out _which_ debugfs file is causing this would be
>> great, if at all possible.  strace?
>
> What seems to be failing is syzkaller's attempt to mmap the coverage
> debugfs file. So this isn't actually a kernel deadlock but syzkaller
> misbehaves when that scenario happens.
>
> Either way, it only fails to mmap with that commit that I've pointed
> out.

That info is really helpful here: the proxy file_operations introduced by
this commit doesn't have a ->mmap() defined, i.e. it is NULL from the
VFS layer's point of view.

The simple reason is that at the time I submitted this series, my
Coccinelle script didn't find any debugfs user with a ->mmap()
defined. Thus either that script was broken or things have changed in
the meanwhile.

I'll look into this tomorrow.

Thank you very much for the effort you put into this!

>
> 	th->cover_fd = open("/sys/kernel/debug/kcov", O_RDWR);
> 	if (th->cover_fd == -1)
> 		fail("open of /sys/kernel/debug/kcov failed");
> 	if (ioctl(th->cover_fd, KCOV_INIT_TRACE, kCoverSize))
> 		fail("cover enable write failed");
> 	th->cover_data = (uintptr_t*)mmap(NULL, kCoverSize * sizeof(th->cover_data[0]), PROT_READ | PROT_WRITE, MAP_SHARED, th->cover_fd, 0);
> 	if ((void*)th->cover_data == MAP_FAILED)
> 		fail("cover mmap failed");
>
> And it's the mmap() that fails with -ENODEV.

[toc] | [prev] | [next] | [standalone]

#1405006 — Re: [PATCH v6 2/8] debugfs: prevent access to removed files' private data

[Multipart message — attachments visible in raw view] — view raw

Nicolai Stange <nicstange@gmail.com> writes:

> Sasha Levin <sasha.levin@oracle.com> writes:
>
>> On 05/18/2016 12:05 PM, Greg Kroah-Hartman wrote:
>>> On Wed, May 18, 2016 at 11:18:16AM -0400, Sasha Levin wrote:
>>>> On 05/18/2016 11:01 AM, Nicolai Stange wrote:
>>>>> Thanks a million for reporting!
>>>>>
>>>>> 1.) Do you have lockdep enabled?
>>>>
>>>> Yup, nothing there.
>>>>
>>>>> 2.) Does this happen before or after userspace init has been spawned,
>>>>>     i.e. does the lockup happen at debugfs file creation time or
>>>>>     possibly at usage time?
>>>>
>>>> So I looked closer, and it seems to happen after starting syzkaller, which
>>>> as far as I know tries to open many different debugfs files.
>>>>
>>>> Is there debug code I can add it that'll help us figure out what's up?
>>> 
>>> Trying to figure out _which_ debugfs file is causing this would be
>>> great, if at all possible.  strace?
>>
>> What seems to be failing is syzkaller's attempt to mmap the coverage
>> debugfs file. So this isn't actually a kernel deadlock but syzkaller
>> misbehaves when that scenario happens.
>>
>> Either way, it only fails to mmap with that commit that I've pointed
>> out.
>
> That info is really helpful here: the proxy file_operations introduced by
> this commit doesn't have a ->mmap() defined, i.e. it is NULL from the
> VFS layer's point of view.
>
> The simple reason is that at the time I submitted this series, my
> Coccinelle script didn't find any debugfs user with a ->mmap()
> defined. Thus either that script was broken or things have changed in
> the meanwhile.

Thankfully, it's the latter :)
See the attached cocci script I used back then.

It now reports:

  ./drivers/staging/android/sync_debug.c:330:1-20: unsupported file_operations given to debugfs
  ./kernel/kcov.c:267:6-25: unsupported file_operations given to debugfs

The kcov's ->mmap() has been introduced by

  5c9a8750a640 ("kernel: add kcov code coverage")

dated from March this year.

Since that kcov debugfs file is never removed, it needs no protecting
proxy and thus, a replacement of debugfs_create_file() by
debugfs_create_file_unsafe() will do the trick here.

I'll send patches addressing the above two issues.

>>
>> 	th->cover_fd = open("/sys/kernel/debug/kcov", O_RDWR);
>> 	if (th->cover_fd == -1)
>> 		fail("open of /sys/kernel/debug/kcov failed");
>> 	if (ioctl(th->cover_fd, KCOV_INIT_TRACE, kCoverSize))
>> 		fail("cover enable write failed");
>> 	th->cover_data = (uintptr_t*)mmap(NULL, kCoverSize * sizeof(th->cover_data[0]), PROT_READ | PROT_WRITE, MAP_SHARED, th->cover_fd, 0);
>> 	if ((void*)th->cover_data == MAP_FAILED)
>> 		fail("cover mmap failed");
>>
>> And it's the mmap() that fails with -ENODEV.

[toc] | [prev] | [next] | [standalone]

#1403141 — Re: [PATCH v6 2/8] debugfs: prevent access to removed files' private data

Sasha Levin <sasha.levin@oracle.com> writes:

> On 05/18/2016 11:01 AM, Nicolai Stange wrote:
>> Thanks a million for reporting!
>> 
>> 1.) Do you have lockdep enabled?
>
> Yup, nothing there.
>
>> 2.) Does this happen before or after userspace init has been spawned,
>>     i.e. does the lockup happen at debugfs file creation time or
>>     possibly at usage time?
>
> So I looked closer, and it seems to happen after starting syzkaller, which
> as far as I know tries to open many different debugfs files.
>
> Is there debug code I can add it that'll help us figure out what's up?

Could you try the patch below? I stared at the new full_proxy_open() for
a while now and had to recognize the fact that if the original real_fops'
->open() fails, then its owning module's reference won't ever get
dropped :(

diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index 6eb58a8..2e663d4 100644
--- a/fs/debugfs/file.c
+++ b/fs/debugfs/file.c
@@ -263,10 +263,14 @@ static int full_proxy_open(struct inode *inode, struct file *filp)
        if (real_fops->open) {
                r = real_fops->open(inode, filp);

-               if (filp->f_op != proxy_fops) {
+               if (r) {
+                       replace_fops(filp, d_inode(dentry)->i_fop);
+                       goto free_proxy;
+               } else if (filp->f_op != proxy_fops) {
                        /* No protection against file removal anymore. */
                        WARN(1, "debugfs file owner replaced proxy fops: %pd",
                                dentry);
+                       replace_fops(filp, d_inode(dentry)->i_fop);
                        goto free_proxy;
                }
        }


I don't see directly how this could lead to lockups, but I think it's
better to rule out the obvious before inserting more or less random
printks...

Thank you very much again,

Nicolai

[toc] | [prev] | [next] | [standalone]

#1404613

On 05/18/2016 12:32 PM, Nicolai Stange wrote:
> Sasha Levin <sasha.levin@oracle.com> writes:
> 
>> On 05/18/2016 11:01 AM, Nicolai Stange wrote:
>>> Thanks a million for reporting!
>>>
>>> 1.) Do you have lockdep enabled?
>>
>> Yup, nothing there.
>>
>>> 2.) Does this happen before or after userspace init has been spawned,
>>>     i.e. does the lockup happen at debugfs file creation time or
>>>     possibly at usage time?
>>
>> So I looked closer, and it seems to happen after starting syzkaller, which
>> as far as I know tries to open many different debugfs files.
>>
>> Is there debug code I can add it that'll help us figure out what's up?
> 
> Could you try the patch below? I stared at the new full_proxy_open() for
> a while now and had to recognize the fact that if the original real_fops'
> ->open() fails, then its owning module's reference won't ever get
> dropped :(
> 
> diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
> index 6eb58a8..2e663d4 100644
> --- a/fs/debugfs/file.c
> +++ b/fs/debugfs/file.c
> @@ -263,10 +263,14 @@ static int full_proxy_open(struct inode *inode, struct file *filp)
>         if (real_fops->open) {
>                 r = real_fops->open(inode, filp);
> 
> -               if (filp->f_op != proxy_fops) {
> +               if (r) {
> +                       replace_fops(filp, d_inode(dentry)->i_fop);
> +                       goto free_proxy;
> +               } else if (filp->f_op != proxy_fops) {
>                         /* No protection against file removal anymore. */
>                         WARN(1, "debugfs file owner replaced proxy fops: %pd",
>                                 dentry);
> +                       replace_fops(filp, d_inode(dentry)->i_fop);
>                         goto free_proxy;
>                 }
>         }
> 
> 
> I don't see directly how this could lead to lockups, but I think it's
> better to rule out the obvious before inserting more or less random
> printks...
> 
> Thank you very much again,

Nope, that didn't do the trick.


Thanks,
Sasha

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web