From: Jason Yan <yanaijie@huawei.com>
To: Kees Cook <keescook@chromium.org>
Cc: Jann Horn <jannh@google.com>,
Kernel Hardening <kernel-hardening@lists.openwall.com>,
zhaohongjiang@huawei.com, miaoxie@huawei.com,
Li Bin <huawei.libin@huawei.com>,
Wei Yongjun <weiyongjun1@huawei.com>
Subject: Re: [PATCH] usercopy: skip the check if not a real usercopy
Date: Fri, 11 Jan 2019 09:52:54 +0800 [thread overview]
Message-ID: <5C37F6F6.3030605@huawei.com> (raw)
In-Reply-To: <CAGXu5jKsj+_O-NAATco6Ln6DLdcA+BC8_zd9DVfLNRa3jL+E=w@mail.gmail.com>
On 2019/1/10 6:59, Kees Cook wrote:
> On Tue, Jan 8, 2019 at 6:26 PM Jason Yan <yanaijie@huawei.com> wrote:
>> It's very easy to reproduce in qemu using my config with v4.20. Please
>> refer to the attachment.
>>
>> I did some debug and found that check_object_size() did not stuck but
>> check_object_size() sometimes takes more than 30 milliseconds, and
>> ftrace will call __probe_kernel_write() thousands of times, which makes
>> the whole process stuck for more than 20 seconds.
>
> 30ms is still WAY too long. :)
>
>> [yanaijie@138 linux]$ ./scripts/faddr2line vmlinux
>> __check_object_size+0x5/0x460
>> __check_object_size+0x5/0x460:
>> __check_object_size at mm/usercopy.c:254
>> [yanaijie@138 linux]$
>
> For me, that's the entry to __check_object_size (the line with "{").
> Is that what you see too?
>
Yes, this is different every time, so it's just because there is too
many loops outside to call this function?
> Perhaps this is poor interaction with tracing? Does marking
> __check_object_size with "notrace" help?
>
I will try this later.
next prev parent reply other threads:[~2019-01-11 1:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-02 9:31 [PATCH] usercopy: skip the check if not a real usercopy Jason Yan
2019-01-02 16:11 ` Casey Schaufler
2019-01-03 9:36 ` Jann Horn
2019-01-08 23:54 ` Kees Cook
2019-01-09 2:26 ` Jason Yan
2019-01-09 2:38 ` Jason Yan
2019-01-09 22:59 ` Kees Cook
2019-01-11 1:52 ` Jason Yan [this message]
2019-01-09 0:48 ` Jann Horn
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=5C37F6F6.3030605@huawei.com \
--to=yanaijie@huawei.com \
--cc=huawei.libin@huawei.com \
--cc=jannh@google.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=miaoxie@huawei.com \
--cc=weiyongjun1@huawei.com \
--cc=zhaohongjiang@huawei.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.