[lldb-dev] Remote debugging and networking questions

[Oleksiy Vyalov]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141202/58c441c2/attachment.html>