LLDB currently uses a client-server architecture. That appears fine,
but runs into an annoying security problem: other users on the same
machine can connect to the TCP socket and take over LLDB and thus the
user’s system. This means that LLDB is useless in multiuser
enviromnents on Linux, such as academic computer labs.
The immediate problem can be solved by using either HMAC authentication
of all messages or by using Unix domain sockets. However, it might be
simpler to use a 3rd party library for the purpose:
https://github.com/DemiMarie/SlipRock (Disclaimer: I wrote SlipRock).
Questions:
- Would you be interested in using SlipRock?
- What features would SlipRock need in order to be useful to you? In
particular, do you need an asynchronous API, or is synchronous fine?
- If not, would you be willing to accept patches to fix the existing
bug?
Sincerely,
Demi Obenour
(+LLDB-Dev) most of the LLDB developers hang out there more than on LLVM-Dev.
LLDB currently uses a client-server architecture. That appears fine,
but runs into an annoying security problem: other users on the same
machine can connect to the TCP socket and take over LLDB and thus the
user’s system. This means that LLDB is useless in multiuser
enviromnents on Linux, such as academic computer labs.
The immediate problem can be solved by using either HMAC authentication
of all messages or by using Unix domain sockets. However, it might be
simpler to use a 3rd party library for the purpose:
https://github.com/DemiMarie/SlipRock (Disclaimer: I wrote SlipRock).
Questions:
- Would you be interested in using SlipRock?
Probably not. Generally we shy away from using third party libraries.
- What features would SlipRock need in order to be useful to you? In
particular, do you need an asynchronous API, or is synchronous fine?
The biggest thing that I would see as a barrier for us using SlipRock is that it would have to provide a large advantage in order to justify using it. We generally don't use middleware libraries that are not readily available on the platforms that we support, usually either via a package manager or shipping on the OS.
- If not, would you be willing to accept patches to fix the existing
bug?
I was actually looking at this code earlier this week. On OS X we do use Unix socketpair to construct domain sockets between debugserver and lldb. Presently lldb-server (the debugserver implementation used everywhere other than OS X) doesn't support accepting a socket pair, but we can and should fix that. I've been working recently on making more of LLDB's code properly configured based on system capabilities rather than hard coded assumptions. This will make it easier for us to do these kinds of things right in the future.
If you're interested in working on getting lldb-server working with socketpair we would certainly take the patches, and I'd be happy to provide review or guidance as needed.
Thanks,
-Chris
A cursory glance at SlipRock raises a few concerns:
- It depends on libsodium (I like libsodium, but it adds another external dependency).
- It doesn’t appear to have been tested on non-Linux *NIX systems (LLDB is the default debugger on macOS / iOS, is about to be on FreeBSD, and is used on NetBSD, OpenBSD and Solaris). I include build testing in this, as the build system only looks for sodium.h in the default location on Linux.
- The Windows support is not yet done (at least, there’s no tick in the ‘compiles on Windows’ status item).
- Attempting to compile it on FreeBSD gives 9 warnings and 8 errors, with several warnings referring to playing fast and loose with pointer aliasing rules. This makes me very nervous in code that’s intended for security.
- It uses assert() instead of real error handling, which is inappropriate in a library, and requires that the file be compiled without -DNDEBUG, which makes it annoying to integrate into other build systems.
- The APIs appear to be entirely undocumented.
- The error handling does not match the lexical scoping and so is very difficult to follow (and therefore potentially error prone). I was unable to run the static analyser on the code because it doesn’t compile on FreeBSD or macOS.
David
Those are all bu
I plan on removing this dependency by copying the code.
Do you know of any ways I can do CI on those systems? That it fails to build on any *nix platform (with libsodium installed) is a bug. I am working on improving the CMake build system to help with that.
I plan on doing a refactoring that should make that much easier.
Not following the pointer aliasing rules is definitely a bug. Would you mind posting the log?
That’s certainly a bug. I will fix it.
The documentation is in sliprock.h, but the fact that that is not easy to find is a bug.
That’s definitely a bug, at least in my opinion. SlipRock should be very easy to follow. I was inspired by the Linux kernel’s “goto fail” but obviously things didn’t work as expected.