linux-kernel - Re: Rust kernel policy

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: <CAADnVQ+cX_oH_0GcdYkixrMxyvwAKrvSnzx1uofD3BM2E+L6eg@mail.gmail.com>
Date: Thu, 20 Feb 2025 10:40:32 -0800
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Christoph Hellwig <hch@...radead.org>
Cc: Jiri Kosina <jikos@...nel.org>, Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, 
	rust-for-linux <rust-for-linux@...r.kernel.org>, 
	Linus Torvalds <torvalds@...ux-foundation.org>, Greg KH <gregkh@...uxfoundation.org>, 
	David Airlie <airlied@...il.com>, LKML <linux-kernel@...r.kernel.org>, 
	ksummit@...ts.linux.dev
Subject: Re: Rust kernel policy

On Wed, Feb 19, 2025 at 10:33 PM Christoph Hellwig <hch@...radead.org> wrote:
>
> On Tue, Feb 18, 2025 at 06:36:55PM +0100, Jiri Kosina wrote:
> > > [2] The idea of drivers in eBPF as done by HID also really doesn't help
> > > with that as much as I like eBPF for some use cases
> >
> > I don't necessarily agree on this specific aspect, but what (at least to
> > me personally) is the crucial point here -- if we at some point decide
> > that HID-eBPF is somehow potentially unhealthy for the project /
> > ecosystem, we can just drop it and convert the existing eBPF snippets to a
> > proper simple HID bus drivers trivially (I'd even dare to say that to some
> > extent perhaps programatically).
>
> Well, Linus declared any bpf kfunc / helper program type change that
> breaks userspace as a no-go.  And such a change very much does.

Have to chime in into this rust thread to correct the facts.

See the doc:
https://github.com/torvalds/linux/blob/master/Documentation/bpf/kfuncs.rst#3-kfunc-lifecycle-expectations
TLDR:
"A kfunc will never have any hard stability guarantees. BPF APIs
cannot and will not ever hard-block a change in the kernel..."

git log proves the history of changing/removing kfuncs.

hid-bpf iself is another example of that policy.
It was redesigned from one way of hooking into hid core to
a completely different approach.
It may happen again, if necessary.