fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
nkambo__ has joined #systemtap
nkambo_ has quit [Ping timeout: 248 seconds]
hpt has joined #systemtap
nkambo_ has joined #systemtap
nkambo__ has quit [Ping timeout: 260 seconds]
irker496 has quit [Quit: transmission timeout]
slowfranklin has joined #systemtap
slowfranklin has quit [Quit: slowfranklin]
nkambo__ has joined #systemtap
nkambo_ has quit [Ping timeout: 240 seconds]
slowfranklin has joined #systemtap
nkambo_ has joined #systemtap
nkambo__ has quit [Ping timeout: 240 seconds]
slowfranklin has quit [Quit: slowfranklin]
slowfranklin has joined #systemtap
orivej has joined #systemtap
orivej has quit [Read error: Connection reset by peer]
slowfranklin has joined #systemtap
hpt has quit [Quit: Lost terminal]
scox has quit [Ping timeout: 248 seconds]
orivej has joined #systemtap
orivej has quit [Ping timeout: 240 seconds]
gila has joined #systemtap
mjw has joined #systemtap
wcohen has quit [Remote host closed the connection]
scox has joined #systemtap
wcohen has joined #systemtap
drsmith_away is now known as drsmith
tromey has joined #systemtap
nkambo__ has joined #systemtap
nkambo_ has quit [Ping timeout: 248 seconds]
nkambo_ has joined #systemtap
nkambo__ has quit [Ping timeout: 248 seconds]
nkambo_ has quit [Ping timeout: 240 seconds]
nkambo_ has joined #systemtap
nkambo__ has joined #systemtap
nkambo_ has quit [Ping timeout: 240 seconds]
nkambo_ has joined #systemtap
lindi- has quit [Remote host closed the connection]
lindi- has joined #systemtap
nkambo__ has quit [Ping timeout: 252 seconds]
nkambo__ has joined #systemtap
nkambo_ has quit [Ping timeout: 258 seconds]
nkambo_ has joined #systemtap
nkambo__ has quit [Ping timeout: 258 seconds]
slowfranklin has quit [Quit: slowfranklin]
slowfranklin has joined #systemtap
cstratak has joined #systemtap
ishcherb has joined #systemtap
<cstratak> Hello. It seems that latest systemtap which was pushed recently in Fedora broke python2 builds. Bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1504009
<fche> I don't see a dtrace -G foo.o run in that build.log
<fche> so there doesn't seem to be an -object file- that would contain those semaphore integers
<fche> another way is to find whatever code turns on _SDT_HAS_SEMAPHORES and comment that (back) out
<fche> then the plain pydtrace.h file should be self-sufficient
mjw has quit [Quit: Leaving]
<cstratak> fche, this is the downstream patch we use to add systemtap hooks. https://src.fedoraproject.org/rpms/python2/blob/master/f/00055-systemtap.patch originally created by dmalcolm if I recall correctly.
<fche> hm notice no dtrace.o listed in the whole build.log
<fche> yeah methinks that original patch is incomplete somehow
<fche> or something else about the pythong2 buildsystem broke ... @DTRACEOBJS@ should probably include Python/dtrace.o
<cstratak> yep. the same file was there in previous builds (with the older version).
<fche> the autoconf machinery tests dtrace -G ....
<cstratak> will try some adjustments to the patch. Thanks a lot for the pointers
<fche> I'd look at patch line area 17 ish
<fche> something is fishy
<fche> maybe it's fish
nkambo__ has joined #systemtap
mjw has joined #systemtap
nkambo_ has quit [Ping timeout: 248 seconds]
<cstratak> so it seems the command 'if dtrace -G -o /dev/null -s $srcdir/Include/pydtrace.d 2>/dev/null' returns a non-zero status
<fche> hm, hand-running the python configure here works for me on rawhide
mjw has quit [Ping timeout: 260 seconds]
mjw has joined #systemtap
<cstratak> fche, the configure script will work but it will go to the 'Apple' case, and not at the first if statement ('Sun' case).
<lindi-> new openssl versions have hidden most of the internal structs from header files. I worked around this by copying internal headers to my stap script. could systemtap consider including some common struct definitions?
<fche> cstratak, yeah, it shouldn't
<lindi-> (I have a script that logs various TLS parameters systemwide)
<fche> lindi-, neat. with debuginfo, stap should be able to get the struct definitions out of the object files pretty easily
<fche> without, and with no headers, you don't have a lot to go on, yeah. it'd be weird for -us- to include openssl.h headers though. not sure how to proceed
<lindi-> fche: you mean it should be possible to implement that or is there already code that does it?
<fche> I assume you're familiar with @cast(ptr,"type","file.h")
<fche> lindi-, which 'it' ?
<lindi-> fche: code to parse struct definitions from object files
<fche> that's @cast()
slowfranklin has quit [Quit: slowfranklin]
<fche> well, more specifically, that's always been part of stap
<fche> if you put a probe into an object file, and that object file includes debuginfo, then types of the objects in there will be visible, incl structs
<lindi-> fche: my old version was print_buffer(@cast($s, "ssl_st", "<openssl/ssl.h>")->s3->client_random, 32);
<fche> right. and now that header has disappeared?
<lindi-> fche: inside probe process("/usr/lib/x86_64-linux-gnu/libssl.so.1.0.2").function("tls1_generate_master_secret").return {
<fche> did $s->s3->client_random work though?
<lindi-> fche: yep. openssl commit b6ba401497001c2f042feff693ed292b21c8369c
<lindi-> fche: "Make libssl opaque. Move all structures that were previously protected by OPENSSL_NO_SSL_INTERN into internal header files."
<lindi-> fche: I can try that
<fche> heh. well, if you can find the header somewhere else, you could </path/to/other/copy/of/ssl.h> in that cast too
<lindi-> fche: it has been split to quite a lot of headers that #include lots of unrelated stuff
<fche> ok, so bottom line is that if the header still exists -somewhere- installed on the system, stap's @cast() should let you find it
<fche> if not, then may need to probe at the right spots, where the $context variables already have the right scope / type
<lindi-> wow, print_buffer(@entry($s->s3->client_random), 32); works
<fche> (you can also prototype with gdb, see what it can do with diffeent breakpoint locations)
<lindi-> this is better than I could imagine, thanks!
<fche> aha. yeah, that's been there since almost day one
<fche> @cast() was added for cases where the types were hidden, by the object code using opaque pointers e.g.
<lindi-> yep, I don't remember why I added that @cast there when I wrote the script originally
<fche> or if the debuginfo describing the types wasn't preserved in the object files, so stap had to try to create them anew from header files
mjw has quit [Ping timeout: 240 seconds]
<lindi-> fche: http://lindi.iki.fi/lindi/systemtap/capture_ssl_master_secrets.stp any other comments? I'd like to make this as reliable on as many distros as possible
<fche> heh, would be a fun example to add to our samples library
<fche> I'd use wildcards in the process ... path names as much as possible
<lindi-> fche: I was thinking about that too
<lindi-> fche: I'd also like to know if this could be used with VMs. doesn't systemtap nowadays have some support for that as well?
<lindi-> (having the host instrument the guest)
<fche> no recent changes; we've had 'run stap on host, target the guest' for quite some time
<fche> stap --remote=libvirt://....
<lindi-> and it could work also for VM userland processes?
mjw has joined #systemtap
<fche> sure should, -but- to process a stap script for the -particular- userland process versions, the host (or stap-server environment) would have to match the target guest's
<fche> we're (ssh, don't tell anyone) working on some more systemic automation for that kind of thing
<fche> but not done yet/soon
<lindi-> right, I need to investigate that
<fche> so it's your job to ensure userspace in the guest matches userspace in the host or whereever
<fche> if you'd like us to adopt a snapshot of your script into stap, that'd be cool, just post it sometimes
<fche> sometime<no s>
<lindi-> I've been hesitating since I want to make this more reliable
<lindi-> having automated testsuite on many distros would be cool
<fche> when you have to do distro-specific tricks (library path names / soname versions / debuginfo reliance), that may be too hard
<fche> sometimes a script can be a template for others
<fche> or be driven from a shell script that digs out actual distro-specific paths if required
<lindi-> maybe
<fche> https://sourceware.org/systemtap/examples/#io/ttyspy.stp <-- see also ... would be a kindred spirit
<lindi-> (some background: the Java specific version has already been public at https://github.com/nixu-corp/tls-secret-extractors for over a year)
<lindi-> in security audits it's very useful to get a global view of what's happening in some system, especially if you don't have source code
<fche> it looks like java is kind enough to pretty-print its own secrets to stdout if you run it with -Djavax.net.debug=all
<fche> how kind!
<lindi-> yes but you need some python to format them for tshark to read :)
<lindi-> fche: process("/usr/lib/x86_64-linux-gnu/libssl.so*") fails with "semantic error: while resolving probe point: identifier 'process' at"
<fche> lindi-, a more complete error message / script would probably help; you may need a "?" on the probe point, to cover cases where a library does -not- actually exist
<lindi-> ah, wrong version
<fche> SHIP IT
* fche must step out a while
ishcherb has quit [Ping timeout: 240 seconds]
<lindi-> ok ok, thanks a lot for the tips
<fche> you may be missing the tls1_generate_master_secret function
<fche> rather than have something wrong with the wildcard
<fche> anyway use more verbosity for next steps
bendlas has quit [Ping timeout: 246 seconds]
pwithnall[m] has quit [Ping timeout: 240 seconds]
<lindi-> but both /usr/lib/x86_64-linux-gnu/libssl.so.1.1 and /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2 work separately just fine
<fche> yeah not sure then. strace, all else failing
<lindi-> strace shows it accesses /usr/lib/x86_64-linux-gnu/libssl.so.1.1 and /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2
amerey has joined #systemtap
<lindi-> I'll try to minimize this
<lindi-> the failing case is doing
<lindi-> 485 access("/usr/lib/x86_64-linux-gnu/libssl.so.1.1", X_OK) = -1 EACCES (Permission denied)
<lindi-> the working case does not make this call at all
<lindi-> at least in debian 9 shared libraries don't have executable bit set
<lindi-> glob_executable indeed does this access() check so I can't use glob patterns
nkambo_ has joined #systemtap
cstratak has quit [Quit: Leaving]
nkambo__ has quit [Ping timeout: 240 seconds]
irker934 has joined #systemtap
<irker934> systemtap: dsmith systemtap.git:refs/heads/master * release-3.2-3-g1f4b9e5 / tapset-mark.cxx tapsets.cxx util.cxx util.h: Add string trim utility functions. http://tinyurl.com/ydfrwqff
<irker934> systemtap: dsmith systemtap.git:refs/heads/master * release-3.2-4-geb6f278 / client-http.cxx httpd/server.cxx httpd/server.h: Improve web service startup a bit. http://tinyurl.com/yafe5c4j
nkambo_ has quit [Ping timeout: 246 seconds]
<fche> lindi-, if that is stap code doing that X_OK access check, it probably should not. R_OK should be ample.
<fche> yeah, that's our bad it seems
<fche> would you like to send a one-liner patch ?
<lindi-> I can send it tomorrow while I'm in traveling and can run the testsuite
<lindi-> s/in //
<fche> neato
<lindi-> the --remote=libvirt support isn't in debian systemtap yet btw
<lindi-> (I know I could fix that but I'm lacking time :/)
<fche> didn't think that had big portability problems;
ishcherb has joined #systemtap
drsmith is now known as drsmith_away
drsmith_away is now known as drsmith
mjw has quit [Quit: Leaving]
ishcherb has quit [Ping timeout: 255 seconds]
nkambo_ has joined #systemtap
ppetraki has quit [Remote host closed the connection]
<irker934> systemtap: amerey systemtap.git:refs/heads/master * release-3.2-5-gc6be0dd / bpf-translate.cxx staptree.h: bpf translator: avoid attaching tags to format string more than once. http://tinyurl.com/y73lno7q
nkambo__ has joined #systemtap
nkambo_ has quit [Ping timeout: 240 seconds]
nkambo_ has joined #systemtap
nkambo__ has quit [Ping timeout: 240 seconds]
nkambo__ has joined #systemtap
nkambo_ has quit [Ping timeout: 246 seconds]
nkambo_ has joined #systemtap
nkambo__ has quit [Ping timeout: 264 seconds]
nkambo__ has joined #systemtap
nkambo_ has quit [Ping timeout: 246 seconds]
nkambo_ has joined #systemtap
nkambo__ has quit [Ping timeout: 246 seconds]
tromey has quit [Quit: ERC (IRC client for Emacs 26.0.60)]
wcohen has quit [Ping timeout: 255 seconds]
nkambo__ has joined #systemtap
nkambo_ has quit [Ping timeout: 246 seconds]
orivej has joined #systemtap
nkambo_ has joined #systemtap
nkambo__ has quit [Ping timeout: 252 seconds]
pwithnall[m] has joined #systemtap
nkambo__ has joined #systemtap
scox has quit [Ping timeout: 260 seconds]
nkambo_ has quit [Ping timeout: 246 seconds]
drsmith is now known as drsmith_away
nkambo_ has joined #systemtap
nkambo__ has quit [Ping timeout: 246 seconds]
bendlas has joined #systemtap
wcohen has joined #systemtap
nkambo__ has joined #systemtap
nkambo_ has quit [Ping timeout: 248 seconds]
nkambo_ has joined #systemtap
nkambo__ has quit [Ping timeout: 260 seconds]
nkambo__ has joined #systemtap
nkambo_ has quit [Ping timeout: 248 seconds]
orivej has quit [Ping timeout: 255 seconds]
scox has joined #systemtap