lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 17 Dec 2008 00:46:46 +0100 From: "Frédéric Weisbecker" <fweisbec@...il.com> To: "Ingo Molnar" <mingo@...e.hu> Cc: "Vladislav Bolkhovitin" <vst@...b.net>, "Steven Rostedt" <srostedt@...hat.com>, "Sam Ravnborg" <sam@...nborg.org>, linux-scsi@...r.kernel.org, "James Bottomley" <James.Bottomley@...senpartnership.com>, "Andrew Morton" <akpm@...ux-foundation.org>, "FUJITA Tomonori" <fujita.tomonori@....ntt.co.jp>, "Mike Christie" <michaelc@...wisc.edu>, "Jeff Garzik" <jeff@...zik.org>, "Boaz Harrosh" <bharrosh@...asas.com>, "Linus Torvalds" <torvalds@...ux-foundation.org>, linux-kernel@...r.kernel.org, scst-devel@...ts.sourceforge.net, "Bart Van Assche" <bart.vanassche@...il.com>, "Nicholas A. Bellinger" <nab@...ux-iscsi.org> Subject: Re: [PATCH][RFC 2/23]: SCST core 2008/12/16 Ingo Molnar <mingo@...e.hu>: > > * Frédéric Weisbecker <fweisbec@...il.com> wrote: > >> 2008/12/16 Ingo Molnar <mingo@...e.hu>: >> > >> > * Frédéric Weisbecker <fweisbec@...il.com> wrote: >> > >> >> > All the above functionality is almost what we need. The only thing >> >> > left, which I forgot to mention, is possibility to log also functions >> >> > return value on exit. This is what TRACE_EXIT_RES() in SCST does. Is >> >> > it possible to add those? >> >> >> >> I want to add that on the function graph tracer. That can be done pretty >> >> easily. The only problem comes with the type of the return value. Would >> >> this tracer be supposed to always return a 64 bits value regardless of >> >> the real typ of the value? There would be some pointless bytes on most >> >> return values. I don't know how to proceed for this problem. >> > >> > Things like mov ...,%eax are zero-extend so they'll zap the high 32 bits. >> >> >> That's right, but the problem occurs under 32 bits. The return values >> for 64 bits are in eax and edx. And most of the time, the high part >> (edx) will be junk. > > for wider types i'd suggest to just print the low bits. Most of the > interesting return types fit into machine word. > >> > The real problem are byte return values generated via things like: >> > >> > movb $1, %al >> > >> > those wont zero-extend, so you could get garbage in the output. One >> > approach would be to try a quick hack just to see how common a problem >> > this is. >> >> >> Yes, I will try something. >> >> > We could extract the return type from the debuginfo, hash it in a >> > read-mostly table and then look it up, but that seems complex both in >> > terms of build overhead and in terms of runtime overhead. >> >> I thought about it too and as you say it's rather complex. And thinking >> about non primitive types (like pid_t....) that would require a second >> pass of analysis to retrieve the corresponding primitive... > > structure returns would be rather evil to handle, agreed. > > Unrelated: > > it would be really nice if we could extend ftrace to trace system calls > and their parameters and return values. We used to have that in the > latency-tracer in -rt, and it was rather useful. Controlled by a > trace_option i guess - and blendable into any of the tracer outputs > (function tracer most notably). > > Explicit calls in the entry.S files would be OK for this - but maybe we > can get this via the tricky use of a TIF_ flags as well, to force the code > into the ptrace callbacks and then divert it for ftrace's pleasure? > > Ingo > I recently thought about making a syscalls tracer and only thought about the tracepoints. But that could be better to trace them and all the function they call with the function graph tracer. I think about the "graph" one because time of execution measure could be useful for the -rt development. I think that putting new calls on entryxx.S would be an overload and would overlap what already does ptrace on syscall entry/exit. So I like the idea of using the ptrace callbacks by manipulating the TIF_ flags. Yeah that's interesting. I will do that for 2.6.30 :-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists