Re: [tor-dev] Dormant Mode and pluggable transports
On Fri, Dec 14, 2018 at 04:28:26AM +0100, Alexander Færøy wrote: > On Thu, Dec 13, 2018 at 04:15:56PM -0700, David Fifield wrote: > > If transports need to become dormant too, then there needs to be some > > way for tor to tell them to be. Now that https://bugs.torproject.org/28179 > > (Handle output from PT processes with the event loop) is almost > > finished, perhaps the stdin/stdout channel would work for it. A request > > to become dormant really does apply to the entire PT process (not just a > > single transport or connection), so it's a good match for a > > process-global channel like stdin. The PT process could respond with a > > "SIGNAL DORMANT" message on its stdout, which would inform tor that the > > PT has understood the request and will try to become dormant. > > I've just opened bug #28849 for us to try to figure out how this should > work both for the new process module itself, but especially for the only > consumer of the process module right now: the pluggable transports. > > One part of this that especially affects PT's running on Windows is that > we would like to disable the Process I/O timer on Windows (which > currently ticks once a second) when we are in the dormant mode. This > would probably mean that once the stdout or stderr pipe's buffer, in the > PT process, is full writing to stdout/stderr will block which would > effectively be the same result as described in ticket #26360 (which > #28179 as a side-effect also happens to fix). > > The easy way out here would of course be to "just" terminate the PT's > when we enter the dormant mode and re-spawn them when we leave the > dormant mode. If we decide to extend the PT protocol to handle `SIGNAL > DORMANT` would we also need to have a method to inform the PT that it > can start interacting with the rest of the world again? As I think about it, I'm thinking that terminating the subprocess is better from a KISS perspective. It's forward-compatible too, in the sense that you can decide to start sending a "SIGNAL DORMANT" stdin message in the future. And yes, if there's a "SIGNAL DORMANT" there should also be a "SIGNAL ACTIVE" or something. > Would it be bad if `SIGNAL DORMANT` also means that the PT should not > write to stdout/stderr until it's been informed that we are no longer > dormant? :-) That could be tricky. It may not be worth it. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Dormant Mode and pluggable transports
Hi, On Thu, Dec 13, 2018 at 04:15:56PM -0700, David Fifield wrote: > If transports need to become dormant too, then there needs to be some > way for tor to tell them to be. Now that https://bugs.torproject.org/28179 > (Handle output from PT processes with the event loop) is almost > finished, perhaps the stdin/stdout channel would work for it. A request > to become dormant really does apply to the entire PT process (not just a > single transport or connection), so it's a good match for a > process-global channel like stdin. The PT process could respond with a > "SIGNAL DORMANT" message on its stdout, which would inform tor that the > PT has understood the request and will try to become dormant. I've just opened bug #28849 for us to try to figure out how this should work both for the new process module itself, but especially for the only consumer of the process module right now: the pluggable transports. One part of this that especially affects PT's running on Windows is that we would like to disable the Process I/O timer on Windows (which currently ticks once a second) when we are in the dormant mode. This would probably mean that once the stdout or stderr pipe's buffer, in the PT process, is full writing to stdout/stderr will block which would effectively be the same result as described in ticket #26360 (which #28179 as a side-effect also happens to fix). The easy way out here would of course be to "just" terminate the PT's when we enter the dormant mode and re-spawn them when we leave the dormant mode. If we decide to extend the PT protocol to handle `SIGNAL DORMANT` would we also need to have a method to inform the PT that it can start interacting with the rest of the world again? Would it be bad if `SIGNAL DORMANT` also means that the PT should not write to stdout/stderr until it's been informed that we are no longer dormant? :-) Cheers, Alex. -- Alexander Færøy ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Dormant Mode and pluggable transports
On Thu, Dec 13, 2018 at 03:56:50PM -0500, Nick Mathewson wrote: > == Compatibility issues > > I see two issues here: one minor, and one major. > > Minor issue: some applications periodically make requests to the tor > network on their own -- for example, Tor Browser's update requests. > These requests prevent Tor from becoming dormant. If this is > undesired, we can add some way around this. > > Major issue: some applications expect that Tor will always bootstrap > when it starts, and delay presenting their own UI until Tor is ready. > But if Tor starts as dormant, then it will not bootstrap until it > receives a request from the client or a "SIGNAL ACTIVE" command from > the controller. This could lead to breakage as the application waits > for Tor to tell it that it's ready, and Tor waits for somebody to tell > it that it's needed. > > Are all application developers okay with the issues above, and okay > with working around them? If not, we may need changes in Tor before > 0.4.0.x is released. Let's talk! I'm thinking about how Dormant Mode will interact with pluggable transports. Our current transports will (I think) become dormant when tor does, because they only send something when tor does. At most, they may chop up and pad some of tor's packets (like obfs4 iat-mode does), but they don't send traffic of their own while tor is quiet. There's nothing requiring that though: a transport is in general free to send dummy traffic whenever it wants, perhaps as a form of traffic flow obfuscation. If transports need to become dormant too, then there needs to be some way for tor to tell them to be. Now that https://bugs.torproject.org/28179 (Handle output from PT processes with the event loop) is almost finished, perhaps the stdin/stdout channel would work for it. A request to become dormant really does apply to the entire PT process (not just a single transport or connection), so it's a good match for a process-global channel like stdin. The PT process could respond with a "SIGNAL DORMANT" message on its stdout, which would inform tor that the PT has understood the request and will try to become dormant. Or simpler but more drastic, tor could terminate its PT subprocesses when it goes dormant (cleanly, by closing their stdin). ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
