lkml.org 
[lkml]   [2015]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH 01/13] kdbus: add documentation
On Tue, Feb 3, 2015 at 2:09 AM, Daniel Mack <daniel@zonque.org> wrote:
> Hi Andy,
>
> On 02/02/2015 09:12 PM, Andy Lutomirski wrote:
>> On Feb 2, 2015 1:34 AM, "Daniel Mack" <daniel@zonque.org> wrote:
>
>>> That's right, but again - if an application wants to gather this kind of
>>> information about tasks it interacts with, it can do so today by looking
>>> at /proc or similar sources. Desktop machines do exactly that already,
>>> and the kernel code executed in such cases very much resembles that in
>>> metadata.c, and is certainly not cheaper. kdbus just makes such
>>> information more accessible when requested. Which information is
>>> collected is defined by bit-masks on both the sender and the receiver
>>> connection, and most applications will effectively only use a very
>>> limited set by default if they go through one of the more high-level
>>> libraries.
>>
>> I should rephrase a bit. Kdbus doesn't require use of send-time
>> metadata. It does, however, strongly encourage it, and it sounds like
>
> On the kernel level, kdbus just *offers* that, just like sockets offer
> SO_PASSCRED. On the userland level, kdbus helps applications get that
> information race-free, easier and faster than they would otherwise.
>
>> systemd and other major users will use send-time metadata. Once that
>> happens, it's ABI (even if it's purely in userspace), and changing it
>> is asking for security holes to pop up. So you'll be mostly stuck
>> with it.
>
> We know we can't break the ABI. At most, we could deprecate item types
> and introduce new ones, but we want to avoid that by all means of
> course. However, I fail to see how that is related to send time
> metadata, or even to kdbus in general, as all ABIs have to be kept stable.

I should have said it differently. ABI is the wrong term -- it's more
of a protocol issue.

It looks like, with the current code, the kernel will provide
(optional) send-time metadata, and the sd-bus library will use it.
The result will be that the communication protocol between clients and
udev, systemd, systemd-logind, g-s-d, etc, will likely involve
send-time metadata. This may end up being a bottleneck.

Once this happens, changing the protocol will be very hard without
introducing security bugs. If people start switching to
connection-time metadata to gain performance, then they'll break both
the communication protocol and the expectations of client code. (In
fact, it'll break twice, sort of, since I think that the current
protocols are connect-time.)

To me, this seems like a down-side of using send-time metadata, albeit
possibly not a huge downside at least in the near term. I don't see a
corresponding benefit, though.

>
>> Do you have some simple benchmark code you can share? I'd like to
>> play with it a bit.
>
> Sure, it's part of the self-test suite. Call it with "-t benchmark" to
> run the benchmark as isolated test with verbose output. The code for
> that lives in test-benchmark.c.
>

I'll try to play with this soon. Thanks.

--Andy

>
> Thanks,
> Daniel
>
>



--
Andy Lutomirski
AMA Capital Management, LLC


\
 
 \ /
  Last update: 2015-02-04 02:01    [W:1.038 / U:0.520 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site