From: Nicolai Stange <nicstange@gmail.com>
To: Kees Cook <keescook@chromium.org>
Cc: Nicolai Stange <nicstange@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Sasha Levin <sasha.levin@oracle.com>,
Andrew Morton <akpm@linux-foundation.org>,
Dmitry Vyukov <dvyukov@google.com>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
James Morse <james.morse@arm.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] kernel/kcov: unproxify debugfs file's fops
Date: Tue, 24 May 2016 14:07:47 +0200 [thread overview]
Message-ID: <87twhnek18.fsf@gmail.com> (raw)
In-Reply-To: <CAGXu5jJ-nagcd5qYcpYT9KUvkFSPe1eJyHT0b3+xKk3HeBkd8g@mail.gmail.com> (Kees Cook's message of "Mon, 23 May 2016 11:00:09 -0700")
Kees Cook <keescook@chromium.org> writes:
> On Mon, May 23, 2016 at 6:45 AM, Nicolai Stange <nicstange@gmail.com> wrote:
>> Since commit 49d200deaa68 ("debugfs: prevent access to removed files'
>> private data"), a debugfs file's file_operations methods get proxied
>> through lifetime aware wrappers.
>>
>> However, only a certain subset of the file_operations members is supported
>> by debugfs and ->mmap isn't among them -- it appears to be NULL from the
>> VFS layer's perspective.
>>
>> This behaviour breaks the /sys/kernel/debug/kcov file introduced
>> concurrently with commit 5c9a8750a640 ("kernel: add kcov code coverage").
>>
>> Since that file never gets removed, there is no file removal race and thus,
>> a lifetime checking proxy isn't needed.
>>
>> Avoid the proxying for /sys/kernel/debug/kcov by creating it via
>> debugfs_create_file_unsafe() rather than debugfs_create_file().
>>
>> Fixes: 49d200deaa68 ("debugfs: prevent access to removed files' private
>> data")
>> Fixes: 5c9a8750a640 ("kernel: add kcov code coverage")
>> Signed-off-by: Nicolai Stange <nicstange@gmail.com>
>> ---
>> Applicable to linux-next 20160523.
>> In particular, it depends on
>> - c64688081490 ("debugfs: add support for self-protecting attribute file
>> fops")
>> - 5c9a8750a640 ("kernel: add kcov code coverage")
>>
>> This issue has been debugged and reported by
>> Sasha Levin <sasha.levin@oracle.com>:
>> http://lkml.kernel.org/g/573F4200.3080208@oracle.com
>>
>> kernel/kcov.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kernel/kcov.c b/kernel/kcov.c
>> index a02f2dd..4c349dd 100644
>> --- a/kernel/kcov.c
>> +++ b/kernel/kcov.c
>> @@ -264,7 +264,7 @@ static const struct file_operations kcov_fops = {
>>
>> static int __init kcov_init(void)
>> {
>> - if (!debugfs_create_file("kcov", 0600, NULL, NULL, &kcov_fops)) {
>> + if (!debugfs_create_file_unsafe("kcov", 0600, NULL, NULL, &kcov_fops)) {
>
> It might make sense to add a comment above this to describe why
> "unsafe" is not unsafe in this case.
Done. v2 can be found at
http://lkml.kernel.org/g/1464091505-20943-1-git-send-email-nicstange@gmail.com
Thanks,
Nicolai
>
> -Kees
>
>> pr_err("failed to create kcov in debugfs\n");
>> return -ENOMEM;
>> }
>> --
>> 2.8.2
>>
prev parent reply other threads:[~2016-05-24 12:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-23 13:45 [PATCH] kernel/kcov: unproxify debugfs file's fops Nicolai Stange
2016-05-23 18:00 ` Kees Cook
2016-05-24 12:07 ` Nicolai Stange [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87twhnek18.fsf@gmail.com \
--to=nicstange@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=aryabinin@virtuozzo.com \
--cc=dvyukov@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=james.morse@arm.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sasha.levin@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.