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
[tor-dev] Upcoming Tor change with application impact: "Dormant Mode"
Hello! This email is about a new feature that has some implications here for applications that use Tor. I want to make sure we've thought about and prepared for those implications, since we still have time to tweak this feature. == Overview In 0.4.0.x, Tor will begin supporting a new "dormant" mode in which it does not initiate network activity, and tries to avoid CPU wakeups. This mode is intended to help mobile devices sleep, and to minimize the impact of unused Tor clients on the network, and on the devices that run them. For the implementation history, see: https://trac.torproject.org/projects/tor/ticket/28335 and https://trac.torproject.org/projects/tor/ticket/28624 By default, Tor will become dormant if it is a pure client (not a relay, not an onion service[*]), and if it has received not client activity for 24 hours. (You can change the interval with DormantClientTimeout.) Unlike "DisableNetwork 1", Tor in dormant mode will not close any listener ports, and will become active again as soon as it receives a client connection. But like a "DisableNetwork 1" Tor, a dormant Tor will not build predicted circuits, and will not download directory information -- and therefore, will not bootstrap. Controllers can make Tor become dormant or non-dormant by sending the commands "SIGNAL DORMANT" and "SIGNAL ACTIVE" respectively -- these are now documented in control-spec.txt. Dormant state is persistent: if Tor has been idle for 20 hours, and you stop tor and start it again, and idle for 4 more hours, Tor will become dormant. If you stop tor and start it again, Tor will start in dormant mode. == Documentation Here's the documentation we have so far -- please let me know if you have ideas for clarification: DormantClientTimeout N minutes|hours|days|weeks If Tor spends this much time without any client activity, enter a dormant state where automatic circuits are not built, and directory information is not fetched. Does not affect servers or onion services. Must be at least 10 minutes. (Default: 24 hours) DormantTimeoutDisabledByIdleStreams 0|1 If true, then any open client stream (even one not reading or writing) counts as client activity for the purpose of DormantClientTimeout. If false, then only network activity counts. (Default: 1) DormantOnFirstStartup 0|1 If true, then the first time Tor starts up with a fresh DataDirectory, it starts in dormant mode, and takes no actions until the user has made a request. (This mode is recommended if installing a Tor client for a user who might not actually use it.) If false, Tor bootstraps the first time it is started, whether it sees a user request or not. After the first time Tor starts, it begins in dormant mode if it was dormant before, and not otherwise. (Default: 0) == 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'd like to add support for dormant onion services, but that's harder. See https://trac.torproject.org/projects/tor/ticket/28424 . peace, -- Nick ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Update on Guardian Project Pluggable Transport work
The Guardian Project "PLUTO" project is our name for the work we're doing around Pluggable Transports. If you want to follow this work more closely, you can ask n8fr8 to add you to our semi-private PLUTO mailing list. n8fr8 is currently working on integrating PTs into Android apps in a reusable way. That work is mostly in https://github.com/guardianproject/AndroidPluggableTransports I recently did some work to port snowflake to Android. That should be useable now, but with some open issues about repeatable builds and verification that non-free libs are not linked in. That's mostly here: https://github.com/keroserene/snowflake/pull/43 Then we're doing full stack prototypes for using PTs in Android apps, based on Wikipedia, F-Droid and an RFA app. That stuff is scattered around. From that work, uniqx (Michael Poehn) has produced a PT bridge server setup automation: https://gitlab.com/uniqx/pt-socks5-over-obfs4proxy uniqx and I are now focused on Encrypted SNI for use as a PT, so there will be some server automation around that, e.g. custom openssl/mod_ssl build included. .hc -- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] prob_distr.c: LogLogistic fails stochastic tests on 32-bits mingw
> Date: Thu, 13 Dec 2018 03:25:30 +
> From: Taylor R Campbell
>
> Binary80 arithmetic tickled a problem in the lerp used for binning --
> [...]
Correction: while making the lerp less naive addresses this problem,
it also arises only when binary80 arithmetic and binary64 arithmetic
are mixed, which you get on 32-bit x86 in C double with the x87 unit
in binary80 mode so (a) double is binary64, but (b) intermediate
expressions are evaluated in binary80.
The attached program shows this, by putting either one (bad) or two
(good) intermediate expressions in double variables. On x86, if you
compile it with -mfpmath=387 (default on 32-bit), you'll see the bad
result, a negative answer; if you compile it with -mfpmath=sse
(default on 64-bit), you'll see only good results, zero. Convert
everything to use long double (and %Le) instead so that all the
arithmetic and intermediate quantities are binary80, and it's fine.
% cc -o loser -mfpmath=387 loser.c && ./loser
bad -2.45760e+04
good 0.0e+00
% cc -o loser -mfpmath=sse loser.c && ./loser
bad 0.0e+00
good 0.0e+00
(This is why I don't like x87 and the automagic evaluation of
expressions in higher precision...)
#include
#ifdef __NetBSD__
#include
#else
#include
#define FP_PS 0
#define FP_PRS 1
#define FP_PD 2
#define FP_PE 3
int
fpsetprec(int nprec)
{
uint32_t ocw, ncw;
int oprec;
asm volatile("fnstcw %0" : "=m"(ocw));
oprec = (ocw >> 8) & 3;
ncw = (ocw & ~(uint32_t)(3 << 8)) | (uint32_t)((nprec & 3) << 8);
asm volatile("fldcw %0" : : "m"(ncw));
return oprec;
}
#endif
int
main(void)
{
volatile double lo = 2.4608250784829636e-20;
volatile double hi = 3.0026742508190853e+20;
volatile double w, d;
volatile size_t n = 100;
fpsetprec(FP_PE);
w = (hi - lo)/(n - 2);
d = (n - 2)*w;
printf("bad %.17e\n", hi - (n - 2)*w);
printf("good %.17e\n", hi - d);
fflush(stdout);
return ferror(stdout);
}
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
