[lldb-dev] Remote debugging and networking questions

[Oleksiy Vyalov]

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 <gclayton at apple.com> wrote:

>
> > On Dec 3, 2014, at 3:28 PM, Oleksiy Vyalov <ovyalov at 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 <gclayton at 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 <ovyalov at 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 | ovyalov at google.com
> > > _______________________________________________
> > > lldb-dev mailing list
> > > lldb-dev at cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> >
> >
> >
> >
> > --
> > Oleksiy Vyalov | Software Engineer | ovyalov at google.com
>
>


-- 
Oleksiy Vyalov | Software Engineer | ovyalov at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141203/63fd4d93/attachment.html>