UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
814 Views
Registered: ‎03-03-2011

Return variable initialisation affecting function!

Jump to solution

I have recently been playing with an ECC library targetting bare metal Zynq (ZC706). I have a bizarre scenario where if I initialise a variable used to store a return value to anything but 1 the function that returns to that variable fails. 

What i'm doing is testing the ecdsa_verify() function. I'm initialising some arrays with public key, a test message hash and the signed version of that hash (with the associated private key). I then have to generate the compressed public key as that is what the ecdsa_verify() function expects, this is fairly trivial as the code shows. I then call the ecdsa_verify() function with the relevant arguments and check the return value for success or failure.

I then modify the [0] element of the hash to check that if I run the test again it fails.

As mentioned previously, this works as long as the int return variable 'ret' is initialised to 1. Anything else ('0' or unitialised) and the ecdsa_verify will fail both tests rather than passing the first test and failing the second.

If anyone has any explanation as to what might be causing this I would be greatful to hear it.

The easy_ecc library i'm playing with is:

https://github.com/esxgx/easy-ecc

I've attached the main application file (helloecc.c) and the easy_ecc source to this post in case anyone is interested enough to see this for themselves (long shot I know!)

Vivado/SDK 2017.4

I've also tried SDK 2018.2 but same result.

TIA

 

Tags (3)
0 Kudos
1 Solution

Accepted Solutions
Teacher xilinxacct
Teacher
803 Views
Registered: ‎10-23-2018

Re: Return variable initialisation affecting function!

Jump to solution

@adrian.h 

It appears there are several SYNCHK errors... so, maybe you are not getting all the 'hardware' you think you are...

ERROR: [SYNCHK 200-42] ecc/ecc.c:1299: pointer comparison is not supported. ecc:solution1 Feb 20, 2019, 9:17:56 AM
ERROR: [SYNCHK 200-11] ecc/ecc.c:1284: Variable 'l_points' has an unsynthesizable type '[4 x %struct.EccPoint.0.2.4*]*'
(possible cause(s): pointer to pointer or global pointer). ecc:solution1 Feb 20, 2019, 9:17:56 AM
ERROR: [SYNCHK 200-11] ecc/ecc.c:1274: Variable 'l_sum' has an unsynthesizable type 'EccPoint' (possible cause(s):
structure variable cannot be decomposed due to (1) unsupported type conversion; (2) memory copy operation; (3) function
pointer used in struct; (4) unsupported pointer comparison). ecc:solution1 Feb 20, 2019, 9:17:56 AM
ERROR: [SYNCHK 200-61] ecc/ecc.c:280: unsupported memory access on variable 'p_left' which is (or contains) an array
with unknown size at compile time. ecc:solution1 Feb 20, 2019, 9:17:56 AM

 

Although some of that maybe random stuff that HLS does from time to time...

The warning may be more real....

ecc/ecc_t.c:44:26: warning: array index 64 is past the end of the array (which contains 64 elements) [-Warray-bounds]
pubKeyComp[0] = 2 + (pubKey[32*2] & 0x01);

Hope that helps

If so, please mark as solution accepted. Kudos also welcomed. :-)

View solution in original post

5 Replies
Teacher xilinxacct
Teacher
804 Views
Registered: ‎10-23-2018

Re: Return variable initialisation affecting function!

Jump to solution

@adrian.h 

It appears there are several SYNCHK errors... so, maybe you are not getting all the 'hardware' you think you are...

ERROR: [SYNCHK 200-42] ecc/ecc.c:1299: pointer comparison is not supported. ecc:solution1 Feb 20, 2019, 9:17:56 AM
ERROR: [SYNCHK 200-11] ecc/ecc.c:1284: Variable 'l_points' has an unsynthesizable type '[4 x %struct.EccPoint.0.2.4*]*'
(possible cause(s): pointer to pointer or global pointer). ecc:solution1 Feb 20, 2019, 9:17:56 AM
ERROR: [SYNCHK 200-11] ecc/ecc.c:1274: Variable 'l_sum' has an unsynthesizable type 'EccPoint' (possible cause(s):
structure variable cannot be decomposed due to (1) unsupported type conversion; (2) memory copy operation; (3) function
pointer used in struct; (4) unsupported pointer comparison). ecc:solution1 Feb 20, 2019, 9:17:56 AM
ERROR: [SYNCHK 200-61] ecc/ecc.c:280: unsupported memory access on variable 'p_left' which is (or contains) an array
with unknown size at compile time. ecc:solution1 Feb 20, 2019, 9:17:56 AM

 

Although some of that maybe random stuff that HLS does from time to time...

The warning may be more real....

ecc/ecc_t.c:44:26: warning: array index 64 is past the end of the array (which contains 64 elements) [-Warray-bounds]
pubKeyComp[0] = 2 + (pubKey[32*2] & 0x01);

Hope that helps

If so, please mark as solution accepted. Kudos also welcomed. :-)

View solution in original post

Explorer
Explorer
798 Views
Registered: ‎03-03-2011

Re: Return variable initialisation affecting function!

Jump to solution

@xilinxacct 

Are you thinking i'm attempting to target this at gates? in HLS? I'm not, just trying to run C code on the ARM core of a Zynq.

0 Kudos
Teacher xilinxacct
Teacher
794 Views
Registered: ‎10-23-2018

Re: Return variable initialisation affecting function!

Jump to solution

Yes, I was trying in HLS... :-)

But the array out of bounds probably applies

0 Kudos
Explorer
Explorer
777 Views
Registered: ‎03-03-2011

Re: Return variable initialisation affecting function!

Jump to solution

@xilinxacct 

And you'd be correct!

Although i'm not sure why the initialisation of the 'ret' variable made this work/not work. Fixing the bug you spotted appears to have fixed the issue.

Interestingly, I didn't see any complaints from the compiler about the fact I was indexing beyond that array. Is that a 'C' thing though? It assumes you know what you're doing! :)

 

0 Kudos
Explorer
Explorer
771 Views
Registered: ‎03-03-2011

Re: Return variable initialisation affecting function!

Jump to solution

Thinking about it I think I can see what was happening. The array I was incorrectly indexing beyond was used to generate the public compressed key. I assume it's feasible this return variable 'ret' could've been sat next to that array in memory, so that's what was getting picked up by the out of bounds index.

Every day's a school day.....

0 Kudos