Kernel prepatch 4.1-rc1

Posted Apr 29, 2015 22:57 UTC (Wed) by cesarb (subscriber, #6266)
In reply to: Kernel prepatch 4.1-rc1 by mbt
Parent article: Kernel prepatch 4.1-rc1

> I am indeed looking to the known facts while trying to uncover what appears to be a hidden agenda. So if D-Bus itself already offers a way to avoid GPL violations, my suggested explanation goes away. That leaves me casting around for other explanations. [...] I'm left wondering why kdbus is so important.

I recalled the true reason for kdbus *not* being performance, but I couldn't recall precisely what it was (something related to containers IIRC), so I went back to one of its initial announcements, and here's what I found (https://lwn.net/Articles/580194/):

> Beyond that, credential passing is limited, there are no timestamps on messages, D-Bus is not available at early boot, connections to security frameworks (e.g. SELinux) must happen in user space, and there are race conditions around the activation of services.

This old presentation I found (https://archive.fosdem.org/2014/schedule/event/anatomy_of...) goes into more detail.

Kernel prepatch 4.1-rc1

Posted Apr 29, 2015 23:47 UTC (Wed) by dlang (guest, #313) [Link] (2 responses)

kdbus doesn't have any connections to security frameworks (dbus does at this point, so this is actually a regression)

As far as race conditions go, examples please? the one provided on the discussion says that services must not exit if there are any outstanding messages to be delivered to them and that's racy today. This seems like the wrong way to do things (want to prevent a service from updating to a new, more secure config, keep sending it messages)

why can dbus not start from initramfs? we've moved so many functions out of the kernel into initramfs, why is dbus more significant than RAID configuration?

Kernel prepatch 4.1-rc1

Posted Apr 30, 2015 1:10 UTC (Thu) by cesarb (subscriber, #6266) [Link] (1 responses)

> As far as race conditions go, examples please?

From what I understood, if I am recalling it correctly, the race condition was with inetd-style activation of dbus services. Something like:

1. The monitor process receives a message for the service, and spawns the service daemon.
2. The monitor process hands over the bus endpoint to the service, so any further messages go to the service daemon.
3. The service has been idle for a while, and decides to exit.
4. The monitor process notices that the service has exited, and starts monitoring the endpoint again.

Between 3 and 4, any messages sent to the service get lost.

Kernel prepatch 4.1-rc1

Posted Apr 30, 2015 1:32 UTC (Thu) by dlang (guest, #313) [Link]

if there is guaranteed delivery, why would the routing process not detect
that the message it sent to the service didn't get acknoledged?

what happens if the process dies instead of processing the message?

how does the kernel close this race? the kernel is not going to be starting
services and doing the other work that you describe the monitor process
doing.