linux-kernel - Re: [PATCH][RFC 2/23]: SCST core

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 16 Dec 2008 23:13:44 +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:
>
>> > 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.


> 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...
--
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/