I think it should be possible to abuse uprobe kernel logic to flip the semaphore value. Instead of writing into /proc/pid/mem we can uprobe on that exact location. Though it's not text, but data section. It may work ?
On Wed, Jan 17, 2018 at 8:57 AM, Sasha Goldshtein via iovisor-dev <[email protected]> wrote: > Not sure I understand your proposal re the kernel setting the semaphore. > > Anyway, yes, the semaphore concept and implementation goes back to SystemTap > SDT which is basically DTrace probes. > >> On Jan 17, 2018, at 16:55, Kiran T <[email protected]> wrote: >> >> Is this because this is tied to DTRACE abi? Perhaps another elf note >> or comment could be implemented, so this semaphore is set on binary >> load itself by the kernel? Again thinking out loud :) >> >> Thanks, >> Kiran >> >>> On Tue, Jan 16, 2018 at 8:51 PM, Sasha Goldshtein <[email protected]> >>> wrote: >>> Enabling semaphore-enabled probes system-wide requires poking >>> the semaphore’s memory in each process, I’m afraid. We can come >>> up with some implementation that would hook new process creation >>> and try to enable the semaphore when the relevant library gets loaded, >>> but it sounds a bit fragile. It could be interesting to explore >>> implementation alternatives for this. To hermetically enable the probe >>> we would need to synchronously block loading the provider’s library >>> into the target until we can modify the semaphore. This isn’t something >>> a BPF program can do, so it would require some external mechanism. >>> >>>> On Jan 17, 2018, at 03:44, Kiran T <[email protected]> wrote: >>>> >>>> Thanks Sasha, Yonghong. >>>> Looks like both php and python use semaphores. Is it fundamentally >>>> not possible to enable this systemwide or is it a feature which hasn't >>>> been implemented? >>>> Maybe we get pids of the process as they hit another probe and then >>>> get the semaphore addresses and enable them? >>>> Or is there a way to start the processes with the semaphore enabled -- >>>> a elf indicator or something? Just thinking out loud. >>>> >>>> Thanks, >>>> Kiran >>>> >>>>> On Mon, Jan 15, 2018 at 10:30 PM, Sasha Goldshtein <[email protected]> >>>>> wrote: >>>>> Please note that some USDT probes have an associated "semaphore", >>>>> which is really just a memory location that the probed code checks >>>>> before actually invoking the probe. You cannot enable USDT probes that >>>>> have a semaphore system-wide, without a process ID, because the >>>>> semaphore location has to be poked in each target process. >>>>> >>>>> To see if your probes have an associated semaphore, just run tplist with >>>>> -v -v and it will print out the semaphore address for each probe. If it's >>>>> 0, you're good to do system-wide tracing. >>>>> >>>>> Sasha >>>>> >>>>> >>>>> On Tue, Jan 16, 2018 at 8:08 AM Y Song via iovisor-dev >>>>> <[email protected]> wrote: >>>>>> >>>>>> Kiran, >>>>>> >>>>>> Yes, tracing through USDT without PID should work. >>>>>> You can just remove "-p" parameter and give a try. >>>>>> >>>>>> Please try latest bcc as it fixed a few bugs. >>>>>> Let us know if you hit any issues. >>>>>> >>>>>> Yonghong >>>>>> >>>>>> >>>>>> On Mon, Jan 15, 2018 at 5:11 PM, Kiran T via iovisor-dev >>>>>> <[email protected]> wrote: >>>>>>> I meant to say >>>>>>> >>>>>>> Can one request to monitor binaries -- like with >>>>>>> uprobes/uretprobes but with USDT? >>>>>>> >>>>>>>> On Mon, Jan 15, 2018 at 5:09 PM, Kiran T <[email protected]> wrote: >>>>>>>> Hi >>>>>>>> All the examples on tracing processes with USDT require the pid of the >>>>>>>> traced program: >>>>>>>> >>>>>>>> https://github.com/iovisor/bcc/tree/master/examples/tracing >>>>>>>> >>>>>>>> Can one not request to monitor binaries -- like with >>>>>>>> uprobes/uretprobes but with USDT? >>>>>>>> >>>>>>>> I am trying to trace php scripts running on a webserver, and USDT >>>>>>>> would be ideal. But, I won't have the pid of the process that will be >>>>>>>> spawned by the webserver in advance. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Kiran >>>>>>> _______________________________________________ >>>>>>> iovisor-dev mailing list >>>>>>> [email protected] >>>>>>> https://lists.iovisor.org/mailman/listinfo/iovisor-dev >>>>>> _______________________________________________ >>>>>> iovisor-dev mailing list >>>>>> [email protected] >>>>>> https://lists.iovisor.org/mailman/listinfo/iovisor-dev > _______________________________________________ > iovisor-dev mailing list > [email protected] > https://lists.iovisor.org/mailman/listinfo/iovisor-dev _______________________________________________ iovisor-dev mailing list [email protected] https://lists.iovisor.org/mailman/listinfo/iovisor-dev
