[chromium-dev] Re: Why SOCK_SEQPACKET?
On Wed, Oct 7, 2009 at 8:09 PM, Evan Martin e...@chromium.org wrote: On Fri, Oct 2, 2009 at 2:40 PM, Adam Langley a...@chromium.org wrote: On Fri, Oct 2, 2009 at 2:37 PM, Ben Laurie b...@chromium.org wrote: Why will it certainly not work? From what (little) I understand, SOCK_SEQPACKET adds record boundaries to SOCK_STREAM ... presumably one could simulate that over SOCK_STREAM? There are multiple, concurrent writers to the socket. If you make assumptions about the kernel's behaviour, you might be able to come up with a workable framing protocol, but it's much better to use the correct socket type. If anyone gets the chance, I would happily pre-LGTM a change that stuffs some comments near this code explaining the reasoning for this. http://codereview.chromium.org/270041 --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Why SOCK_SEQPACKET?
On Fri, Oct 9, 2009 at 7:42 AM, Ben Laurie b...@chromium.org wrote: If anyone gets the chance, I would happily pre-LGTM a change that stuffs some comments near this code explaining the reasoning for this. http://codereview.chromium.org/270041 AGL beat you to it, but maybe he didn't commit it since the tree's always closed. :( --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Why SOCK_SEQPACKET?
On Fri, Oct 9, 2009 at 4:33 PM, Evan Martin e...@chromium.org wrote: On Fri, Oct 9, 2009 at 7:42 AM, Ben Laurie b...@chromium.org wrote: If anyone gets the chance, I would happily pre-LGTM a change that stuffs some comments near this code explaining the reasoning for this. http://codereview.chromium.org/270041 AGL beat you to it, but maybe he didn't commit it since the tree's always closed. :( Dammit! :-) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Why SOCK_SEQPACKET?
On Fri, Oct 2, 2009 at 2:40 PM, Adam Langley a...@chromium.org wrote: On Fri, Oct 2, 2009 at 2:37 PM, Ben Laurie b...@chromium.org wrote: Why will it certainly not work? From what (little) I understand, SOCK_SEQPACKET adds record boundaries to SOCK_STREAM ... presumably one could simulate that over SOCK_STREAM? There are multiple, concurrent writers to the socket. If you make assumptions about the kernel's behaviour, you might be able to come up with a workable framing protocol, but it's much better to use the correct socket type. If anyone gets the chance, I would happily pre-LGTM a change that stuffs some comments near this code explaining the reasoning for this. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Why SOCK_SEQPACKET?
On Sat, Oct 3, 2009 at 3:22 PM, Ben Laurie b...@chromium.org wrote: Why doesn't the sandbox prevent this? The SUID sandbox doesn't work that way. To be clear, the correct solution on FreeBSD is to use SOCK_DGRAM. Please don't rewrite the sandbox IPC scheme to have framing. It's a very minor security issue and not worth the extra code. On Linux, we want SOCK_SEQPACKET and if FreeBSD gets SEQPACKET in the future, then great, we can switch to using it everywhere. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Why SOCK_SEQPACKET?
On Fri, Oct 2, 2009 at 4:20 PM, Dan Kegel d...@kegel.com wrote:
On Fri, Oct 2, 2009 at 4:02 PM, Jacob Mandelson ja...@mandelson.org wrote:
Which reads like all or nothing to me, though I could imagine a (perverse?)
implementation with each writer having a send buffer lower layer pulling
data from multiple writers' send buffers in an interleaved manner. (But
maybe there's something else which restricts sockets to a single send
buffer.)
http://www.opengroup.org/onlinepubs/95399/functions/write.html
says
An attempt to write to a pipe or FIFO has several major characteristics:
Atomic/non-atomic: A write is atomic if the whole amount written in
one operation is not interleaved with data from any other process.
This is useful when there are multiple writers sending data to a
single reader. Applications need to know how large a write request can
be expected to be performed atomically. This maximum is called
{PIPE_BUF}. This volume of IEEE Std 1003.1-2001 does not say whether
write requests for more than {PIPE_BUF} bytes are atomic, but requires
that writes of {PIPE_BUF} or fewer bytes shall be atomic.
(I think PIPE_BUF is 64K on modern Linux, but might be smaller elsewhere.)
and
If fildes refers to a socket, write() shall be equivalent to send()
with no flags set.
So there is at least some cause to worry about data interleaving
between processes
without the fancy SOCK_SEQPACKET.
Sounds like it would be possible to fix, though, by sending multiple
chunks of the form idlengthdone flagdata each of which is
smaller than PIPE_BUF.
FreeBSD is adding SOCK_SEQPACKET, but it'd be nice to not require an
OS upgrade to use Chrome.
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Why SOCK_SEQPACKET?
On Fri, Oct 2, 2009 at 2:34 PM, Adam Langley a...@chromium.org wrote: On Fri, Oct 2, 2009 at 2:30 PM, Adam Langley a...@chromium.org wrote: There was some concern that a renderer could use sendto on a SOCK_DGRAM to direct packets to other destinations. However, when created with socketpair, this isn't an issue as I recall. Wait a minute. Idiot alert; I got that wrong. It *is* an issue with SOCK_DGRAM, which is why we're using SEQPACKET. Why doesn't the sandbox prevent this? So, if you change it to DGRAM for FreeBSD, please make sure that it's still SEQPACKET on Linux. Cheers AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Why SOCK_SEQPACKET?
On Fri, Oct 2, 2009 at 2:26 PM, Ben Laurie b...@chromium.org wrote: zygote_host_linux.cc creates a socketpair using SOCK_SEQPACKET rather than the more usual SOCK_STREAM? Before I trawl through code, does anyone know why? This is a problem for the FreeBSD port: FreeBSD doesn't support SOCK_SEQPACKET for unix domain sockets... SOCK_STREAM certainly won't work, but SOCK_DGRAM should be fine. There was some concern that a renderer could use sendto on a SOCK_DGRAM to direct packets to other destinations. However, when created with socketpair, this isn't an issue as I recall. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Why SOCK_SEQPACKET?
On Fri, Oct 2, 2009 at 2:30 PM, Adam Langley a...@chromium.org wrote: There was some concern that a renderer could use sendto on a SOCK_DGRAM to direct packets to other destinations. However, when created with socketpair, this isn't an issue as I recall. Wait a minute. Idiot alert; I got that wrong. It *is* an issue with SOCK_DGRAM, which is why we're using SEQPACKET. So, if you change it to DGRAM for FreeBSD, please make sure that it's still SEQPACKET on Linux. Cheers AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Why SOCK_SEQPACKET?
On Fri, Oct 2, 2009 at 2:30 PM, Adam Langley a...@chromium.org wrote: On Fri, Oct 2, 2009 at 2:26 PM, Ben Laurie b...@chromium.org wrote: zygote_host_linux.cc creates a socketpair using SOCK_SEQPACKET rather than the more usual SOCK_STREAM? Before I trawl through code, does anyone know why? This is a problem for the FreeBSD port: FreeBSD doesn't support SOCK_SEQPACKET for unix domain sockets... SOCK_STREAM certainly won't work, but SOCK_DGRAM should be fine. Why will it certainly not work? From what (little) I understand, SOCK_SEQPACKET adds record boundaries to SOCK_STREAM ... presumably one could simulate that over SOCK_STREAM? There was some concern that a renderer could use sendto on a SOCK_DGRAM to direct packets to other destinations. However, when created with socketpair, this isn't an issue as I recall. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Why SOCK_SEQPACKET?
On Fri, Oct 2, 2009 at 2:37 PM, Ben Laurie b...@chromium.org wrote: Why will it certainly not work? From what (little) I understand, SOCK_SEQPACKET adds record boundaries to SOCK_STREAM ... presumably one could simulate that over SOCK_STREAM? There are multiple, concurrent writers to the socket. If you make assumptions about the kernel's behaviour, you might be able to come up with a workable framing protocol, but it's much better to use the correct socket type. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Why SOCK_SEQPACKET?
On Fri, Oct 2, 2009 at 2:40 PM, Adam Langley a...@chromium.org wrote: On Fri, Oct 2, 2009 at 2:37 PM, Ben Laurie b...@chromium.org wrote: Why will it certainly not work? From what (little) I understand, SOCK_SEQPACKET adds record boundaries to SOCK_STREAM ... presumably one could simulate that over SOCK_STREAM? There are multiple, concurrent writers to the socket. If you make assumptions about the kernel's behaviour, you might be able to come up with a workable framing protocol, but it's much better to use the correct socket type. Ah, I see. Hmmm. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Why SOCK_SEQPACKET?
On Fri, Oct 02, 2009 at 02:45:21PM -0700, Ben Laurie wrote: On Fri, Oct 2, 2009 at 2:40 PM, Adam Langley a...@chromium.org wrote: On Fri, Oct 2, 2009 at 2:37 PM, Ben Laurie b...@chromium.org wrote: Why will it certainly not work? From what (little) I understand, SOCK_SEQPACKET adds record boundaries to SOCK_STREAM ... presumably one could simulate that over SOCK_STREAM? There are multiple, concurrent writers to the socket. If you make assumptions about the kernel's behaviour, you might be able to come up with a workable framing protocol, but it's much better to use the correct socket type. Ah, I see. Hmmm. The Linux send(2) man page explicitly says the message is all-or-nothing, and the SUS entry seems to indicate the same thing, though not as clearly, so that framing protocol can probably just be [lengthdata]* Still more complicated than having the socket layer do it though. -- Jacob --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Why SOCK_SEQPACKET?
On Fri, Oct 2, 2009 at 3:44 PM, Jacob Mandelson ja...@mandelson.org wrote: There are multiple, concurrent writers to the socket. If you make assumptions about the kernel's behaviour, you might be able to come up with a workable framing protocol, but it's much better to use the correct socket type. The Linux send(2) man page explicitly says the message is all-or-nothing, and the SUS entry seems to indicate the same thing, though not as clearly, so that framing protocol can probably just be [lengthdata]* Still more complicated than having the socket layer do it though. And SOCK_SEQPACKET is atomic, but simulating it with lengthdata isn't, so the simulation might break down with multiple concurrent writers. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Why SOCK_SEQPACKET?
On Fri, Oct 2, 2009 at 3:44 PM, Jacob Mandelson ja...@mandelson.org wrote: The Linux send(2) man page explicitly says the message is all-or-nothing, I don't think so. It says: If the message is too long to pass atomically through the underlying protocol, the error EMSGSIZE is returned, and the message is not transmitted. I think the confusion is that the underlying protocol for SOCK_STREAM isn't atomic. The description of the error is clearer: EMSGSIZE: The socket type requires that message be sent atomically, and the size of the message to be sent made this impossible. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Why SOCK_SEQPACKET?
On Fri, Oct 02, 2009 at 03:48:02PM -0700, Adam Langley wrote: On Fri, Oct 2, 2009 at 3:44 PM, Jacob Mandelson ja...@mandelson.org wrote: The Linux send(2) man page explicitly says the message is all-or-nothing, I don't think so. It says: If the message is too long to pass atomically through the underlying protocol, the error EMSGSIZE is returned, and the message is not transmitted. I think the confusion is that the underlying protocol for SOCK_STREAM isn't atomic. The description of the error is clearer: EMSGSIZE: The socket type requires that message be sent atomically, and the size of the message to be sent made this impossible. It also says: When the message does not fit into the send buffer of the socket, send() normally blocks, unless the socket has been placed in non-block‐ ing I/O mode. In non-blocking mode it would return EAGAIN in this case. Which reads like all or nothing to me, though I could imagine a (perverse?) implementation with each writer having a send buffer lower layer pulling data from multiple writers' send buffers in an interleaved manner. (But maybe there's something else which restricts sockets to a single send buffer.) -- Jacob --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Why SOCK_SEQPACKET?
On Fri, Oct 2, 2009 at 4:02 PM, Jacob Mandelson ja...@mandelson.org wrote:
Which reads like all or nothing to me, though I could imagine a (perverse?)
implementation with each writer having a send buffer lower layer pulling
data from multiple writers' send buffers in an interleaved manner. (But
maybe there's something else which restricts sockets to a single send buffer.)
http://www.opengroup.org/onlinepubs/95399/functions/write.html
says
An attempt to write to a pipe or FIFO has several major characteristics:
Atomic/non-atomic: A write is atomic if the whole amount written in
one operation is not interleaved with data from any other process.
This is useful when there are multiple writers sending data to a
single reader. Applications need to know how large a write request can
be expected to be performed atomically. This maximum is called
{PIPE_BUF}. This volume of IEEE Std 1003.1-2001 does not say whether
write requests for more than {PIPE_BUF} bytes are atomic, but requires
that writes of {PIPE_BUF} or fewer bytes shall be atomic.
(I think PIPE_BUF is 64K on modern Linux, but might be smaller elsewhere.)
and
If fildes refers to a socket, write() shall be equivalent to send()
with no flags set.
So there is at least some cause to worry about data interleaving
between processes
without the fancy SOCK_SEQPACKET.
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Why SOCK_SEQPACKET?
On Fri, Oct 2, 2009 at 4:20 PM, Dan Kegel d...@kegel.com wrote: (I think PIPE_BUF is 64K on modern Linux, but might be smaller elsewhere.) I seem to recall that pipe buf is a page and /usr/include/linux/limits.h says #define PIPE_BUF4096 -- Steve --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Why SOCK_SEQPACKET?
On Fri, Oct 2, 2009 at 4:25 PM, Steve Vandebogart vand...@chromium.org wrote: (I think PIPE_BUF is 64K on modern Linux, but might be smaller elsewhere.) I seem to recall that pipe buf is a page and /usr/include/linux/limits.h says #define PIPE_BUF 4096 Yeah, I got PIPE_BUF and pipe capacity mixed up. man 7 pipe set me straight. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
