From: "zhujianwei (C)" <zhujianwei7@huawei.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: "Kees Cook" <keescook@chromium.org>,
"bpf@vger.kernel.org" <bpf@vger.kernel.org>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>,
Hehuazhen <hehuazhen@huawei.com>,
"Lennart Poettering" <lennart@poettering.net>,
"Christian Ehrhardt" <christian.ehrhardt@canonical.com>,
"Zbigniew Jędrzejewski-Szmek" <zbyszek@in.waw.pl>
Subject: 答复: 答复: new seccomp mode aims to improve performance
Date: Tue, 2 Jun 2020 11:13:00 +0000 [thread overview]
Message-ID: <717a06e7f35740ccb4c70470ec70fb2f@huawei.com> (raw)
In-Reply-To: <20200602032446.7sn2fmzsea2v2wbs@ast-mbp.dhcp.thefacebook.com>
> > This is the test result on linux 5.7.0-rc7 for aarch64.
> > And retpoline disabled default.
> > #cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
> > Not affected
> >
> > bpf_jit_enable 1
> > bpf_jit_harden 0
> >
> > We run unixbench syscall benchmark on the original kernel and the new one(replace bpf_prog_run_pin_on_cpu() with immediately returning 'allow' one).
> > The unixbench syscall testcase runs 5 system calls(close/umask/dup/getpid/getuid, extra 15 syscalls needed to run it) in a loop for 10 seconds, counts the number and finally output it. We also add some more filters (each with the same rules) to evaluate the situation just like kees mentioned(case like systemd-resolve), and we find it is right: more filters, more overhead. The following is our result (./syscall 10 m):
> >
> > original:
> > seccomp_off: 10684939
> > seccomp_on_1_filters: 8513805 overhead:19.8%
> > seccomp_on_4_filters: 7105592 overhead:33.0%
> > seccomp_on_32_filters: 2308677 overhead:78.3%
> >
> > after replacing bpf_prog_run_pin_on_cpu:
> > seccomp_off: 10685244
> > seccomp_on_1_filters: 9146483 overhead:14.1%
> > seccomp_on_4_filters: 8969886 overhead:16.0%
> > seccomp_on_32_filters: 6454372 overhead:39.6%
> >
> > N-filter bpf overhead:
> > 1_filters: 5.7%
> > 4_filters: 17.0%
> > 32_filters: 38.7%
> >
> > // kernel code modification place
> > static noinline u32 bpf_prog_run_pin_on_cpu_allow(const struct
> > bpf_prog *prog, const void *ctx) {
> > return SECCOMP_RET_ALLOW;
> > }
>
> >This is apples to oranges.
> >As explained earlier:
> >https://lore.kernel.org/netdev/20200531171915.wsxvdjeetmhpsdv2@ast-mb
> >p.dhcp.thefacebook.com/T/#u Please use __weak instead of static and
> >redo the numbers.
>
>
> we have replaced ‘static’ with ‘__weak’, tested with the same way, and got almostly the same result, in our test environment(aarch64).
>
> -static noinline u32 bpf_prog_run_pin_on_cpu_allow(const struct
> bpf_prog *prog, const void *ctx)
> +__weak noinline u32 bpf_prog_run_pin_on_cpu_allow(const struct
> +bpf_prog *prog, const void *ctx)
>
> original:
> seccomp_off: 10684939
> seccomp_on_1_filters: 8513805 overhead:19.8%
> seccomp_on_4_filters: 7105592 overhead:33.0%
> seccomp_on_32_filters: 2308677 overhead:78.3%
>
> after replacing bpf_prog_run_pin_on_cpu:
> seccomp_off: 10667195
> seccomp_on_1_filters: 9147454 overhead:14.2%
> seccomp_on_4_filters: 8927605 overhead:16.1%
> seccomp_on_32_filters: 6355476 overhead:40.6%
> are you saying that by replacing 'static' with '__weak' it got slower?!
> Something doesn't add up. Please check generated assembly.
> By having such 'static noinline bpf_prog_run_pin_on_cpu' you're telling compiler to remove most of seccomp_run_filters() code which now will return only two possible values. Which further means that large 'switch'
> statement in __seccomp_filter() is also optimized. populate_seccomp_data() is removed. Etc, etc. That explains 14% vs 19% difference.
> May be you have some debug on? Like cant_migrate() is not a nop?
> Or static_branch is not supported?
> The sure way is to check assembly.
No, we say that by replacing 'static' with '__weak' it got the same result, in our testcase which filters 20 allowed syscall num (for details, see the previous post).
static case:
N-filter bpf overhead:
1_filters: 5.7%
4_filters: 17.0%
32_filters: 38.7%
__weak case:
N-filter bpf overhead:
1_filters: 5.6%
4_filters: 16.9%
32_filters: 37.7%
next prev parent reply other threads:[~2020-06-02 11:13 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-29 12:48 new seccomp mode aims to improve performance zhujianwei (C)
2020-05-29 15:43 ` Alexei Starovoitov
2020-05-29 16:09 ` Kees Cook
2020-05-29 17:31 ` Alexei Starovoitov
2020-05-29 19:27 ` Kees Cook
2020-05-31 17:19 ` Alexei Starovoitov
2020-06-01 18:16 ` Kees Cook
2020-06-01 2:08 ` 答复: " zhujianwei (C)
2020-06-01 3:30 ` Alexei Starovoitov
2020-06-02 2:42 ` 答复: " zhujianwei (C)
2020-06-02 3:24 ` Alexei Starovoitov
2020-06-02 11:13 ` zhujianwei (C) [this message]
2020-06-02 11:34 ` 答复: " zhujianwei (C)
2020-06-02 18:32 ` Kees Cook
2020-06-03 4:51 ` 答复: " zhujianwei (C)
2020-06-01 10:11 ` Lennart Poettering
2020-06-01 12:32 ` Paul Moore
2020-06-02 12:53 ` Lennart Poettering
2020-06-02 15:03 ` Paul Moore
2020-06-02 18:39 ` Kees Cook
2020-06-01 18:21 ` Kees Cook
2020-06-02 12:44 ` Lennart Poettering
2020-06-02 18:37 ` Kees Cook
2020-06-16 6:00 ` Kees Cook
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=717a06e7f35740ccb4c70470ec70fb2f@huawei.com \
--to=zhujianwei7@huawei.com \
--cc=alexei.starovoitov@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=christian.ehrhardt@canonical.com \
--cc=hehuazhen@huawei.com \
--cc=keescook@chromium.org \
--cc=lennart@poettering.net \
--cc=linux-security-module@vger.kernel.org \
--cc=zbyszek@in.waw.pl \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).