From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753162AbbBDCvy (ORCPT ); Tue, 3 Feb 2015 21:51:54 -0500 Received: from out02.mta.xmission.com ([166.70.13.232]:58577 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750844AbbBDCvt (ORCPT ); Tue, 3 Feb 2015 21:51:49 -0500 From: ebiederm@xmission.com (Eric W. Biederman) To: Andy Lutomirski Cc: Daniel Mack , Arnd Bergmann , "Ted Ts'o" , Michael Kerrisk , Linux API , One Thousand Gnomes , Austin S Hemmelgarn , Tom Gundersen , Greg Kroah-Hartman , linux-kernel , David Herrmann , Djalal Harouni , Johannes Stezenbach , Christoph Hellwig References: <1421435777-25306-1-git-send-email-gregkh@linuxfoundation.org> <1421435777-25306-2-git-send-email-gregkh@linuxfoundation.org> <54BE5DC8.70706@gmail.com> <54BE9D08.7010804@zonque.org> <54BF805B.4000609@gmail.com> <54BFDAAA.50203@zonque.org> <54C0CE8A.5080805@gmail.com> <54C10DDC.9000503@gmail.com> <20150123160854.GA5210@kroah.com> <54C65346.5070504@gmail.com> <54C9F525.4040703@zonque.org> <54CA1CA2.9060005@zonque.org> <54CF44B9.8000005@zonque.org> <54D09E6B.2020903@zonque.org> Date: Tue, 03 Feb 2015 20:47:51 -0600 In-Reply-To: (Andy Lutomirski's message of "Tue, 3 Feb 2015 16:41:04 -0800") Message-ID: <87siemgzoo.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX18HYtWb9+Ole8mMlkKbX4cv1A340aD8yHE= X-SA-Exim-Connect-IP: 70.59.163.10 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.4978] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] * 0.5 XM_Body_Dirty_Words Contains a dirty word * 1.0 T_XMDrugObfuBody_08 obfuscated drug references X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;Andy Lutomirski X-Spam-Relay-Country: X-Spam-Timing: total 669 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 3.6 (0.5%), b_tie_ro: 2.5 (0.4%), parse: 0.85 (0.1%), extract_message_metadata: 16 (2.5%), get_uri_detail_list: 2.9 (0.4%), tests_pri_-1000: 8 (1.1%), tests_pri_-950: 1.28 (0.2%), tests_pri_-900: 1.13 (0.2%), tests_pri_-400: 33 (4.9%), check_bayes: 31 (4.7%), b_tokenize: 10 (1.4%), b_tok_get_all: 12 (1.8%), b_comp_prob: 3.4 (0.5%), b_tok_touch_all: 3.5 (0.5%), b_finish: 0.72 (0.1%), tests_pri_0: 598 (89.4%), tests_pri_500: 4.3 (0.6%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH 01/13] kdbus: add documentation X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Andy Lutomirski writes: > On Tue, Feb 3, 2015 at 2:09 AM, Daniel Mack wrote: >> Hi Andy, >> >> On 02/02/2015 09:12 PM, Andy Lutomirski wrote: >>> On Feb 2, 2015 1:34 AM, "Daniel Mack" 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. A quick note on a couple of things I have seen in this conversation. - The reason for kdbus is performance. - pipes rather than unix domain sockets are likely the standard to meet. If you can't equal unix domain sockets for simple things you are likely leaving a lot of stops in. Last I looked pipes in general were notiably faster than unix domain sockets. The performance numbers I saw posted up-thread were horrible. I have seen faster numbers across a network of machines. If your ping-pong latency isn't measured in nano-seconds you are probably doing something wrong. - syscalls remove overhead. So since performance is kdbus's reason for existence let's remove some ridiculous stops, and get a fast path into the kernel. - send-time metadata is a performance nightmare. SO_PASSCRED is hard to implement in a fast performant way, especially when namespaces get involved. Over the long term if you use send-time metadata you will grow the kind of compatibility hacks that the user namespace and the pid namespace have on SO_PASSCRED and things will slow down. A similar effect that is more performant in general is to enforce that the sender has the expected attributes. > 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. I think send-time metadata verification is less bad in this regard. Eric