The C Binder driver exposes messages over netlink when transactions
fail, so that a userpace daemon can respond to processes with many
failing transactions.

This patch series adds netlink support from Rust, then implements an
equivalent API in Rust Binder.

As Binder only uses broadcast messages, I did not add support for other
kinds of messages.

Depends on:
https://lore.kernel.org/r/20260306-transaction-info-v1-1-fda58fca558b@google.com

Available in this branch:
https://github.com/Darksonn/linux/commits/b4/binder-netlink/

Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
Alice Ryhl (3):
      rust: netlink: add raw netlink abstraction
      ynl_gen: generate Rust files from yaml files
      rust_binder: add generated netlink.rs file

Carlos Llamas (1):
      rust_binder: report netlink transactions

 drivers/android/Kconfig                    |   2 +-
 drivers/android/binder/netlink.rs          | 113 ++++++++++++
 drivers/android/binder/rust_binder_main.rs |   8 +-
 drivers/android/binder/thread.rs           |   9 +
 drivers/android/binder/transaction.rs      |  38 ++++
 rust/bindings/bindings_helper.h            |   3 +
 rust/helpers/genetlink.c                   |  46 +++++
 rust/helpers/helpers.c                     |   1 +
 rust/kernel/lib.rs                         |   1 +
 rust/kernel/netlink.rs                     | 267 +++++++++++++++++++++++++++++
 rust/uapi/uapi_helper.h                    |   1 +
 tools/net/ynl/pyynl/ynl_gen_c.py           | 132 +++++++++++++-
 tools/net/ynl/ynl-regen.sh                 |   2 +-
 13 files changed, 618 insertions(+), 5 deletions(-)
---
base-commit: 3f9cd19e764b782706dbaacc69e502099cb014ba
change-id: 20260306-binder-netlink-c82110b2fb74
prerequisite-change-id: 20260305-transaction-info-62653c65f789:v1
prerequisite-patch-id: d324a8e3e611b7be5837cfb01c27625e657804c6

Best regards,
-- 
Alice Ryhl <aliceryhl@google.com>

On Fri, 06 Mar 2026 15:12:12 +0000 Alice Ryhl wrote:
> The C Binder driver exposes messages over netlink when transactions
> fail, so that a userpace daemon can respond to processes with many
> failing transactions.

Ugh, now I regret letting binder use Netlink. Should have seen this
coming :/

> This patch series adds netlink support from Rust, then implements an
> equivalent API in Rust Binder.
> 
> As Binder only uses broadcast messages, I did not add support for other
> kinds of messages.

Please no duplication of existing code in Rust.

On Sat, Mar 07, 2026 at 10:41:31AM -0800, Jakub Kicinski wrote:
> On Fri, 06 Mar 2026 15:12:12 +0000 Alice Ryhl wrote:
> > The C Binder driver exposes messages over netlink when transactions
> > fail, so that a userpace daemon can respond to processes with many
> > failing transactions.
> 
> Ugh, now I regret letting binder use Netlink. Should have seen this
> coming :/

To be honest, I'm not entirely happy with what Binder is using netlink
for either, but it is what it is.

> > This patch series adds netlink support from Rust, then implements an
> > equivalent API in Rust Binder.
> > 
> > As Binder only uses broadcast messages, I did not add support for other
> > kinds of messages.
> 
> Please no duplication of existing code in Rust.

The plan is certainly to get rid of C Binder, but it was unfortunately
not possible to get there without a transition period.

Alice

On Sat, 7 Mar 2026 21:19:06 +0000 Alice Ryhl wrote:
> On Sat, Mar 07, 2026 at 10:41:31AM -0800, Jakub Kicinski wrote:
> > On Fri, 06 Mar 2026 15:12:12 +0000 Alice Ryhl wrote:  
> > > The C Binder driver exposes messages over netlink when transactions
> > > fail, so that a userpace daemon can respond to processes with many
> > > failing transactions.  
> > 
> > Ugh, now I regret letting binder use Netlink. Should have seen this
> > coming :/  
> 
> To be honest, I'm not entirely happy with what Binder is using netlink
> for either, but it is what it is.

If we're both not happy let's take this opportunity to find a better
solution?

On Sat, Mar 07, 2026 at 01:59:41PM -0800, Jakub Kicinski wrote:
> On Sat, 7 Mar 2026 21:19:06 +0000 Alice Ryhl wrote:
> > On Sat, Mar 07, 2026 at 10:41:31AM -0800, Jakub Kicinski wrote:
> > > On Fri, 06 Mar 2026 15:12:12 +0000 Alice Ryhl wrote:  
> > > > The C Binder driver exposes messages over netlink when transactions
> > > > fail, so that a userpace daemon can respond to processes with many
> > > > failing transactions.  
> > > 
> > > Ugh, now I regret letting binder use Netlink. Should have seen this
> > > coming :/  
> > 
> > To be honest, I'm not entirely happy with what Binder is using netlink
> > for either, but it is what it is.
> 
> If we're both not happy let's take this opportunity to find a better
> solution?

My understanding is that userspace is already using or looking into
using the netlink uapi that Binder exposes here. I don't know to what
extent; it's not used *that* much yet, but it may still be tricky to
change the uapi at this point.

Alice

On Sat, 7 Mar 2026 22:50:31 +0000 Alice Ryhl wrote:
> > > To be honest, I'm not entirely happy with what Binder is using netlink
> > > for either, but it is what it is.  
> > 
> > If we're both not happy let's take this opportunity to find a better
> > solution?  
> 
> My understanding is that userspace is already using or looking into
> using the netlink uapi that Binder exposes here. I don't know to what
> extent; it's not used *that* much yet, but it may still be tricky to
> change the uapi at this point.

Let's explore it? What user space components would need to be updated?
What's a better design?

On Mon, Mar 09, 2026 at 02:24:00PM -0700, Jakub Kicinski wrote:
> On Sat, 7 Mar 2026 22:50:31 +0000 Alice Ryhl wrote:
> > > > To be honest, I'm not entirely happy with what Binder is using netlink
> > > > for either, but it is what it is.  
> > > 
> > > If we're both not happy let's take this opportunity to find a better
> > > solution?  
> > 
> > My understanding is that userspace is already using or looking into
> > using the netlink uapi that Binder exposes here. I don't know to what
> > extent; it's not used *that* much yet, but it may still be tricky to
> > change the uapi at this point.
> 
> Let's explore it? What user space components would need to be updated?
> What's a better design?

Well ... the thing I'm the most unhappy about is needing to have a
userspace daemon that is notified about all transaction failures to
begin with.

But if you must have such a daemon, I think the netlink based API is
an okay way to do it. You can easily add new fields in the future, and
it implements notifications to userspace on our behalf.

Though using raw pids in the netlink messages is pretty ugly ... pids
can change, and the pid namespace of the receiving proc ends up ignored.

Alice

> > Please no duplication of existing code in Rust.
> 
> The plan is certainly to get rid of C Binder, but it was unfortunately
> not possible to get there without a transition period.

Dumb question....

Why?

You are just sending messages to user space. Does the rust version
send different messages? Can user space tell the difference?

     Andrew

On Sat, Mar 07, 2026 at 10:39:28PM +0100, Andrew Lunn wrote:
> > > Please no duplication of existing code in Rust.
> > 
> > The plan is certainly to get rid of C Binder, but it was unfortunately
> > not possible to get there without a transition period.
> 
> Dumb question....
> 
> Why?

The reasons for moving to a Rust implementation are discussed in the
cover letter [1], and in my 2023 plumbers talk [2].

[1]: https://lore.kernel.org/all/20231101-rust-binder-v1-0-08ba9197f637@google.com/
[2]: https://www.youtube.com/watch?v=Kt3hpvMZv8o

> You are just sending messages to user space. Does the rust version
> send different messages? Can user space tell the difference?

No, it sends the same messages. The intent is for Android to move to the
Rust implementation without userspace being able to tell the difference.

Alice

On Sat, Mar 07, 2026 at 10:41:09PM +0000, Alice Ryhl wrote:
> On Sat, Mar 07, 2026 at 10:39:28PM +0100, Andrew Lunn wrote:
> > > > Please no duplication of existing code in Rust.
> > > 
> > > The plan is certainly to get rid of C Binder, but it was unfortunately
> > > not possible to get there without a transition period.
> > 
> > Dumb question....
> > 
> > Why?
> 
> The reasons for moving to a Rust implementation are discussed in the
> cover letter [1], and in my 2023 plumbers talk [2].

Ah, so you meant binder itself has be dual implementation for a while.

> No, it sends the same messages. The intent is for Android to move to the
> Rust implementation without userspace being able to tell the difference.

Any reason you cannot use this Rust netlink code with the C binder?
You can then throw away the C netlink code, no code duplication.

	Andrew

On Sun, Mar 08, 2026 at 03:12:55PM +0100, Andrew Lunn wrote:
> On Sat, Mar 07, 2026 at 10:41:09PM +0000, Alice Ryhl wrote:
> > On Sat, Mar 07, 2026 at 10:39:28PM +0100, Andrew Lunn wrote:
> > > > > Please no duplication of existing code in Rust.
> > > > 
> > > > The plan is certainly to get rid of C Binder, but it was unfortunately
> > > > not possible to get there without a transition period.
> > > 
> > > Dumb question....
> > > 
> > > Why?
> > 
> > The reasons for moving to a Rust implementation are discussed in the
> > cover letter [1], and in my 2023 plumbers talk [2].
> 
> Ah, so you meant binder itself has be dual implementation for a while.

Yes, that's right.

> > No, it sends the same messages. The intent is for Android to move to the
> > Rust implementation without userspace being able to tell the difference.
> 
> Any reason you cannot use this Rust netlink code with the C binder?
> You can then throw away the C netlink code, no code duplication.

I think the benefit from that would be quite little. It would probably
not have helped avoid commit 5e8a3d015442 ("binder: fix UAF in
binder_netlink_report()") because that was a bug in the caller of
binder_netlink_report(), rather than a bug in the function itself.

And as for the benefit from avoiding duplication on its own, Binder's
netlink logic is very small to begin with, so I do not think that's
worth it either. It'll go away eventually when the entire C driver is
deleted.

Alice