netdev - Re: pull-request: bpf-next 2023-12-18

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: <20231220-einfiel-narkose-72cf400ae7e6@brauner>
Date: Wed, 20 Dec 2023 12:18:03 +0100
From: Christian Brauner <brauner@...nel.org>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: Linus Torvalds <torvalds@...uxfoundation.org>,
	Andrii Nakryiko <andrii@...nel.org>,
	Jakub Kicinski <kuba@...nel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
	Daniel Borkmann <daniel@...earbox.net>,
	Peter Zijlstra <peterz@...radead.org>,
	Network Development <netdev@...r.kernel.org>,
	bpf <bpf@...r.kernel.org>, Kernel Team <kernel-team@...com>,
	Linux-Fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: pull-request: bpf-next 2023-12-18

> The patch 4 that does:
> if (attr->map_token_fd)
> wasn't sneaked in in any way.
> You were cc-ed on it just like linux-fsdevel@...r
> during all 12 revisions of the token series over many months.
> 
> So this accusation of breach of trust is baseless.

I was expecting this reply and I'm still disappointed.

Both of you were explicitly told in very clear words that special-casing
fd 0 is not ok.

Fast forward a few weeks, you chose to not just add patches that forbid
fd 0 again, no, the heinous part is that you chose to not lose a single
word about this: not in the cover letter, not in the relevant commit,
not in all the discussions we had around this.

You were absolutely aware how opposed we are to this. It cannot get any
more sneaky than this. And it's frankly insulting that you choose to
defend this by feigning ignorance. No one is buying this.

But let's assume for a second that both you and Andrii somehow managed
to forget the very clear and heated discussion on-list last time, the
resulting LWN article written about it and the in-person discussion
around this we had in November at LPC.

You still would have put a major deviation from file descriptor
semantics in the bpf specific parts of the patches yet failed to lose a
single word on this anywhere. Yet we explicitly requested in the last
thread that if bpf does deviate from core fs semantics you clearly
communicate this.

But shame on me as well. I should've caught this during review. I
trusted you both enough that I only focussed on the parts that matter
for the VFS which were the two patches I ACKed. I didn't think it
necessary to wade through the completely uninteresting BPF bits that I
couldn't care less about. That won't happen again.

What I want for the future is for bpf to clearly, openly, and explicitly
communicate any decisions that affect core fs semantics. It's the exact
same request I put forward last time. This is a path forward.