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: <45rpsr92-4416-9no4-8o26-r0998nr77nr8@xreary.bet>
Date: Tue, 18 Feb 2025 18:36:55 +0100 (CET)
From: Jiri Kosina <jikos@...nel.org>
To: Christoph Hellwig <hch@...radead.org>
cc: 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>, 
    linux-kernel@...r.kernel.org, ksummit@...ts.linux.dev
Subject: Re: Rust kernel policy

On Tue, 18 Feb 2025, Christoph Hellwig wrote:

> So we'll have these bindings creep everywhere like a cancer and are
> very quickly moving from a software project that allows for and strives
> for global changes that improve the overall project to increasing
> compartmentalization [2].
[ ... ]

> [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).

This is not growing anywhere beyond pretty much a few hooks to make 
writing HID-eBPF driver code more convenient compared to creating a 
full-fledged kernel one.

It's mostly useful for quick-turnaround debugging with users who are not 
generally capable of compiling kernel modules / applying patches to test 
fixes, although the usage is admittedly slightly expanding beyond that.

To me that's something completely different than making changes (or 
bindings, "ABI stability contracts", or however we want to call it) that 
are pretty much impossible to revert, because everything quickly becomes 
depending on the new core code.

-- 
Jiri Kosina
SUSE Labs