> 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


_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

Reply via email to