From: ebiederm@xmission.com (Eric W. Biederman) To: Andy Lutomirski <luto@amacapital.net> Cc: Daniel Mack <daniel@zonque.org>, Arnd Bergmann <arnd@arndb.de>, "Ted Ts'o" <tytso@mit.edu>, Michael Kerrisk <mtk.manpages@gmail.com>, Linux API <linux-api@vger.kernel.org>, One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>, Austin S Hemmelgarn <ahferroin7@gmail.com>, Tom Gundersen <teg@jklm.no>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, linux-kernel <linux-kernel@vger.kernel.org>, David Herrmann <dh.herrmann@gmail.com>, Djalal Harouni <tixxdz@opendz.org>, Johannes Stezenbach <js@sig21.net>, Christoph Hellwig <hch@infradead.org> Subject: Re: [PATCH 01/13] kdbus: add documentation Date: Tue, 03 Feb 2015 20:47:51 -0600 [thread overview] Message-ID: <87siemgzoo.fsf@x220.int.ebiederm.org> (raw) In-Reply-To: <CALCETrV_q9Y4OWC6fA78WsD+XFhsdGHrqH6OK-hc=Vvj2F5C5w@mail.gmail.com> (Andy Lutomirski's message of "Tue, 3 Feb 2015 16:41:04 -0800") Andy Lutomirski <luto@amacapital.net> writes: > 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. 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
WARNING: multiple messages have this Message-ID (diff)
From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) To: Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> Cc: Daniel Mack <daniel-cYrQPVfZoowdnm+yROfE0A@public.gmane.org>, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>, Ted Ts'o <tytso-3s7WtUTddSA@public.gmane.org>, Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, One Thousand Gnomes <gnomes-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>, Austin S Hemmelgarn <ahferroin7-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Tom Gundersen <teg-B22kvLQNl6c@public.gmane.org>, Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>, linux-kernel <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, David Herrmann <dh.herrmann-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Djalal Harouni <tixxdz-Umm1ozX2/EEdnm+yROfE0A@public.gmane.org>, Johannes Stezenbach <js-FF7aIK3TAVNeoWH0uzbU5w@public.gmane.org>, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> Subject: Re: [PATCH 01/13] kdbus: add documentation Date: Tue, 03 Feb 2015 20:47:51 -0600 [thread overview] Message-ID: <87siemgzoo.fsf@x220.int.ebiederm.org> (raw) In-Reply-To: <CALCETrV_q9Y4OWC6fA78WsD+XFhsdGHrqH6OK-hc=Vvj2F5C5w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> (Andy Lutomirski's message of "Tue, 3 Feb 2015 16:41:04 -0800") Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> writes: > On Tue, Feb 3, 2015 at 2:09 AM, Daniel Mack <daniel-cYrQPVfZoowdnm+yROfE0A@public.gmane.org> wrote: >> Hi Andy, >> >> On 02/02/2015 09:12 PM, Andy Lutomirski wrote: >>> On Feb 2, 2015 1:34 AM, "Daniel Mack" <daniel-cYrQPVfZoowdnm+yROfE0A@public.gmane.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. 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
next prev parent reply other threads:[~2015-02-04 2:51 UTC|newest] Thread overview: 143+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-01-16 19:16 [PATCH v3 00/13] Add kdbus implementation Greg Kroah-Hartman 2015-01-16 19:16 ` Greg Kroah-Hartman 2015-01-16 19:16 ` [PATCH 01/13] kdbus: add documentation Greg Kroah-Hartman 2015-01-20 13:53 ` Michael Kerrisk (man-pages) 2015-01-20 13:53 ` Michael Kerrisk (man-pages) 2015-01-20 14:31 ` David Herrmann 2015-01-20 14:31 ` David Herrmann 2015-01-20 14:42 ` Josh Boyer 2015-01-20 14:42 ` Josh Boyer 2015-01-20 14:53 ` Djalal Harouni 2015-01-20 14:53 ` Djalal Harouni 2015-01-20 16:08 ` Johannes Stezenbach 2015-01-20 17:00 ` David Herrmann 2015-01-20 17:00 ` David Herrmann 2015-01-20 22:00 ` Johannes Stezenbach 2015-01-20 22:00 ` Johannes Stezenbach 2015-01-21 10:28 ` Michael Kerrisk (man-pages) 2015-01-21 10:28 ` Michael Kerrisk (man-pages) 2015-01-20 18:23 ` Daniel Mack 2015-01-20 18:23 ` Daniel Mack 2015-01-21 10:32 ` Michael Kerrisk (man-pages) 2015-01-21 10:32 ` Michael Kerrisk (man-pages) 2015-01-21 15:19 ` Theodore Ts'o 2015-01-21 15:19 ` Theodore Ts'o 2015-01-21 16:58 ` Daniel Mack 2015-01-21 16:58 ` Daniel Mack 2015-01-22 10:18 ` Michael Kerrisk (man-pages) 2015-01-22 10:18 ` Michael Kerrisk (man-pages) 2015-01-22 13:46 ` David Herrmann 2015-01-22 13:46 ` David Herrmann 2015-01-22 14:49 ` Austin S Hemmelgarn 2015-01-23 16:08 ` Greg Kroah-Hartman 2015-01-26 14:46 ` Michael Kerrisk (man-pages) 2015-01-26 14:46 ` Michael Kerrisk (man-pages) 2015-01-27 15:05 ` David Herrmann 2015-01-27 15:05 ` David Herrmann 2015-01-27 16:03 ` Andy Lutomirski 2015-01-27 16:03 ` Andy Lutomirski 2015-01-29 8:53 ` Daniel Mack 2015-01-29 8:53 ` Daniel Mack 2015-01-29 11:25 ` Andy Lutomirski 2015-01-29 11:42 ` Daniel Mack 2015-01-29 12:09 ` Andy Lutomirski 2015-02-02 9:34 ` Daniel Mack 2015-02-02 9:34 ` Daniel Mack 2015-02-02 20:12 ` Andy Lutomirski 2015-02-02 20:12 ` Andy Lutomirski 2015-02-03 10:09 ` Daniel Mack 2015-02-03 10:09 ` Daniel Mack 2015-02-04 0:41 ` Andy Lutomirski 2015-02-04 0:41 ` Andy Lutomirski 2015-02-04 2:47 ` Eric W. Biederman [this message] 2015-02-04 2:47 ` Eric W. Biederman 2015-02-04 3:14 ` Greg Kroah-Hartman 2015-02-04 3:14 ` Greg Kroah-Hartman 2015-02-04 6:30 ` Eric W. Biederman 2015-02-04 6:30 ` Eric W. Biederman 2015-02-04 23:03 ` Andy Lutomirski 2015-02-04 23:03 ` Andy Lutomirski 2015-02-05 0:16 ` David Herrmann 2015-02-08 16:54 ` Andy Lutomirski 2015-02-08 16:54 ` Andy Lutomirski 2015-01-27 18:03 ` Michael Kerrisk (man-pages) 2015-01-27 18:03 ` Michael Kerrisk (man-pages) 2015-01-23 11:47 ` Michael Kerrisk (man-pages) 2015-01-23 11:47 ` Michael Kerrisk (man-pages) 2015-01-23 15:54 ` Greg Kroah-Hartman 2015-01-23 15:54 ` Greg Kroah-Hartman 2015-01-26 14:42 ` Michael Kerrisk (man-pages) 2015-01-26 14:42 ` Michael Kerrisk (man-pages) 2015-01-26 15:26 ` Tom Gundersen 2015-01-26 16:44 ` christoph Hellwig 2015-01-26 16:44 ` christoph Hellwig 2015-01-26 16:45 ` Michael Kerrisk (man-pages) 2015-01-27 15:23 ` David Herrmann 2015-01-27 17:53 ` Michael Kerrisk (man-pages) 2015-01-27 18:14 ` Daniel Mack 2015-01-27 18:14 ` Daniel Mack 2015-01-28 10:46 ` Michael Kerrisk (man-pages) 2015-01-20 13:58 ` Michael Kerrisk (man-pages) 2015-01-20 13:58 ` Michael Kerrisk (man-pages) 2015-01-20 17:50 ` Daniel Mack 2015-01-21 8:57 ` Michael Kerrisk (man-pages) 2015-01-21 8:57 ` Michael Kerrisk (man-pages) 2015-01-21 9:07 ` Daniel Mack 2015-01-21 9:07 ` Michael Kerrisk (man-pages) 2015-01-21 9:07 ` Michael Kerrisk (man-pages) 2015-01-21 9:12 ` Daniel Mack 2015-01-21 9:12 ` Daniel Mack 2015-01-23 6:28 ` Ahmed S. Darwish 2015-01-23 6:28 ` Ahmed S. Darwish 2015-01-23 13:19 ` Greg Kroah-Hartman 2015-01-23 13:29 ` Greg Kroah-Hartman 2015-01-23 13:29 ` Greg Kroah-Hartman 2015-01-25 3:30 ` Ahmed S. Darwish 2015-01-25 3:30 ` Ahmed S. Darwish 2015-01-16 19:16 ` [PATCH 02/13] kdbus: add header file Greg Kroah-Hartman 2015-01-16 19:16 ` [PATCH 03/13] kdbus: add driver skeleton, ioctl entry points and utility functions Greg Kroah-Hartman 2015-01-16 19:16 ` Greg Kroah-Hartman 2015-01-16 19:16 ` [PATCH 04/13] kdbus: add connection pool implementation Greg Kroah-Hartman 2015-01-16 19:16 ` [PATCH 05/13] kdbus: add connection, queue handling and message validation code Greg Kroah-Hartman 2015-01-16 19:16 ` Greg Kroah-Hartman 2015-01-16 19:16 ` [PATCH 06/13] kdbus: add node and filesystem implementation Greg Kroah-Hartman 2015-01-16 19:16 ` [PATCH 07/13] kdbus: add code to gather metadata Greg Kroah-Hartman 2015-01-16 19:16 ` [PATCH 08/13] kdbus: add code for notifications and matches Greg Kroah-Hartman 2015-01-16 19:16 ` [PATCH 09/13] kdbus: add code for buses, domains and endpoints Greg Kroah-Hartman 2015-01-16 19:16 ` Greg Kroah-Hartman 2015-01-16 19:16 ` [PATCH 10/13] kdbus: add name registry implementation Greg Kroah-Hartman 2015-01-16 19:16 ` [PATCH 11/13] kdbus: add policy database implementation Greg Kroah-Hartman 2015-01-16 19:16 ` Greg Kroah-Hartman 2015-01-16 19:16 ` [PATCH 12/13] kdbus: add Makefile, Kconfig and MAINTAINERS entry Greg Kroah-Hartman 2015-01-16 19:16 ` Greg Kroah-Hartman 2015-01-16 19:16 ` [PATCH 13/13] kdbus: add selftests Greg Kroah-Hartman 2015-01-16 22:07 ` [PATCH v3 00/13] Add kdbus implementation Josh Boyer 2015-01-16 22:07 ` Josh Boyer 2015-01-16 22:18 ` Greg Kroah-Hartman 2015-01-17 0:26 ` Daniel Mack 2015-01-17 0:26 ` Daniel Mack 2015-01-17 0:41 ` Josh Boyer 2015-01-17 0:41 ` Josh Boyer 2015-01-19 18:06 ` Johannes Stezenbach 2015-01-19 18:06 ` Johannes Stezenbach 2015-01-19 18:38 ` Greg Kroah-Hartman 2015-01-19 20:19 ` Johannes Stezenbach 2015-01-19 20:19 ` Johannes Stezenbach 2015-01-19 20:31 ` Greg Kroah-Hartman 2015-01-19 23:38 ` Johannes Stezenbach 2015-01-19 23:38 ` Johannes Stezenbach 2015-01-20 1:13 ` Greg Kroah-Hartman 2015-01-20 1:13 ` Greg Kroah-Hartman 2015-01-20 10:57 ` Johannes Stezenbach 2015-01-20 11:26 ` Greg Kroah-Hartman 2015-01-20 11:26 ` Greg Kroah-Hartman 2015-01-20 13:24 ` Johannes Stezenbach 2015-01-20 13:24 ` Johannes Stezenbach 2015-01-20 14:12 ` Michael Kerrisk (man-pages) 2015-01-26 21:32 ` One Thousand Gnomes 2015-01-26 21:32 ` One Thousand Gnomes 2015-01-19 18:33 ` Johannes Stezenbach 2015-01-19 18:33 ` Johannes Stezenbach 2015-01-20 14:05 ` Michael Kerrisk (man-pages) 2015-01-20 14:05 ` Michael Kerrisk (man-pages) 2015-01-20 14:15 ` Michael Kerrisk (man-pages)
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=87siemgzoo.fsf@x220.int.ebiederm.org \ --to=ebiederm@xmission.com \ --cc=ahferroin7@gmail.com \ --cc=arnd@arndb.de \ --cc=daniel@zonque.org \ --cc=dh.herrmann@gmail.com \ --cc=gnomes@lxorguk.ukuu.org.uk \ --cc=gregkh@linuxfoundation.org \ --cc=hch@infradead.org \ --cc=js@sig21.net \ --cc=linux-api@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=luto@amacapital.net \ --cc=mtk.manpages@gmail.com \ --cc=teg@jklm.no \ --cc=tixxdz@opendz.org \ --cc=tytso@mit.edu \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.