Opened 8 years ago

Last modified 10 months ago

#6948 new enhancement

Shared memory for zygote mind meld

Reported by: ioerror Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-security, tbb-sandboxing
Cc: mikeperry, nickm, arma, adrelanos@…, intrigeri@…, sysrqb Actual Points:
Parent ID: #19750 Points:
Reviewer: Sponsor:


As I mentioned in #6937, I think we could really use a shared memory mutex as some kind meeting point for various Tor specific applications. This likely would be created by Tor or by a zygote that launches things like Tor and the Tor Browser. In theory, we could then have the launcher application and ensure we don't launch extra copies of Tor, we could ensure that we know _how_ we may connect as well as how to authenticate; lots of stuff becomes possible with a little IPC love.

I have a sketch of the zygote/launcher process but I need to take it from my notepad to text, so I'm merely capturing this part of the process in this ticket. More tickets to come.

Child Tickets

Change History (15)

comment:1 Changed 8 years ago by arma

Sounds plausible to me. The first catch that comes to mind is that when Tor dies it needs to take down the shared memory hunk too -- and if it dies poorly, it might not be able to.

comment:2 in reply to:  1 Changed 8 years ago by ioerror

Replying to arma:

Sounds plausible to me. The first catch that comes to mind is that when Tor dies it needs to take down the shared memory hunk too -- and if it dies poorly, it might not be able to.

I was considering this last night and I thought of a possible solution to this problem.

We can ensure that the shared memory hunk has a pointer to a name of another shared memory hunk. If Tor goes down without taking down the shared global memory mutex, and an application cannot connect, the application with this zygote support can check the contents of the shared memory for an item that tells them where to create a new shared memory mutex. The zygote may then create a new tor instance, which will look at the previous instance, grab the old mutex name, increment to the next one or use the one left by the first Tor and start a fresh Tor. In this way, we can be sure that Tor will always have left a linked list behind that leads to a possible new Tor.

In essence tor-shim-000 will have a few points of application contact (ControlSocket, SocksSocket, SocksPort, TransPort, etc) and then other information that might be useful (pid of Tor, time of launch, pointer to next shared memory address in case this Tor dies badly, etc) to the zygote, to other applications and so on.

This should solve our auto-configuration problems and because we'll have security contexts, we can do SOCKS isolation on the SocksSocket by uid/gid, we can do security controls with uid/gid on the ControlSocket (and still freely share it), we can give out the pid without having to resort to some un-portable nightmare and so on.

comment:3 Changed 8 years ago by ioerror

The code name for this overall project is 'tzygotor' after Google's zygote.

comment:4 Changed 8 years ago by stewart

It may be easier/simpler to take the approach of something like uuidd, which is spawned by libuuid on demand - and you just use a UNIX socket to connect to it (for Windows you'd do a named pipe).

Basically, the first tzygotor app launched would spawn tor and get a socket to do SOCKS things over, subsequent ones would just get the same socket without spawning it. It could even be that on the last tzygotor app exiting, the tor daemon is shut down.

comment:5 Changed 8 years ago by stewart

Basically.. I've found that shared memory hard; sockets good. Especially cross-platform and in the event of failure.

comment:6 Changed 8 years ago by nickm

For reference, a "zygote" is apparently a reference to part of the Chrome architecture.

comment:7 Changed 8 years ago by proper

I made an overview about the current limitations of communication between Tor, various bundles and applications. It's a list with feature requests and open trac tickets. (yes, not best title)

comment:8 Changed 8 years ago by proper

Cc: adrelanos@… added

comment:9 Changed 8 years ago by ioerror

Stewart - I agree entirely. I think that is a fine idea overall. I'm still going to mess around with shared memory stuff but it won't be required for anything. I want to add ways of getting this stuff done and less and less asking of the user is best, I think.

comment:10 Changed 8 years ago by intrigeri

Cc: intrigeri@… added

comment:11 Changed 6 years ago by erinn

Keywords: needs-triage added

comment:12 Changed 3 years ago by teor

Severity: Normal

Set all open tickets without a severity to "Normal"

comment:13 Changed 2 years ago by gk

Cc: sysrqb added
Component: Applications/Tor bundles/installationApplications/Tor Browser
Keywords: tbb-security added; needs-triage removed
Owner: changed from erinn to tbb-team

comment:14 Changed 10 months ago by gk

Keywords: tbb-sandboxing added

comment:15 Changed 10 months ago by gk

Parent ID: #19750
Note: See TracTickets for help on using tickets.