09:17 <lindi-> is there perhaps some existing recipe for recovering LUKS2 master key from kernel keyring with systemtap?

12:56 <fche> lindi-, well if the kernel knows it, stap can find it, I guess

18:51 <agentzh> running into a weird issue. user_long_error() throws out the "read fault" error, but using the exact virtual memory address to lookup the corresponding userland process's /proc/PID/pagemap, it shows the page is present, not swapped out, and has a Page Frame Number. what could it be?

19:08 <fche> not sure; is it readable?

19:14 <agentzh> how to tell if it's readable without triggering a read fault?

19:14 <agentzh> it's readable according to /proc/PID/maps

19:15 <fche> not sure .... could write a stap script that uses some inlined c code to do the read_from_user bit and see how that compares

19:15 <fche> or probe_read_blah

19:16 <agentzh> ah, that's clever. thanks for the suggestion

19:21 <fche> we do a little bit more than that but not much

19:21 <fche> set_fs (USER_DS) or somesuch

19:30 <agentzh> is it possible that the host machine swaps out the memory page while the kvm guest does not know about it?

19:31 <lindi-> agentzh: it should be transparent to the guest

19:31 <agentzh> lindi-: okay, so it won't be a page fault for the guest OS kernel?

19:32 <lindi-> agentzh: I would think the host would handle that

19:32 <agentzh> yeah, i also ready that the host OS will handle the page fault instead of the guest. thanks.

19:34 <fche> a fault at the host is different kind of thing than a fault at the gues

19:55 <agentzh> fche: okay, thanks

19:56 <agentzh> i wonder if it's possible to use module("foo").function("...") to probe on the kernel modules generated by some other stap scripts.

19:57 <agentzh> i used stap -p4 -m foo a.stp to generate a foo.ko file and then use staprun to keep it running. and then in another terminal, i use probe module("foo").function("*") in another .stp script but it says module("foo") cannot be resolved.

19:57 <agentzh> is this expected?

19:57 <fche> it's been done before

19:58 <fche> but the target stap module .ko file, ideally built with -BCONFIG_DEBUG_INFO=y must be findable by the second stap job

19:58 <agentzh> maybe i should use -d /path/to/foo.ko for the module("foo") script?

19:58 <fche> module("/path/to/foo.ko") more like it

19:58 <agentzh> okay, i see.

19:58 <agentzh> i'll try. thanks

19:58 <agentzh> is there any easy way to enable debug symbols in the resulting stap .ko module?

19:59 <agentzh> i can hack the stap source to enable it, but it is kinda bloody...

19:59 <fche> stap -BCONFIG_DEBUG_INFO=y

19:59 <fche> read your mind

19:59 <agentzh> oh, excellent.

20:00 <agentzh> thanks

20:04 <agentzh> fche: module("/path/to/foo.ko") works. thanks

20:05 <fche> there you go

20:05 <fche> hm, wonder who made that work

20:05 <agentzh> heh

20:05 <fche> was it you? :)

20:28 <agentzh> i don't think so...

20:53 <irker523> systemtap: fche systemtap.git:master * release-4.2-59-g91d1b6014 / tapsets.cxx: kernel tracepoint support update: clk, fsi, ib_*