Remote debugging and networking questions

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.

  1. 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.

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

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)?

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"?

connect-hostname sounds good to me. As an alternative, I was thinking about “bind-hostname”.