public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] CyaSSL library port (WIP): Space for struct corrupts other eCos-data in RAM
@ 2013-09-30  8:55 Daniel Zebralla
  2013-10-11  8:18 ` [ECOS] " Daniel Zebralla
  0 siblings, 1 reply; 4+ messages in thread
From: Daniel Zebralla @ 2013-09-30  8:55 UTC (permalink / raw)
  To: ecos-discuss

I'm working on a port of the CyaSSL SSL library by WolfSSL [1] to eCos-3.0
running on a Freescale MPC5668.
The basic setup was quite simple and I was able to successfully run some of
the tests.
As soon as the tests started using structs though, I ran into weird problems
which turned out to be caused by memory being overwritten as soon as the
memory for the structs was set to 0 using the memset-function.

The problem happens for example when I try to test the RSA-function which
uses a variable "key" of type RsaKey:
  RsaKey key;

"RsaKey" is a struct with the following definition:
/* RSA */
typedef struct RsaKey {
    mp_int n, e, d, p, q, dP, dQ, u;
    int   type;                               /* public or private */
    void* heap;                               /* for user memory overrides
*/
#ifdef HAVE_CAVIUM
    /* Not set in my case, so I don't post content here */
#endif
} RsaKey;


The struct member "mp_int" is a typedef ...
    typedef fp_int mp_int;
... with "fp_int" being following struct:
/* a FP type */
typedef struct {
    fp_digit dp[FP_SIZE];
    int      used, 
             sign;
} fp_int;

"fp_digit" is a define:
    typedef unsigned int       fp_digit;



The system crashes after the function memset was called with the following
parameters:
s = 0x400031CC (the target address of "key")
c = 0
n = 552

This call overwrites 552 bytes of memory starting from address 0x400031CC.
This results in various variables needed by eCos in being 0ed and thus
corrupting the system context, causing a reboot of my hardware shortly
after.
I created commented screenshots of the memory space before the memset-call
[2] and after [3].

I've also made a posting about this issue on the CyaSSL forums [4], with no
answers so far. Note that addresses posted there are slightly different as
these were obtained by some previous debug-run.

[1] http://wolfssl.com/yaSSL/Products-cyassl.html
[2] http://oi41.tinypic.com/30bn4uv.jpg
[3] http://oi39.tinypic.com/ou8bcm.jpg
[4]
http://www.yassl.com/forums/topic431-fastmath-memset-for-rsakey-corrupts-memory-on-ecosport-wip.html

Can someone help in understanding the issue here as I'm not an C expert? It
seems like at some point different data type sizes are assumed, which leads
the compiler to put the struct in some place where not enough unused memory
resides!?

Thanks in advance!
- Daniel



--
View this message in context: http://sourceware-org.1504.n7.nabble.com/CyaSSL-library-port-WIP-Space-for-struct-corrupts-other-eCos-data-in-RAM-tp245720.html
Sent from the Sourceware - ecos-discuss mailing list archive at Nabble.com.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [ECOS] Re: CyaSSL library port (WIP): Space for struct corrupts other eCos-data in RAM
  2013-09-30  8:55 [ECOS] CyaSSL library port (WIP): Space for struct corrupts other eCos-data in RAM Daniel Zebralla
@ 2013-10-11  8:18 ` Daniel Zebralla
  2013-10-11  9:16   ` Ross Younger
  0 siblings, 1 reply; 4+ messages in thread
From: Daniel Zebralla @ 2013-10-11  8:18 UTC (permalink / raw)
  To: ecos-discuss

I now solved the problem by putting all CyaSSL-related stuff and tests into
an individual thread:

void create_TLS_thread(void)
{
	cyg_mutex_init(&cliblock_TLS);

	cyg_thread_create(
			TLS_THREAD_PRIOTITY,
			TLS_communication,
			(cyg_addrword_t) 1,
			"TLS Communication",
			(void *) tls_stack,
			sizeof(tls_stack),
			&TLS_Thread,
			&thread_tls
		);

	cyg_thread_resume(TLS_Thread);
	printf("TLS-Thread created!\n");
}

Suddenly, all tests complete successfully and no memory is corrupted.

Is there some general rule of thumb, that one should not do memory-intensive
work in the 'main'-thread?

Regards
- Daniel



--
View this message in context: http://sourceware-org.1504.n7.nabble.com/CyaSSL-library-port-WIP-Space-for-struct-corrupts-other-eCos-data-in-RAM-tp245720p247044.html
Sent from the Sourceware - ecos-discuss mailing list archive at Nabble.com.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [ECOS] Re: CyaSSL library port (WIP): Space for struct corrupts other eCos-data in RAM
  2013-10-11  8:18 ` [ECOS] " Daniel Zebralla
@ 2013-10-11  9:16   ` Ross Younger
  2013-10-14  7:59     ` Daniel Zebralla
  0 siblings, 1 reply; 4+ messages in thread
From: Ross Younger @ 2013-10-11  9:16 UTC (permalink / raw)
  To: ecos-discuss

On 11/10/13 21:18, Daniel Zebralla wrote:
> I now solved the problem by putting all CyaSSL-related stuff and tests into
> an individual thread:
 > Is there some general rule of thumb, that one should not do 
memory-intensive
 > work in the 'main'-thread?

Did you by any chance put your RsaKey struct on the stack, as opposed to 
static or malloced? Threads in eCos often have very small stacks; the 
corruption you describe sounds typical of a stack overrun.

You can find the stack size for the default ("main") thread in the .ecc 
file you're using.


Ross

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [ECOS] Re: CyaSSL library port (WIP): Space for struct corrupts other eCos-data in RAM
  2013-10-11  9:16   ` Ross Younger
@ 2013-10-14  7:59     ` Daniel Zebralla
  0 siblings, 0 replies; 4+ messages in thread
From: Daniel Zebralla @ 2013-10-14  7:59 UTC (permalink / raw)
  To: ecos-discuss

> Did you by any chance put your RsaKey struct on the stack, as opposed
> to static or malloced?

Yes, the RsaKey struct was put on the stack as I didn't really want to
change too much inside the code provided by CyaSSL, but at one point I tried
to allocate memory for the RsaKey struct using malloc and this struct then
indeed got correct memory. Unfortunately the test failed someplace later
then because of other structs being put on the stack as well. So I guess
changing *ALL* struct declarations to use malloc'd space would have done the
trick as well but would of course be quite some work and would have changed
the internal structure of the CyaSSL library significantly.

> You can find the stack size for the default ("main") thread in the .ecc
> file you're using. 

Thanks for the hint. I already tested this by setting the stack size to 32k
(iirc), but the tests still failed (don't know anymore if it was at the same
spot or later after further data was put on the stack).

I will stick to the individual thread-solution and provide a hint on this
issue with the port once it's done.

- Daniel



--
View this message in context: http://sourceware-org.1504.n7.nabble.com/CyaSSL-library-port-WIP-Space-for-struct-corrupts-other-eCos-data-in-RAM-tp245720p247311.html
Sent from the Sourceware - ecos-discuss mailing list archive at Nabble.com.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2013-10-14  7:59 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-09-30  8:55 [ECOS] CyaSSL library port (WIP): Space for struct corrupts other eCos-data in RAM Daniel Zebralla
2013-10-11  8:18 ` [ECOS] " Daniel Zebralla
2013-10-11  9:16   ` Ross Younger
2013-10-14  7:59     ` Daniel Zebralla

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).