Menu
▾
▴
valgrind-developers
|
From: Sunny D. <int...@ya...> - 2012-05-30 14:33:43
|
Folks, Someone had posted a patch back in 2008 to fix crashes in vmware backdoor code: http://comments.gmane.org/gmane.comp.debugging.valgrind.devel/5378 Does anybody know if these patches were incorporated? I am seeing the same crash in vmware_rpccmd function which is used by my daemon to talk to the vmware subsystem and was wondering if this patch made it. Thanks, -Sunny |
|
From: Sunny D. <int...@ya...> - 2012-05-30 15:09:29
|
The patch still seems to apply (after some path/file renaming) but it does not build. That answers my original question. But it raises a new one: Is anyone planning on fixing and merging that patch in? Thanks, -Sunny --- On Wed, 5/30/12, Sunny Das <int...@ya...> wrote: > From: Sunny Das <int...@ya...> > Subject: [Valgrind-developers] vmware backdoor patch > To: "val...@li..." <val...@li...> > Date: Wednesday, May 30, 2012, 7:33 AM > > > Folks, > > Someone had posted a patch back in 2008 to fix crashes in > vmware backdoor code: > > http://comments.gmane.org/gmane.comp.debugging.valgrind.devel/5378 > > Does anybody know if these patches were incorporated? I am > seeing the same crash in vmware_rpccmd function which is > used by my daemon to talk to the vmware subsystem and was > wondering if this patch made it. > > Thanks, > -Sunny > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's > security and > threat landscape has changed and how IT managers can > respond. Discussions > will include endpoint security, mobile security and the > latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Philippe W. <phi...@sk...> - 2012-05-30 18:30:26
|
On Wed, 2012-05-30 at 08:09 -0700, Sunny Das wrote:
> The patch still seems to apply (after some path/file renaming) but it does not build. That answers my original question. But it raises a new one:
>
> Is anyone planning on fixing and merging that patch in?
I have 0+epsilon intention to work on this patch,
the epsilon is to cover the unlikely case the vmware would donate
1_000_000 (1 million) dollars to support Valgrind development :).
(the patch is many lines, only to support vmware specific things,
not clear how to test thist, etc).
So, does not look very attractive to me.
Why not rather do that at "user level" ?
(i.e. in the vmware code or libraries, do something like:
if (RUNNING_ON_VALGRIND)
VALGRIND_NON_SIMD_CALLx(do_the_real_thing_on_the_real_cpu_function, args ...);
else
do_the_real_thing_on_the_real_cpu_function (args);
Looks to me this should have the effect desired, without introducing
hundreds of vmware backdoor thingies in Valgrind.
Philippe
|
|
From: Sunny D. <int...@ya...> - 2012-06-01 14:10:39
|
> VALGRIND_NON_SIMD_CALLx(do_the_real_thing_on_the_real_cpu_function, > args ...); The max version of this macro allows 3 args. The vmware backdoor needs 4 args. Is it possible to extend this to 4,5,6 args easily? -Stay Sunny! --- On Wed, 5/30/12, Philippe Waroquiers <phi...@sk...> wrote: > From: Philippe Waroquiers <phi...@sk...> > Subject: Re: [Valgrind-developers] vmware backdoor patch > To: "Sunny Das" <int...@ya...> > Cc: "val...@li..." <val...@li...> > Date: Wednesday, May 30, 2012, 11:30 AM > On Wed, 2012-05-30 at 08:09 -0700, > Sunny Das wrote: > > The patch still seems to apply (after some path/file > renaming) but it does not build. That answers my original > question. But it raises a new one: > > > > Is anyone planning on fixing and merging that patch > in? > I have 0+epsilon intention to work on this patch, > the epsilon is to cover the unlikely case the vmware would > donate > 1_000_000 (1 million) dollars to support Valgrind > development :). > > (the patch is many lines, only to support vmware specific > things, > not clear how to test thist, etc). > So, does not look very attractive to me. > > > Why not rather do that at "user level" ? > (i.e. in the vmware code or libraries, do something like: > > if (RUNNING_ON_VALGRIND) > > VALGRIND_NON_SIMD_CALLx(do_the_real_thing_on_the_real_cpu_function, > args ...); > else > > do_the_real_thing_on_the_real_cpu_function (args); > > Looks to me this should have the effect desired, without > introducing > hundreds of vmware backdoor thingies in Valgrind. > > Philippe > > > |
|
From: Sunny D. <int...@ya...> - 2012-06-01 14:47:56
|
Looks like we will need to change Vg_ClientRequest to add CLIENT_CALL4 and then just provide the CALL4 version of VALGRIND_NON_SIMD_CALLx. It also looks like it will be hard to go beyond 4 args. Is this doable? -Stay Sunny! --- On Fri, 6/1/12, Sunny Das <int...@ya...> wrote: > From: Sunny Das <int...@ya...> > Subject: Re: [Valgrind-developers] vmware backdoor patch > To: "Philippe Waroquiers" <phi...@sk...> > Cc: "val...@li..." <val...@li...> > Date: Friday, June 1, 2012, 7:10 AM > > > VALGRIND_NON_SIMD_CALLx(do_the_real_thing_on_the_real_cpu_function, > > args ...); > > The max version of this macro allows 3 args. The vmware > backdoor needs 4 args. Is it possible to extend this to > 4,5,6 args easily? > > -Stay Sunny! > > --- On Wed, 5/30/12, Philippe Waroquiers <phi...@sk...> > wrote: > > > From: Philippe Waroquiers <phi...@sk...> > > Subject: Re: [Valgrind-developers] vmware backdoor > patch > > To: "Sunny Das" <int...@ya...> > > Cc: "val...@li..." > <val...@li...> > > Date: Wednesday, May 30, 2012, 11:30 AM > > On Wed, 2012-05-30 at 08:09 -0700, > > Sunny Das wrote: > > > The patch still seems to apply (after some > path/file > > renaming) but it does not build. That answers my > original > > question. But it raises a new one: > > > > > > Is anyone planning on fixing and merging that > patch > > in? > > I have 0+epsilon intention to work on this patch, > > the epsilon is to cover the unlikely case the vmware > would > > donate > > 1_000_000 (1 million) dollars to support Valgrind > > development :). > > > > (the patch is many lines, only to support vmware > specific > > things, > > not clear how to test thist, etc). > > So, does not look very attractive to me. > > > > > > Why not rather do that at "user level" ? > > (i.e. in the vmware code or libraries, do something > like: > > > > if (RUNNING_ON_VALGRIND) > > > > > VALGRIND_NON_SIMD_CALLx(do_the_real_thing_on_the_real_cpu_function, > > args ...); > > else > > > > do_the_real_thing_on_the_real_cpu_function (args); > > > > Looks to me this should have the effect desired, > without > > introducing > > hundreds of vmware backdoor thingies in Valgrind. > > > > Philippe > > > > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's > security and > threat landscape has changed and how IT managers can > respond. Discussions > will include endpoint security, mobile security and the > latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Sunny D. <int...@ya...> - 2012-06-01 19:58:29
|
anybody? -Not so Sunny...:( ----- Original Message ----- From: Sunny Das <int...@ya...> To: Philippe Waroquiers <phi...@sk...> Cc: "val...@li..." <val...@li...> Sent: Friday, June 1, 2012 7:47 AM Subject: Re: [Valgrind-developers] vmware backdoor patch Looks like we will need to change Vg_ClientRequest to add CLIENT_CALL4 and then just provide the CALL4 version of VALGRIND_NON_SIMD_CALLx. It also looks like it will be hard to go beyond 4 args. Is this doable? -Stay Sunny! --- On Fri, 6/1/12, Sunny Das <int...@ya...> wrote: > From: Sunny Das <int...@ya...> > Subject: Re: [Valgrind-developers] vmware backdoor patch > To: "Philippe Waroquiers" <phi...@sk...> > Cc: "val...@li..." <val...@li...> > Date: Friday, June 1, 2012, 7:10 AM > > > VALGRIND_NON_SIMD_CALLx(do_the_real_thing_on_the_real_cpu_function, > > args ...); > > The max version of this macro allows 3 args. The vmware > backdoor needs 4 args. Is it possible to extend this to > 4,5,6 args easily? > > -Stay Sunny! > > --- On Wed, 5/30/12, Philippe Waroquiers <phi...@sk...> > wrote: > > > From: Philippe Waroquiers <phi...@sk...> > > Subject: Re: [Valgrind-developers] vmware backdoor > patch > > To: "Sunny Das" <int...@ya...> > > Cc: "val...@li..." > <val...@li...> > > Date: Wednesday, May 30, 2012, 11:30 AM > > On Wed, 2012-05-30 at 08:09 -0700, > > Sunny Das wrote: > > > The patch still seems to apply (after some > path/file > > renaming) but it does not build. That answers my > original > > question. But it raises a new one: > > > > > > Is anyone planning on fixing and merging that > patch > > in? > > I have 0+epsilon intention to work on this patch, > > the epsilon is to cover the unlikely case the vmware > would > > donate > > 1_000_000 (1 million) dollars to support Valgrind > > development :). > > > > (the patch is many lines, only to support vmware > specific > > things, > > not clear how to test thist, etc). > > So, does not look very attractive to me. > > > > > > Why not rather do that at "user level" ? > > (i.e. in the vmware code or libraries, do something > like: > > > > if (RUNNING_ON_VALGRIND) > > > > > VALGRIND_NON_SIMD_CALLx(do_the_real_thing_on_the_real_cpu_function, > > args ...); > > else > > > > do_the_real_thing_on_the_real_cpu_function (args); > > > > Looks to me this should have the effect desired, > without > > introducing > > hundreds of vmware backdoor thingies in Valgrind. > > > > Philippe > > > > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's > security and > threat landscape has changed and how IT managers can > respond. Discussions > will include endpoint security, mobile security and the > latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Valgrind-developers mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Philippe W. <phi...@sk...> - 2012-06-01 20:16:57
|
On Fri, 2012-06-01 at 07:47 -0700, Sunny Das wrote: > Looks like we will need to change Vg_ClientRequest to add CLIENT_CALL4 and then just provide the CALL4 version of VALGRIND_NON_SIMD_CALLx. > > It also looks like it will be hard to go beyond 4 args. Is this doable? It is probably doable (did not look) but I think you can work with the following: define a struct containing the needed x args call VALGRIND_NON_SIMD_CALL1( passing the address of the struct). Philippe |
|
From: Sunny D. <int...@ya...> - 2012-06-04 19:20:51
|
I managed to reduce the args to 3 and use CALL3. But it now crashes in another part of that backdoor function inside the native implementation: if (RUNNING_ON_VALGRIND) #ifndef WE_DO_NOT_CARE_ABOUT_CHECKING_THE_REPLY ret = VALGRIND_NON_SIMD_CALL3(__vmware_rpccmd, cmd_len, cmd, reply_buf); #else ret = VALGRIND_NON_SIMD_CALL2(__vmware_rpccmd, cmd_len, cmd); #endif else #ifdef WE_DO_NOT_CARE_ABOUT_CHECKING_THE_REPLY ret = __vmware_rpccmd(cmd_len, cmd); #else ret = __vmware_rpccmd(cmd_len, cmd, reply_buf); *reply_buf_siz = strlen(*reply_buf)+1; #endif The backtrace clearly shows the death occurred at the line ret = VALGRIND_NON_SIMD_CALL3(__vmware_rpccmd, cmd_len, cmd, reply_buf); Why would a function fail to run with VALGRIND_NON_SIMD_CALLx wrapper around it when it works natively fine? Thanks for your help! -Sunny ----- Original Message ----- From: Philippe Waroquiers <phi...@sk...> To: Sunny Das <int...@ya...> Cc: "val...@li..." <val...@li...> Sent: Friday, June 1, 2012 1:17 PM Subject: Re: [Valgrind-developers] vmware backdoor patch On Fri, 2012-06-01 at 07:47 -0700, Sunny Das wrote: > Looks like we will need to change Vg_ClientRequest to add CLIENT_CALL4 and then just provide the CALL4 version of VALGRIND_NON_SIMD_CALLx. > > It also looks like it will be hard to go beyond 4 args. Is this doable? It is probably doable (did not look) but I think you can work with the following: define a struct containing the needed x args call VALGRIND_NON_SIMD_CALL1( passing the address of the struct). Philippe |
|
From: Philippe W. <phi...@sk...> - 2012-06-04 19:45:57
|
On Mon, 2012-06-04 at 12:20 -0700, Sunny Das wrote:
> Why would a function fail to run with VALGRIND_NON_SIMD_CALLx wrapper around it when it works natively fine?
Maybe because the function is not exactly as documented in valgrind.h
for NON_SIMD calls :)
here is an extract
...
Note that the current ThreadId is inserted as the first argument.
So this call:
VALGRIND_NON_SIMD_CALL2(f, arg1, arg2)
requires f to have this signature:
Word f(Word tid, Word arg1, Word arg2)
where "Word" is a word-sized type.
...
So, take care to have your function strictly following the expected
layout. I suggest to read the full comment in valgrind.h
about the NON_SIMD calls.
Note: I never experimented with all these NON_SIMD calls, so this is all
theoretical advice ...
Philippe
|
|
From: Philippe W. <phi...@sk...> - 2012-06-04 19:54:47
|
On Mon, 2012-06-04 at 12:20 -0700, Sunny Das wrote: > #ifdef WE_DO_NOT_CARE_ABOUT_CHECKING_THE_REPLY > ret = __vmware_rpccmd(cmd_len, cmd); > #else > ret = __vmware_rpccmd(cmd_len, cmd, reply_buf); > *reply_buf_siz = strlen(*reply_buf)+1; > #endif Also it is not clear to me how __vmware_rpccmd would know if it has or not received the 3rd argument (reply_buf). and whether it can or cannot (try to) store a reply at that address. Philippe |
|
From: Sunny D. <int...@ya...> - 2012-06-04 23:01:37
|
reply_buf is only accessed under the macro WE_DO_NOT_CARE... in __vmware_rpccmd The first arg to __vmware_rpccmd is a size_t, 2nd and 3rd are pointers. -Sunny ----- Original Message ----- From: Philippe Waroquiers <phi...@sk...> To: Sunny Das <int...@ya...> Cc: "val...@li..." <val...@li...> Sent: Monday, June 4, 2012 12:55 PM Subject: Re: [Valgrind-developers] vmware backdoor patch On Mon, 2012-06-04 at 12:20 -0700, Sunny Das wrote: > #ifdef WE_DO_NOT_CARE_ABOUT_CHECKING_THE_REPLY > ret = __vmware_rpccmd(cmd_len, cmd); > #else > ret = __vmware_rpccmd(cmd_len, cmd, reply_buf); > *reply_buf_siz = strlen(*reply_buf)+1; > #endif Also it is not clear to me how __vmware_rpccmd would know if it has or not received the 3rd argument (reply_buf). and whether it can or cannot (try to) store a reply at that address. Philippe |
|
From: Philippe W. <phi...@sk...> - 2012-06-05 20:32:11
|
On Mon, 2012-06-04 at 16:01 -0700, Sunny Das wrote: > reply_buf is only accessed under the macro WE_DO_NOT_CARE... in __vmware_rpccmd > > > The first arg to __vmware_rpccmd is a size_t, 2nd and 3rd are pointers. This confirms your function does *not* follow the signature as documented in valgrind.h (missing tid argument). I suggest to read and strictly follow the valgrind.h comments about NON_SIMD calls. Philippe |
|
From: Sunny D. <int...@ya...> - 2012-06-06 04:34:20
|
Ok, thanks. adding TID as the first argument to the function got past that point and now its dying in a malloc() call. VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --5377-- si_code=1; Faulting address: 0x18; sp: 0x402bded80 valgrind: the 'impossible' happened: Killed by fatal signal ==5377== at 0x400CDA9: _dl_fixup (dl-runtime.c:108) ==5377== by 0x40133F4: _dl_runtime_resolve (dl-trampoline.S:41) ==5377== by 0xA68A4C8: __vmware_rpccmd (guestinfo_core.h:457) guestinfo_core.h:457 is a malloc. Any ideas what that _dl_fixup might be dying for at line 108 of dl-runtime.c? -Sunny ----- Original Message ----- From: Philippe Waroquiers <phi...@sk...> To: Sunny Das <int...@ya...> Cc: "val...@li..." <val...@li...> Sent: Tuesday, June 5, 2012 1:32 PM Subject: Re: [Valgrind-developers] vmware backdoor patch On Mon, 2012-06-04 at 16:01 -0700, Sunny Das wrote: > reply_buf is only accessed under the macro WE_DO_NOT_CARE... in __vmware_rpccmd > > > The first arg to __vmware_rpccmd is a size_t, 2nd and 3rd are pointers. This confirms your function does *not* follow the signature as documented in valgrind.h (missing tid argument). I suggest to read and strictly follow the valgrind.h comments about NON_SIMD calls. Philippe |
|
From: Philippe W. <phi...@sk...> - 2012-06-06 05:52:21
|
On Tue, 2012-06-05 at 21:34 -0700, Sunny Das wrote: > guestinfo_core.h:457 is a malloc. Any ideas what that _dl_fixup might be dying for at line 108 of dl-runtime.c? You will find the explanation in the 20 lines of comments of valgrind.h for the NON_SIMD calls. Your NON_SIMD call should preferably be limited to the strict minimum needed (i.e. the magical instruction sequence triggering the vmware backdoor). Philippe |
|
From: Sunny D. <int...@ya...> - 2012-06-06 14:14:55
|
So, basically, I can't do simple things like strlen, malloc....:( Man that sucks big time. How do I segregate the darn thing like that? And its someone else's code I am ripping apart. I can't have valgrind ignore a function, an object or a shared library completely in any form? This one thing is holding my project back. I mean I have leaks to be found and fixed in my project and I am lost in just getting valgrind to run...:( -Sunny ----- Original Message ----- From: Philippe Waroquiers <phi...@sk...> To: Sunny Das <int...@ya...> Cc: "val...@li..." <val...@li...> Sent: Tuesday, June 5, 2012 10:53 PM Subject: Re: [Valgrind-developers] vmware backdoor patch On Tue, 2012-06-05 at 21:34 -0700, Sunny Das wrote: > guestinfo_core.h:457 is a malloc. Any ideas what that _dl_fixup might be dying for at line 108 of dl-runtime.c? You will find the explanation in the 20 lines of comments of valgrind.h for the NON_SIMD calls. Your NON_SIMD call should preferably be limited to the strict minimum needed (i.e. the magical instruction sequence triggering the vmware backdoor). Philippe |
|
From: Philippe W. <phi...@sk...> - 2012-06-06 17:01:53
|
On Wed, 2012-06-06 at 07:14 -0700, Sunny Das wrote:
> So, basically, I can't do simple things like strlen, malloc....:( Man that sucks big time.
> How do I segregate the darn thing like that? And its someone else's code I am ripping apart.
Depending on the structure of this code, it might be easy or might be
very tricky.
If the special sequence(s) of instruction that triggers the vmware
backdoor is at well isolated and specific place(s), then it is should
be trivial to put an "if" around it.
So, something like:
...
surrounding code doing malloc/free/....
...
asm("... special instruction sequence of vmware")
...
some other code doing malloc/free/...
Then just replace the asm by:
if RUNNING_ON_VALGRIND
SIMD_CALL (valgrind_vmware_backdoor_fn, ...)
else
asm ("...")
keep all the rest as is,
and have your function valgrind_vmware_backdoor_fn doing the magical
instructions with the same asm sequence, and returning the values
as expected by the inline asm.
If there are several tricky interactions between the surrounding code
and the special asm, then I think it is still possible but more
of these valgrind specific fn will have to be written.
If you do not have access to the above code and cannot modify it (so,
if you just have a "vmware closed source library", then
you need to ask vmware developpers to do this for you.
Philippe
|
|
From: Sunny D. <int...@ya...> - 2012-06-06 23:08:49
|
I went ahead and ripped all the 8 functions out and replaced the part which does backdoor assembly into their own functions with correct signature, handling the returns properly. And I went past that issue of backdoor.
Now, I am running into another weird issue where valgrind crashed somewhere and I can't figure out where because the backtrace is all '??'. This happens even if I run the program inline inside the gdb. valgrind was built with splitdebug in gentoo and so was glibc. The valgrind debug symbols are all in /usr/lib/debug/usr/lib64/valgrind/ and /usr/lib/debug/usr/bin/valgrind.debug and glibc debug symbols are in/usr/lib/debug/lib64. Why is gdb refusing to give me a proper backtrace?
-Sunny
----- Original Message -----
From: Philippe Waroquiers <phi...@sk...>
To: Sunny Das <int...@ya...>
Cc: "val...@li..." <val...@li...>
Sent: Wednesday, June 6, 2012 10:02 AM
Subject: Re: [Valgrind-developers] vmware backdoor patch
On Wed, 2012-06-06 at 07:14 -0700, Sunny Das wrote:
> So, basically, I can't do simple things like strlen, malloc....:( Man that sucks big time.
> How do I segregate the darn thing like that? And its someone else's code I am ripping apart.
Depending on the structure of this code, it might be easy or might be
very tricky.
If the special sequence(s) of instruction that triggers the vmware
backdoor is at well isolated and specific place(s), then it is should
be trivial to put an "if" around it.
So, something like:
...
surrounding code doing malloc/free/....
...
asm("... special instruction sequence of vmware")
...
some other code doing malloc/free/...
Then just replace the asm by:
if RUNNING_ON_VALGRIND
SIMD_CALL (valgrind_vmware_backdoor_fn, ...)
else
asm ("...")
keep all the rest as is,
and have your function valgrind_vmware_backdoor_fn doing the magical
instructions with the same asm sequence, and returning the values
as expected by the inline asm.
If there are several tricky interactions between the surrounding code
and the special asm, then I think it is still possible but more
of these valgrind specific fn will have to be written.
If you do not have access to the above code and cannot modify it (so,
if you just have a "vmware closed source library", then
you need to ask vmware developpers to do this for you.
Philippe
|
|
From: Sunny D. <int...@ya...> - 2012-06-07 11:31:00
|
I forgot to mention that I can gdb my daemons perfectly fine with all the debug information like line numbers, local variables and code listing etc. Its only when valgrind crashes, the backtrace is all '??'.
-Sunny
----- Original Message -----
From: Sunny Das <int...@ya...>
To: Philippe Waroquiers <phi...@sk...>
Cc: "val...@li..." <val...@li...>
Sent: Wednesday, June 6, 2012 4:08 PM
Subject: Re: [Valgrind-developers] vmware backdoor patch
I went ahead and ripped all the 8 functions out and replaced the part which does backdoor assembly into their own functions with correct signature, handling the returns properly. And I went past that issue of backdoor.
Now, I am running into another weird issue where valgrind crashed somewhere and I can't figure out where because the backtrace is all '??'. This happens even if I run the program inline inside the gdb. valgrind was built with splitdebug in gentoo and so was glibc. The valgrind debug symbols are all in /usr/lib/debug/usr/lib64/valgrind/ and /usr/lib/debug/usr/bin/valgrind.debug and glibc debug symbols are in/usr/lib/debug/lib64. Why is gdb refusing to give me a proper backtrace?
-Sunny
----- Original Message -----
From: Philippe Waroquiers <phi...@sk...>
To: Sunny Das <int...@ya...>
Cc: "val...@li..." <val...@li...>
Sent: Wednesday, June 6, 2012 10:02 AM
Subject: Re: [Valgrind-developers] vmware backdoor patch
On Wed, 2012-06-06 at 07:14 -0700, Sunny Das wrote:
> So, basically, I can't do simple things like strlen, malloc....:( Man that sucks big time.
> How do I segregate the darn thing like that? And its someone else's code I am ripping apart.
Depending on the structure of this code, it might be easy or might be
very tricky.
If the special sequence(s) of instruction that triggers the vmware
backdoor is at well isolated and specific place(s), then it is should
be trivial to put an "if" around it.
So, something like:
...
surrounding code doing malloc/free/....
...
asm("... special instruction sequence of vmware")
...
some other code doing malloc/free/...
Then just replace the asm by:
if RUNNING_ON_VALGRIND
SIMD_CALL (valgrind_vmware_backdoor_fn, ...)
else
asm ("...")
keep all the rest as is,
and have your function valgrind_vmware_backdoor_fn doing the magical
instructions with the same asm sequence, and returning the values
as expected by the inline asm.
If there are several tricky interactions between the surrounding code
and the special asm, then I think it is still possible but more
of these valgrind specific fn will have to be written.
If you do not have access to the above code and cannot modify it (so,
if you just have a "vmware closed source library", then
you need to ask vmware developpers to do this for you.
Philippe
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Valgrind-developers mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|
|
From: Philippe W. <phi...@sk...> - 2012-06-07 17:37:58
|
On Wed, 2012-06-06 at 16:08 -0700, Sunny Das wrote: > I went ahead and ripped all the 8 functions out and replaced the > part which does backdoor assembly into their own functions with correct signature, > handling the returns properly. And I went past that issue of backdoor. That is good news. > > Now, I am running into another weird issue where valgrind crashed > somewhere and I can't figure out where because the backtrace is > all '??'. This happens even if I run the program inline inside > the gdb. valgrind was built with splitdebug in gentoo and so was glibc. > The valgrind debug symbols are all in /usr/lib/debug/usr/lib64/valgrind/ > and /usr/lib/debug/usr/bin/valgrind.debug and glibc debug symbols are > in/usr/lib/debug/lib64. Why is gdb refusing to give me a proper backtrace? Might be because the problem happens in JITted code (i.e. the code dynamically generated by Valgrind starting from your application code). GDB then does not have any information about what these program counters could be. Now, if Valgrind is "internally" crashing, usually (at least for me), it outputs a nice crash message, giving its own backtrace, and a backtrace for all the "application threads". It would help to have some info such as: * which Valgrind version * what is the exact crash message you get If you obtain no stacktrace at all, I would suggest to avoid compiling V with separate debug info. Philippe |
|
From: Sunny D. <int...@ya...> - 2012-06-07 19:34:43
|
Philippe, I am using valgrind-3.6.1, which is the stable version on Gentoo. Here is the message: ==5377== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==5377== Access not within mapped region at address 0x100000008 Looks like process died, not the valgrind. Other than that message in the end, the log file consists of backtraces of usual 'invalid reads' and some non-leak leaks etc. There is a core file created which when I do a 'file' on, it says core was generated by valgrind, but gdb'ing it with valgrind or my binary doesn't produce a valid backtrace. Note that I can gdb both valgrind and my binary with line numbers and all debugs perfectly fine. Do u think its died in tricky JITted code? How do I debug this? I am slipping deadlines here...:( I have used valgrind for a very long time and never gotten stuck like this. Thanks for all the help. I appreciate it. -Sunny ----- Original Message ----- From: Philippe Waroquiers <phi...@sk...> To: Sunny Das <int...@ya...> Cc: "val...@li..." <val...@li...> Sent: Thursday, June 7, 2012 10:37 AM Subject: Re: [Valgrind-developers] vmware backdoor patch On Wed, 2012-06-06 at 16:08 -0700, Sunny Das wrote: > I went ahead and ripped all the 8 functions out and replaced the > part which does backdoor assembly into their own functions with correct signature, > handling the returns properly. And I went past that issue of backdoor. That is good news. > > Now, I am running into another weird issue where valgrind crashed > somewhere and I can't figure out where because the backtrace is > all '??'. This happens even if I run the program inline inside > the gdb. valgrind was built with splitdebug in gentoo and so was glibc. > The valgrind debug symbols are all in /usr/lib/debug/usr/lib64/valgrind/ > and /usr/lib/debug/usr/bin/valgrind.debug and glibc debug symbols are > in/usr/lib/debug/lib64. Why is gdb refusing to give me a proper backtrace? Might be because the problem happens in JITted code (i.e. the code dynamically generated by Valgrind starting from your application code). GDB then does not have any information about what these program counters could be. Now, if Valgrind is "internally" crashing, usually (at least for me), it outputs a nice crash message, giving its own backtrace, and a backtrace for all the "application threads". It would help to have some info such as: * which Valgrind version * what is the exact crash message you get If you obtain no stacktrace at all, I would suggest to avoid compiling V with separate debug info. Philippe |
|
From: Philippe W. <phi...@sk...> - 2012-06-07 20:09:12
|
On Thu, 2012-06-07 at 12:33 -0700, Sunny Das wrote: > Philippe, > > I am using valgrind-3.6.1, which is the stable version on Gentoo. > > Here is the message: > ==5377== Process terminating with default action of signal 11 (SIGSEGV): dumping core > ==5377== Access not within mapped region at address 0x100000008 This might be caused by a bug in your program. > Do u think its died in tricky JITted code? How do I debug this? > I am slipping deadlines here...:( I have used valgrind for a very > long time and never gotten stuck like this. JITted code will be the translation of the application code. To debug it, you must upgrade to Valgrind 3.7.0. This version has an embedded gdbserver, which means you can debug your application under Valgrind and e.g. understand where this 0x100000008 is coming from. Just start Valgrind as usual, but give option --vgdb-error=0 and follow the instructions on the screen. The 3.7.0 user manual has a specific chapter about how to use the V gdbserver. It contains a lot of useful information. Philippe |
|
From: Philippe W. <phi...@sk...> - 2012-06-07 20:17:54
|
On Thu, 2012-06-07 at 12:33 -0700, Sunny Das wrote: > Looks like process died, not the valgrind. Other than that message in the end, > the log file consists of backtraces of usual 'invalid reads' Also, invalid reads should better be fixed (or at least understood and proved "safe"), as these invalid reads might cause e.g. access to unmapped memory, causing a SEGV. Again, the 3.7.0 V gdbserver will help to understand what is going on. Philippe |
|
From: Sunny D. <int...@ya...> - 2012-06-07 20:23:16
|
Those invalid reads are from pth and are understood to be safe to ignore. I had tried 3.7.0 while debugging the earlier issue but reverted back to stable to reduce the moving parts. May be, now that I am past the backdoor, I can go back to 3.7.0. -Sunny ----- Original Message ----- From: Philippe Waroquiers <phi...@sk...> To: Sunny Das <int...@ya...> Cc: "val...@li..." <val...@li...> Sent: Thursday, June 7, 2012 1:17 PM Subject: Re: [Valgrind-developers] vmware backdoor patch On Thu, 2012-06-07 at 12:33 -0700, Sunny Das wrote: > Looks like process died, not the valgrind. Other than that message in the end, > the log file consists of backtraces of usual 'invalid reads' Also, invalid reads should better be fixed (or at least understood and proved "safe"), as these invalid reads might cause e.g. access to unmapped memory, causing a SEGV. Again, the 3.7.0 V gdbserver will help to understand what is going on. Philippe |
|
From: Sunil K. <int...@ya...> - 2012-05-30 18:39:33
|
Stupid question: are RUNNING_ON_VALGRIND and VALGRIND_NON_SIMD_CALLx real macros? Thanks, Stay Sunny ________________________________ From: Philippe Waroquiers <phi...@sk...> To: Sunny Das <int...@ya...> Cc: "val...@li..." <val...@li...> Sent: Wednesday, May 30, 2012 11:30 AM Subject: Re: [Valgrind-developers] vmware backdoor patch On Wed, 2012-05-30 at 08:09 -0700, Sunny Das wrote: > The patch still seems to apply (after some path/file renaming) but it does not build. That answers my original question. But it raises a new one: > > Is anyone planning on fixing and merging that patch in? I have 0+epsilon intention to work on this patch, the epsilon is to cover the unlikely case the vmware would donate 1_000_000 (1 million) dollars to support Valgrind development :). (the patch is many lines, only to support vmware specific things, not clear how to test thist, etc). So, does not look very attractive to me. Why not rather do that at "user level" ? (i.e. in the vmware code or libraries, do something like: if (RUNNING_ON_VALGRIND) VALGRIND_NON_SIMD_CALLx(do_the_real_thing_on_the_real_cpu_function, args ...); else do_the_real_thing_on_the_real_cpu_function (args); Looks to me this should have the effect desired, without introducing hundreds of vmware backdoor thingies in Valgrind. Philippe |
|
From: Philippe W. <phi...@sk...> - 2012-05-30 23:44:16
|
On Wed, 2012-05-30 at 11:38 -0700, Sunil Kumar wrote: > Stupid question: are RUNNING_ON_VALGRIND and VALGRIND_NON_SIMD_CALLx > real macros? Note that depending on the nr of args the fn has, you have to use the correct VALGRIND_NON_SIMD_CALL macro (see valgrind.h). So, at the end, VALGRIND_NON_SIMD_CALLx is not a real macro, it was just a shortcut for me to say "either 0 or 1 or 2 or 3" (not too sure how many macros there are). Philippe |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X