Re: [lldb-dev] Trying to use socketpair for lldb-server fails
This is big time overkill, but I wasn’t sure where the problem I was tracking down was: “lldb all:linux all:gdb-remote all” Ted -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project From: Demi Obenour [mailto:demioben...@gmail.com] Sent: Friday, July 21, 2017 8:54 PM To: Ted Woodward ; lldb-dev@lists.llvm.org Subject: Re: [lldb-dev] Trying to use socketpair for lldb-server fails Sadly, that gives me nothing in the log file. Also, ConnectionFileDescriptor::Connect already seems to handle this case. Running strace on all child processes gives a “Operation not permitted” error from setsid(). That seems like the culprit, which is strange. Would you mind providing the value you used for LLDB_SERVER_LOG_CHANNELS? Demi On Fri, Jul 21, 2017 at 2:55 PM Ted Woodward mailto:ted.woodw...@codeaurora.org> > wrote: The first thing I'd do is use the lldb logging mechanism. lldb-server closes its own stdout and stderr, because nobody is interested in output from the server, just from the target. Except when you're debugging the server, so there is an easy way to turn on logging. Set the following environment variables: LLDB_DEBUGSERVER_LOG_FILE - this contains the path to the file the logs will be written to LLDB_SERVER_LOG_CHANNELS - this contains the channels and categories to turn logging on for. The format is "channel category:channel category...". If you want more than 1 category for a channel, I think "channel cat1 cat2..." works. This is not spelled out very clearly, unfortunately. Quickly glancing at the code, it looks like you need to implement a socketpair connection, and handling of the fd:// connection URL, starting in ConnectionFileDescriptor::Connect. The log for this would be "lldb connection". Ted -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project > -Original Message- > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org > <mailto:lldb-dev-boun...@lists.llvm.org> ] On Behalf Of Demi > Obenour via lldb-dev > Sent: Wednesday, July 19, 2017 7:44 PM > To: lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> > Subject: [lldb-dev] Trying to use socketpair for lldb-server fails > > To avoid a local privilage escalation, I am trying to patch LLDB not to use a TCP > socket for local communication. > > The attached patch failed. Would anyone be able to provide suggestions for > how to debug the problem? > > Sincerely, > > Demi ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Trying to use socketpair for lldb-server fails
Sadly, that gives me nothing in the log file. Also, ConnectionFileDescriptor::Connect already seems to handle this case. Running strace on all child processes gives a “Operation not permitted” error from setsid(). That seems like the culprit, which is strange. Would you mind providing the value you used for LLDB_SERVER_LOG_CHANNELS? Demi On Fri, Jul 21, 2017 at 2:55 PM Ted Woodward wrote: > The first thing I'd do is use the lldb logging mechanism. lldb-server > closes > its own stdout and stderr, because nobody is interested in output from the > server, just from the target. Except when you're debugging the server, so > there is an easy way to turn on logging. > > Set the following environment variables: > LLDB_DEBUGSERVER_LOG_FILE - this contains the path to the file the logs > will > be written to > LLDB_SERVER_LOG_CHANNELS - this contains the channels and categories to > turn > logging on for. The format is "channel category:channel category...". If > you > want more than 1 category for a channel, I think "channel cat1 cat2..." > works. This is not spelled out very clearly, unfortunately. > > > Quickly glancing at the code, it looks like you need to implement a > socketpair connection, and handling of the fd:// connection URL, starting > in > ConnectionFileDescriptor::Connect. The log for this would be "lldb > connection". > > Ted > > -- > Qualcomm Innovation Center, Inc. > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a > Linux Foundation Collaborative Project > > > -Original Message- > > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of > Demi > > Obenour via lldb-dev > > Sent: Wednesday, July 19, 2017 7:44 PM > > To: lldb-dev@lists.llvm.org > > Subject: [lldb-dev] Trying to use socketpair for lldb-server fails > > > > To avoid a local privilage escalation, I am trying to patch LLDB not to > use a TCP > > socket for local communication. > > > > The attached patch failed. Would anyone be able to provide suggestions > for > > how to debug the problem? > > > > Sincerely, > > > > Demi > > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Trying to use socketpair for lldb-server fails
The first thing I'd do is use the lldb logging mechanism. lldb-server closes its own stdout and stderr, because nobody is interested in output from the server, just from the target. Except when you're debugging the server, so there is an easy way to turn on logging. Set the following environment variables: LLDB_DEBUGSERVER_LOG_FILE - this contains the path to the file the logs will be written to LLDB_SERVER_LOG_CHANNELS - this contains the channels and categories to turn logging on for. The format is "channel category:channel category...". If you want more than 1 category for a channel, I think "channel cat1 cat2..." works. This is not spelled out very clearly, unfortunately. Quickly glancing at the code, it looks like you need to implement a socketpair connection, and handling of the fd:// connection URL, starting in ConnectionFileDescriptor::Connect. The log for this would be "lldb connection". Ted -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project > -Original Message- > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Demi > Obenour via lldb-dev > Sent: Wednesday, July 19, 2017 7:44 PM > To: lldb-dev@lists.llvm.org > Subject: [lldb-dev] Trying to use socketpair for lldb-server fails > > To avoid a local privilage escalation, I am trying to patch LLDB not to use a TCP > socket for local communication. > > The attached patch failed. Would anyone be able to provide suggestions for > how to debug the problem? > > Sincerely, > > Demi ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Trying to use socketpair for lldb-server fails
To avoid a local privilage escalation, I am trying to patch LLDB not to
use a TCP socket for local communication.
The attached patch failed. Would anyone be able to provide suggestions
for how to debug the problem?
Sincerely,
Demi
Index: source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp (revision
308480)
+++ source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp (working copy)
@@ -3289,7 +3289,8 @@
}
return error;
}
-#if defined(__APPLE__)
+#ifndef _WIN32
+//#ifdef __APPLE__
#define USE_SOCKETPAIR_FOR_LOCAL_CONNECTION 1
#endif
Index: tools/lldb-server/lldb-gdbserver.cpp
===
--- tools/lldb-server/lldb-gdbserver.cpp(revision 308480)
+++ tools/lldb-server/lldb-gdbserver.cpp(working copy)
@@ -97,6 +97,7 @@
{"attach", required_argument, NULL, 'a'},
{"named-pipe", required_argument, NULL, 'N'},
{"pipe", required_argument, NULL, 'U'},
+{"fd", required_argument, NULL, 'F'},
{"native-regs", no_argument, NULL,
'r'}, // Specify to use the native registers instead of the gdb defaults
// for the architecture. NOTE: this is a do-nothing arg as it's
@@ -232,7 +233,8 @@
GDBRemoteCommunicationServerLLGS &gdb_server,
bool reverse_connect, const char *const host_and_port,
const char *const progname, const char *const subcommand,
- const char *const named_pipe_path, int unnamed_pipe_fd) {
+ const char *const named_pipe_path, int unnamed_pipe_fd,
+ int connection_fd) {
Status error;
if (host_and_port && host_and_port[0]) {
@@ -257,7 +259,24 @@
std::unique_ptr connection_up;
-if (reverse_connect) {
+if (connection_fd != -1) {
+ abort();
+ char connection_url[512];
+ snprintf(connection_url, sizeof(connection_url), "fd://%d",
connection_fd);
+ connection_up.reset(new ConnectionFileDescriptor);
+ auto connection_result = connection_up->Connect(connection_url, &error);
+ if (connection_result != eConnectionStatusSuccess) {
+fprintf(stderr, "error: failed to connect to client at '%s' "
+"(connection status: %d)",
+connection_url, static_cast(connection_result));
+exit(-1);
+ }
+ if (error.Fail()) {
+fprintf(stderr, "error: failed to connect to client at '%s': %s",
+connection_url, error.AsCString());
+exit(-1);
+ }
+} else if (reverse_connect) {
// llgs will connect to the gdb-remote client.
// Ensure we have a port number for the connection.
@@ -364,6 +383,7 @@
log_channels; // e.g. "lldb process threads:gdb-remote default:linux all"
int unnamed_pipe_fd = -1;
bool reverse_connect = false;
+ int connection_fd = -1;
// ProcessLaunchInfo launch_info;
ProcessAttachInfo attach_info;
@@ -413,6 +433,11 @@
reverse_connect = true;
break;
+case 'F':
+ if (optarg && optarg[0])
+connection_fd = StringConvert::ToUInt32(optarg, -1);
+ break;
+
#ifndef _WIN32
case 'S':
// Put llgs into a new session. Terminals group processes
@@ -501,7 +526,7 @@
ConnectToRemote(mainloop, gdb_server, reverse_connect, host_and_port,
progname, subcommand, named_pipe_path.c_str(),
- unnamed_pipe_fd);
+ unnamed_pipe_fd, connection_fd);
if (!gdb_server.IsConnected()) {
fprintf(stderr, "no connection information provided, unable to run\n");
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
