From: Daniel Zebralla <daniel.zebralla@zebralla-it.de>
To: ecos-discuss@ecos.sourceware.org
Subject: [ECOS] CyaSSL library port (WIP): Space for struct corrupts other eCos-data in RAM
Date: Mon, 30 Sep 2013 08:55:00 -0000 [thread overview]
Message-ID: <1380531306664-245720.post@n7.nabble.com> (raw)
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
next reply other threads:[~2013-09-30 8:55 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-30 8:55 Daniel Zebralla [this message]
2013-10-11 8:18 ` [ECOS] " Daniel Zebralla
2013-10-11 9:16 ` Ross Younger
2013-10-14 7:59 ` Daniel Zebralla
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1380531306664-245720.post@n7.nabble.com \
--to=daniel.zebralla@zebralla-it.de \
--cc=ecos-discuss@ecos.sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).