Thanks! Great to know!
Aleksey
On 2/10/2010 9:25 PM, mahendra N wrote:
Hi Aleksey,
We were able to sort out the problem. We had to compile
our program with
XMLSEC_NO_SIZE_T flag before porting it to MIPS 64 bit system. Thanks
for all your time Aleksey.
Thanks and Regards,
Mahendra Naik
2010/2/4 mahendra N <[email protected] <mailto:[email protected]>>
Hi,
What should the function return. 0 or -1? Is the code piece
right..?..
Thanks an Regards,
Mahendra Naik
2010/2/4 Aleksey Sanin <[email protected]
<mailto:[email protected]>>
Ah, OK. I was looking at the other place.
Aleksey
On 2/3/2010 11:03 PM, mahendra N wrote:
Hi,
I have attached some comments inline
Thanks and Regards,
Mahendra Naik
2010/2/4 Aleksey Sanin <[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>
See my answers inline.
Aleksey
On 2/3/2010 10:15 PM, mahendra N wrote:
Hi Aleksey,
In /xmlSecDSigCtxVerify/ there are
calls to two
functions
/xmlSecDSigCtxProcessSignatureNode/ and
/xmlSecTransformVerifyNodeContent/
/ After the call to
x/mlSecDSigCtxProcessSignatureNode /there is
a check
placed for /
/ dSigCtx->status!=xmlSecDSigStatusUnknown .If
there is a
success
then the function returns 0. Is this check
absolutely necessary
at that
point in the code?. Because when we comment the
check and proceed
further, then /xmlSecTransformVerifyNodeContent
/returns -1 for
any XML
file that is tampered./
[Aleksey] The check there returns -1 if the status is
NOT equal to
xmlSecDSigStatusUnknown. This is a check to make sure
that we don't
have unexpected state in the signature. One of the
possible cases where
it might happen is if you are re-using the *same*
xmlDsigCtx for
multiple signatures w/o calling xmlSecDSigCtxFinalize().
The check returns 0 not -1.
I am attaching the code piece here.I've marked the
concerned part in
bold.
int xmlSecDSigCtxVerify(xmlSecDSigCtxPtr dsigCtx,
xmlNodePtr node) {
int ret;
xmlSecAssert2(dsigCtx != NULL, -1);
xmlSecAssert2(node != NULL, -1);
xmlSecAssert2(node->doc != NULL, -1);
/* add ids for Signature nodes */
dsigCtx->operation = xmlSecTransformOperationVerify;
dsigCtx->status = xmlSecDSigStatusUnknown;
xmlSecAddIDs(node->doc, node, xmlSecDSigIds);
/* read siganture info */
ret = xmlSecDSigCtxProcessSignatureNode(dsigCtx, node);
if(ret < 0) {
xmlSecError(XMLSEC_ERRORS_HERE,
NULL,
"xmlSecDSigCtxSigantureProcessNode",
XMLSEC_ERRORS_R_XMLSEC_FAILED,
XMLSEC_ERRORS_NO_MESSAGE);
return(-1);
}
xmlSecAssert2(dsigCtx->signMethod != NULL, -1);
xmlSecAssert2(dsigCtx->signValueNode != NULL, -1);
/* references processing might change the status */
*if(dsigCtx->status != xmlSecDSigStatusUnknown) {*
* return(0); *
* }*
/* verify SignatureValue node content */
ret = xmlSecTransformVerifyNodeContent(dsigCtx->signMethod,
dsigCtx->signValueNode,
&(dsigCtx->transformCtx));
if(ret < 0) {
xmlSecError(XMLSEC_ERRORS_HERE,
NULL,
"xmlSecTransformVerifyNodeContent",
XMLSEC_ERRORS_R_XMLSEC_FAILED,
XMLSEC_ERRORS_NO_MESSAGE);
return(-1);
}
/* set status and we are done */
if(dsigCtx->signMethod->status ==
xmlSecTransformStatusOk) {
dsigCtx->status = xmlSecDSigStatusSucceeded;
} else {
dsigCtx->status = xmlSecDSigStatusInvalid;
}
return(0);
}
/
/
/
/
/And I tried with purify tool, there was no memory
corruption
reported/
/./
/Aleksey the system where this error is reproduced
is a 64-bit, MIPS
architecture ,Windriver linux/
/
/
/.Are there any specific compiler flags to be set
for the above
mentioned configuration./
/
[Aleksey] No idea. Never used such a setup.
/
/
/
Some more investigation that was done:
(i) The unpredictable behaviour is due to mismatch
of memory
location
of status member of the structure struct xmlSecDSigCtx.
(ii) I tried to get the adress of each of the member
variable of
structure xmlSecDSigCtx. Please find it below.
Inside the ImplLibXml(our local file)
dsigCtx Address ( 4832286288) + size (8)
Address of userData(4832286288) + size(8)
Address of flags(4832286296) + size(4)
Address of flags2(4832286300) + size(4)
Address of keyInfoReadCtx(4832286304) + size(368)
Address of keyInfoWriteCtx(4832286672) + size(368)
Address of transformCtx(4832287040) + size(136)
Address of enabledReferenceUris(4832287176) + size(4)
Address of enabledReferenceTransforms(4832287184) +
size(8)
Address of referencePreExecuteCallback(4832287192) +
size(8)
Address of defSignMethodId(4832287200) + size(8)
Address of defC14NMethodId(4832287208) + size(8)
Address of defDigestMethodId(4832287216) + size(8)
Address of signKey(4832287224) + size(8)
Address of operation(4832287232) + size(4)
Address of result(4832287240) + size(8)
Address of status(4832287248) + size(4)
Address of signMethod(4832287256) + size(8)
Address of preSignMemBufMethod(4832287272) + size(8)
Address of signValueNode(4832287280) + size(8)
Address of id(4832287288) + size(8)
Address of signedInfoReferences(4832287296) + size(40)
Address of manifestReferences(4832287336) + size(40)
Address of reserved0(4832287376) + size(8)
Address of reserved1(4832287384) + size(8)
ImplLibXml **END**
Inside xmlsec
dsigCtx Address ( 4832286288) + size (8)
Address of userData(4832286288) + size(8)
Address of flags(4832286296) + size(4)
Address of flags2(4832286300) + size(4)
Address of keyInfoReadCtx(4832286304) + size(344)
Address of keyInfoWriteCtx(4832286648) + size(344)
Address of transformCtx(4832286992) + size(128)
Address of enabledReferenceUris(4832287120) + size(4)
Address of enabledReferenceTransforms(4832287128) +
size(8)
Address of referencePreExecuteCallback(4832287136) +
size(8)
Address of defSignMethodId(4832287144) + size(8)
Address of defC14NMethodId(4832287152) + size(8)
Address of defDigestMethodId(4832287160) + size(8)
Address of signKey(4832287168) + size(8)
Address of operation(4832287176) + size(4)
Address of result(4832287184) + size(8)
Address of status(4832287192) + size(4)
Address of signMethod(4832287200) + size(8)
Address of preSignMemBufMethod(4832287216) + size(8)
Address of signValueNode(4832287224) + size(8)
Address of id(4832287232) + size(8)
Address of signedInfoReferences(4832287240) + size(32)
Address of manifestReferences(4832287272) + size(32)
Address of reserved0(4832287304) + size(8)
Address of reserved1(4832287312) + size(8)
xmlSecDSigCtxVerify****************END**********
Please observe that the main culprit for mismatch of
memory
location are
three user defined data members
Address of keyInfoReadCtx(4832286304) + size(368) --
more 24 bytes
Address of keyInfoWriteCtx(4832286672) + size(368)
-- more 24 bytes
Address of transformCtx(4832287040) + size(136)
-- more 8 bytes.
But I find the consistency in case of status member
is that the
difference of location (i.e. between the status
member in xmlsec
and in
ImplLibXml )is always 56 bytes as above the memory
difference is
also 56
bytes.I feel issue on MIPS is somehow related to
memory mapping
issues.
[Aleksey] Bingo! As I said, it feels like you have a problem
with compiler flags. Check data alignment related flags
for xmlsec
compilation vs. your program compilation. This obviously
explains
why you can't reproduce this problem with xmlsec command
line tool.
_______________________________________________
xmlsec mailing list
[email protected]
http://www.aleksey.com/mailman/listinfo/xmlsec
