LWN: Comments on "In a bind with binder"

In a bind with binder

aahlawat — Fri, 27 Mar 2015 01:47:01 +0000

This article mentions that Binder "has known security problems when used outside of the tightly controlled Android setting, and more.".

Can anyone elaborate what these problems are and what tight control Android puts in place to mitigate these problems ?

In a bind with binder

error27 — Wed, 05 Nov 2014 10:59:16 +0000

The binder devs are fairly unresponsive. It's not hard to create documentation. You could write half arsed documentation in one afternoon.

I have seen other maintainers where you say "Your code is ugly. Look at this function everything about it is horrible. The rest of your code is the same." They fix the one function and leave everything else the same. If you keep sending half arsed patches to fix review comments then we eventually just merge your code even when we aren't 100% happy.

The binder devs could have fixed up the binder ioctl to use proper return codes. That would take 10 minutes of work and it fixes a specific problem that I complained about.

Instead of that they are all "No, you need to merge it as-is because we aren't going to lift a finger to fix anything." What about when it has real bugs?

In a bind with binder

HIGHGuY — Fri, 31 Oct 2014 11:50:41 +0000

Given that the staging tree comes with "warranty void if seal broken" marks, should ABI be maintained for staging code?

In my view, moving something out of staging comes down to: this code works properly, has sane design, sane ABI and semantics and doesn't give readers spontaneous thirst for the strongest liquors around... Or perhaps in k-dev speak: we're now committed to the ABI.

I'd say the simplest example would be the removal of logger - this is an ABI break. So, putting things together: if there are known issues with the thing, should the kernel really start committing to not breaking or fixing the code?

In a bind with binder

arnd — Thu, 30 Oct 2014 12:57:51 +0000

I guess from the Android side that would be mostly a matter of timing. The 5.0 release presumably changed a lot of things, and removing the logger was one of them. Replacing binder with something else won't realistically happen before Android 6.0, whenever that may be.

In a bind with binder

moltonel — Thu, 30 Oct 2014 12:04:30 +0000

In don't understand why what is done with logger (stop using it in android, and then remove it from vanilla entirely) can't be done with binder ? If kdbus can eventually replace binder, then leave binder in staging for now as Google's problem, and then remove it. Promoting binder from stagging to mainline today would probably make it harder to get rid of tomorrow, even if android stops using it ?

BeOS?

tialaramex — Thu, 30 Oct 2014 09:12:58 +0000

"Android's binder [...] first shown up as part of the BeOS system"

I can't find any evidence that this is true in a meaningful sense. It's correct that people behind Binder (and thus OpenBinder) worked at Be Inc. but if Binder was part of that work it seems to have never shipped to end users.

It is of course hard to prove a negative. Little pieces of binder might be present, undocumented and largely unused, in BeOS R5 without anybody knowing. But certainly if it's there its presence was so unfelt that BeOS clone project Haiku (once OpenBeOS) has nothing resembling binder nor any indication that it thinks such a thing is needed or desired.

Some documents assert that Binder was the IPC mechanism in BeOS. In fact BeOS IPC is an asynchronous message passing system built around the BMessage type-length-value flattened data structure - it has little surface resemblance to Binder's synchronous local procedure calls.

The next item in Binder's history is PalmOS. That's huge, a well-loved product on handheld devices. Except, it's referring to PalmOS Cobalt (6.0). That's the version developed by Palm spin-out Palm Source, and not only was it not successful as an independent venture - Cobalt was never even used on Palm's own hardware, maybe Binder made it awesome, maybe it was a disaster, end users will never be able to try it for themselves.

It seems to me as though somebody successfully painted Binder as a project with a real world pedigree when in fact, for all the enthusiasm of its developers, Android was actually the first time it was used in anger in a consumer product. That certainly makes it easier to understand how it shipped while still "horrible" and "broken by design".