Problems with remote debugging connections

Hi all,

I’m having a couple of problems with remote debugging.

  1. lldb unable to connect to lldb-gdbserver
    when lldb connects to platform, platform sends back a hostname that is supposed to be used for connection to lldb-gdbserver. Unfortunately, for my VM targets without DNS entries, the hostnames they return are useless. A much better strategy is to re-use the hostname in the platform connect url to connect to the lldb-gdbserver.

  2. lldb-gdbserver refuses connection from lldb. Similarly, qLaunchGDBServer includes a host name that lldb-gdbserver is allowed to accept connections from. If, for whatever reason, my source host doesn’t have a DNS entry, this will fail.

Also, if I platform connect to localhost, lldb-gdbserver will see the remote ip address as 127.0.0.1 which will not to match the DNS lookup of my hostname. A much better strategy is to just allow connections from the IP address that lldb-platform is currently communicating with.

I think these changes will work with all existing use cases and add many more use cases without compromising security.

I’m working on these changes now. I’m going to add the ability for a connection object to return either a remote hostname or a SocketAddress.

Questions/concerns?

Sincerely,

Vince

Hi all,

I'm having a couple of problems with remote debugging.

1) lldb unable to connect to lldb-gdbserver
when lldb connects to platform, platform sends back a hostname that is supposed to be used for connection to lldb-gdbserver. Unfortunately, for my VM targets without DNS entries, the hostnames they return are useless. A much better strategy is to re-use the hostname in the platform connect url to connect to the lldb-gdbserver.

That could easily work. We also could provide a lldb-platform argument that says what hostname to connect back to instead of itself, but that is more work and probably not needed. I can't think of any reason we would not just be able to use the hostname used to connect to the platform...

2) lldb-gdbserver refuses connection from lldb. Similarly, qLaunchGDBServer includes a host name that lldb-gdbserver is allowed to accept connections from. If, for whatever reason, my source host doesn't have a DNS entry, this will fail.

Isn't that related to why the above case 1 is failing? What value is the platform sending back to LLDB in the above case?

Also, if I platform connect to localhost, lldb-gdbserver will see the remote ip address as 127.0.0.1 which will not to match the DNS lookup of my hostname. A much better strategy is to just allow connections from the IP address that lldb-platform is currently communicating with.

that is fine.

I think these changes will work with all existing use cases and add many more use cases without compromising security.

That sounds good.

I'm working on these changes now. I'm going to add the ability for a connection object to return either a remote hostname or a SocketAddress.

Questions/concerns?

There is so much spoofing that goes on when running things remotely and with virtual machines that this needs to be as powerful as we can make it. Feel free propose fixes and we can look at what you come up with. I will need to test with iOS when you have changes so I can make sure nothing breaks on our side. Let me know when you have something and I will test it.

Greg

Isn’t that related to why the above case 1 is failing?

Related in that they’re both using a passed hostname for making/allowing a connection but different in that they are different spots in the code.