netdev - Re: [PATCH bpf v2 1/2] bpf: Forbid bpf_ktime_get_coarse_ns and bpf_timer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87o86k6ep0.ffs@tglx>
Date:   Tue, 16 Nov 2021 03:02:03 +0100
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Dmitrii Banshchikov <me@...que.spb.ru>, bpf@...r.kernel.org
Cc:     Dmitrii Banshchikov <me@...que.spb.ru>, ast@...nel.org,
        daniel@...earbox.net, andrii@...nel.org, kafai@...com,
        songliubraving@...com, yhs@...com, john.fastabend@...il.com,
        kpsingh@...nel.org, netdev@...r.kernel.org, rdna@...com,
        syzbot+43fd005b5a1b4d10781e@...kaller.appspotmail.com
Subject: Re: [PATCH bpf v2 1/2] bpf: Forbid bpf_ktime_get_coarse_ns and
 bpf_timer_* in tracing progs

Dmitrii.

On Sat, Nov 13 2021 at 18:22, Dmitrii Banshchikov wrote:
> Use of bpf_ktime_get_coarse_ns() and bpf_timer_* helpers in tracing
> progs may result in locking issues.

"may result in locking issues"? There is no 'may'. This is simply a matter
of fact that this can and will result in deadlocks. Please spell it out.

It's a bug, so what. Why do you need to whitewash it?
.
> @@ -4632,6 +4632,9 @@ union bpf_attr {
>   * 		system boot, in nanoseconds. Does not include time the system
>   * 		was suspended.
>   *
> + *		Tracing programs cannot use **bpf_ktime_get_coarse_ns**\() (but
> + *		this may change in the future).

Sorry no. This is a bug fix and there is no place for 'may change in the
future' nonsense. It's simply not possible right now and unless you have
a plan to make this work backed up by actual patches this comment is
worse than wishful thinking.

> + *
>   * 		See: **clock_gettime**\ (**CLOCK_MONOTONIC_COARSE**)
>   * 	Return
>   * 		Current *ktime*.
> @@ -4804,6 +4807,9 @@ union bpf_attr {
>   *		All other bits of *flags* are reserved.
>   *		The verifier will reject the program if *timer* is not from
>   *		the same *map*.
> + *
> + *		Tracing programs cannot use **bpf_timer_init**\() (but this may
> + *		change in the future).

This is even worse than the above because it cannot happen ever. Please
stop this nonsensical wishful thinking crap. It does not add any value,
it just adds confusion.

Timers will have to take spinlocks no matter what even if the kernel has
been reimplemented in BPF someday. Tracing happens at any arbitrary
place which includes places inisde locked sections. So what are you
hallucinating about?

I completely understand that you are all enthused about the "unlimited"
power of BPF, but please take a step back and understand that BPF has
very well defined limitations as any other instrumentation facility has.

That said, I agree with the code changes but I vehemently NAK comments
which are built on wishful thinking or worse.

Thanks,

        tglx