On Mon, Nov 14, 2016 at 7:34 AM, Joe Lawrence <joe.lawre...@redhat.com> wrote: > On 11/11/2016 09:41 PM, Alexei Starovoitov wrote: >> On Thu, Nov 10, 2016 at 7:36 AM, Joe Lawrence <joe.lawre...@redhat.com> >> wrote: >>> On 11/09/2016 11:11 PM, Alexei Starovoitov wrote: >>>> On Wed, Nov 9, 2016 at 8:59 AM, Joe Lawrence <joe.lawre...@redhat.com> >>>> wrote: >>>>> Hi Alexei -- I was at the Plumber's conference last week, but >>>>> unfortunately missed your talk on User Space Dynamic Tracing... A >>>>> colleague mentioned that you had presented a slide deck -- I'd be >>>>> interested in checking that out if it was still available (email or >>>>> uploaded to LPC site). >>>> >>>> There was only one slide to illustrate the goal. >>>> Not very useful without hearing the discussion that we had. >>>> Here it is anyway. >>>> What is your particular interest in the tracing? >>>> >>>> Thanks >>>> >>> >>> Thanks for attaching the slides... My interest was from the POV of >>> userspace live patching. A Red Hat colleague, Josh Poimboeuf, was at >>> your presentation and suggested touching base with you. >>> >>> Our group at Red Hat primary works on kpatch, which uses the ftrace >>> infrastructure to hook functions... Perhaps a similar technique would be >>> possible given a userspace tracing facility. >>> >>> In our early efforts to do userspace live patching, I've been tinkering >>> with a ptrace-shared library injection-code trampoline approach that >>> looks similar to the "Install program, binary blob" parts of your third >>> slide. >> >> interesting. could you share the link to this lib? > > What I did was fork a project called linux-inject here: > > https://github.com/joe-lawrence/linux-inject > > This project demonstrates the use of ptrace to attach and then force the > target to call __libc_dlopen_mode (this lives in libc unlike the dlopen > wrapper in libdl) effectively injecting a given shared object into that > program.
looks great! > I added the patches/ directory to the project to try out this approach > in applying a few CVE fixes. I built a base patching shared library > that reads and applies a patch description array. New patched code is > also included in this shared library. The patching mechanism applies a > code-trampoline at given locations routing the binary away from the old > code and into the newly loaded patched code. > > It's only a proof-of-concept, but I did record a few .gif terminal > sessions to show what's possible: > > > https://raw.githubusercontent.com/joe-lawrence/linux-inject/master/patches/demo.gif > > https://raw.githubusercontent.com/joe-lawrence/linux-inject/master/patches/ghost_demo.gif > > https://raw.githubusercontent.com/joe-lawrence/linux-inject/master/patches/cves.gif > >> we're trying to reuse as much as possible. >> Like for shmem ring buffer we're thinking to reuse lttng per-cpu >> ring buffer mechanism after rseq patches land. >> For code injections many different ideas were proposed. >> Including dyninst, but it looks to be an overkill. > > I'm still reading up on dyninst (and its PatchAPI) ... it's a lot more > developed than my PoC, but offers a much richer API than I envisioned > for livepatching. That said, it's documented, tested, etc. so might > still be useful for the livepatching use case. > >> I'm thinking something like ptrace but inode based like uprobe, >> so that 'patch' of the program can be setup before the program >> starts. > > This is similar to the discussion we had with Masami at one of the LPC > evening events. He didn't get too far into details, but suggested a > uprobes approach where we may be able to stitch in replacement pages for > target tasks. Some kind of inode approach would be interesting as well > to solve new program invocations. > > Are the tracing folks discussing userspace upstream on the mailing lists > yet? If so, I'd like to participate :) sorry for delay and thanks a lot for all the links. starting next year we're planning to invest into building a prototype where we can inject the code into remote process, fixup usdt-s in the remote process to point to injected code and let this injected code interact with master process via shared memory. The goal is to build an alternative to uprobe+bpf at much higher speed. Hence cc-ing all interested folks. > libcompel - execute arbitrary code in a context of a foreign process > https://criu.org/Compel excellent find! this one looks the most advanced and ready to use. Could you please share your finding with them? Are you going to continue investing into your: https://github.com/joe-lawrence/linux-inject and how does it compare? Thanks! _______________________________________________ iovisor-dev mailing list iovisor-dev@lists.iovisor.org https://lists.iovisor.org/mailman/listinfo/iovisor-dev
