On Tue, 29 Jan 2019, Heiko Carstens wrote: > On Tue, Jan 29, 2019 at 05:32:49PM +0900, Masami Hiramatsu wrote: > > > > # cat trace > > > > <...>-18602 [000] d... 288289.847945: do_sys_open: (do_sys_open+0x0/0x238) filename_string=(fault) > > > > <...>-18602 [000] d... 288289.848586: do_sys_open: (do_sys_open+0x0/0x238) filename_string=(fault) > > > > <...>-18602 [000] d... 288289.852643: do_sys_open: (do_sys_open+0x0/0x238) filename_string=(fault) > > > > <...>-18602 [000] d... 288289.853202: do_sys_open: (do_sys_open+0x0/0x238) filename_string=(fault) > > > > ... > > > > > > > > I'm getting this on latest upstream 5.0.0-rc3+ > > > > > > > > looks like we call strncpy_from_unsafe -> __get_user, which fails > > > > in this case.. any idea if this is perhaps some known issue on s390x? > > > > > > This looks like the wrong address space is accessed. The "string" type > > > is supposed to copy a string from _kernel_ space while the filename > > > argument of do_sys_open() is a user space pointer. > > > > Right... since kprobes runs in interrupt(exception) handler, we can not > > sleep inside it, so accessing user-space can be failed. > > Well, this didn't fail because a user space page was not mapped, but > because a wrong address space with a different page table was used. > > If the kernel address space would have something mapped at the same > address like user space, then garbage would have been returned > instead. Well, good to say here that this scenario happens, practically undefined "garbage" occurs in the "strings" sometimes too. I am not any expert of this, but it looks like a data leak from the kernel-space... If I set a probe with a variable of some address which should be taken as a string and kernel just gives us back the data from there when the probe is hit, it doesn't look good. I hope I am wrong here. > > Still, this is a usage error. > > > > And if I'm correct it is not easy to "fix". _If_ this functionality is > > > desired then the kprobes interface must probably be changed so that it > > > would be possible to specify the address space from where something > > > should be copied. Or.. maybe the "__user" annotation in the kernel > > > code can be instrumented(?). > > > > No, I don't want to "fix" this. Describing in a document will be OK, > > but this is a limitation comes from its design. > > It could be fixed if e.g. a new ustring fetcharg type would be > supported, where we don't switch to KERNEL_DS. It would still fault > when the page isn't mapped, but would access the correct address > space. > > I don't know if it is really worth to implement this.. since I'm > afraid this will cause "some" problems ;) > >
