connect-hostname sounds good to me. As an alternative, I was thinking about "bind-hostname".
On Wed, Dec 3, 2014 at 5:29 PM, Greg Clayton <gclay...@apple.com> wrote: > > > On Dec 3, 2014, at 3:28 PM, Oleksiy Vyalov <ovya...@google.com> wrote: > > > > Thank you for suggestions - let me think this path through. > > > > How do you think does it make sense to use value of hostname property as > a part of qHostInfo response (instead of real hostname)? > > Yes. Anything that will be doing and reverse connections will need to use > this. Not sure if "hostname" is a good name? "connect-hostname"? > "reverse-hostname"? > > > > > > On Wed, Dec 3, 2014 at 10:41 AM, Greg Clayton <gclay...@apple.com> > wrote: > > We should probably make a global setting in LLDB in Debugger.cpp line > 131 where we add a new setting named "hostname" or something else that > makes sense. It defaults to not being set, or we can try to populate it > with the result of HostInfo::GetHostname(...). Then you can change this if > needed to allow reverse connections to succeed. > > > > By default, it should do what it does now but it should use the > "hostname" (or whatever name we want to name it) setting instead of > HostInfo::GetHostname(). If the user changes the setting, then it would get > picked up and used. > > > > Greg > > > > > On Dec 2, 2014, at 5:34 PM, Oleksiy Vyalov <ovya...@google.com> wrote: > > > > > > Hello, > > > > > > I was playing with LLDB remote debugging and stumbled upon a few > network issues. Presumably, such issues may prevent lldb from connecting to > debugserver: > > > > > > 1. qLaunchGDBServer takes host's local hostname (like > $qLaunchGDBServer;host:ovyalov-linux...;#..), so lldb-platform may pass > this hostname to debugserver via command line. As I can see, debugserver > uses this hostname for authentication purposes - only incoming connection > from this host is allowed. There are a few possible problems here: > > > • Host's hostname may be just a local network name and in case > of debugging over the Internet target cannot resolve it. > > > • If host has multiple IPs there is no way to figure out which > IP will be chosen by host to connect to debugserver (unless lldb has option > to specify a local bind address). So, there is a likelihood that such > connection will be rejected by debugserver. > > > • As a variation of previous issue - host and target are on the > same machine and connected via remote-* platform as > "connect://localhost:some_port". If host binds a socket to any local > address excluding 127.0.0.1 - connection is rejected by debugserver. > > > • If host cannot get his own host name( > https://github.com/llvm-mirror/lldb/blob/ba1d944f0e761c277e6caba23a818b9d2083c40b/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp#L2838) > LLDB allows any inbound connection to debugserver. This affects debugging > security allowing anybody to connect debugserver and maybe even broken > right now - when platform parses "$qLaunchGDBServer;host:*;" it treats * > as a beginning of RLE sequence and eventually starts debugserver allowing > only connections from localhost. > > > Potentially, we may use hash authentication instead of using IP > address: > > > - lldb may generate a random hash which will be sent along with > qLaunchGDBServer (instead of host parameter). > > > - lldb-platform passes auth hash to debugserver via command line. > > > - debugserver expects to receive new packet with auth hash and > verifies that received hash matches the hash provided by platform. > > > Such change will definitely complicates interaction between lldb and > debugserver but on other hand will make LLDB networking more robust. > > > > > > As an easier workaround lldb can take local IP address (as a setting > option or command line flag) which will be used for outgoing TCP > connections (i.e. Socket::TcpConnect will bind to it) and will be sent as a > host option of qLaunchGDBServer request. It's still not perfect and won't > work in case of debugging over Internet, since most likely remote target > will get incoming connection from host's gateway/NAT IP. > > > > > > 2. Another problem that I found that once qLaunchGDBServer succeeded, > lldb tries to establish connection to debugserver, but instead of platform > connect address a target's host name is used - > https://github.com/llvm-mirror/lldb/blob/f06d448a750ebf88851791237077bb2a665f9784/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp#L486. > In case of debugging over the Internet, this may not work and it might be a > safer option to re-use the platform's address when connecting to > debugserver. > > > > > > Please let me know your opinion and whether it sounds reasonable to > you. > > > > > > Thank you. > > > > > > > > > -- > > > Oleksiy Vyalov | Software Engineer | ovya...@google.com > > > _______________________________________________ > > > lldb-dev mailing list > > > lldb-dev@cs.uiuc.edu > > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > > > > > > > > > -- > > Oleksiy Vyalov | Software Engineer | ovya...@google.com > > -- Oleksiy Vyalov | Software Engineer | ovya...@google.com
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
