From: Rutger Hofman <rutger@cs.vu.nl>
To: ecos-discuss@ecos.sourceware.org
Subject: [ECOS] RedBoot xyModem bug
Date: Fri, 11 Jan 2008 15:24:00 -0000 [thread overview]
Message-ID: <47878A1F.3070607@cs.vu.nl> (raw)
Hello list,
I ran into a bug in RedBoot xyModem.c. It is in lines 420..434 in the
current version (cvs 1.21):
while (!xyz.at_eof && (size > 0)) {
... code for each block in the xyzModem protocols: ...
#if defined(xyzModem_zmodem) || defined(USE_YMODEM_LENGTH)
if (xyz.mode == xyzModem_xmodem ||
xyz.file_length == 0) {
#else
if (1) {
#endif
// Data blocks can be padded with ^Z (EOF)
characters
// This code tries to detect and remove them
if ((xyz.bufp[xyz.len-1] == EOF) &&
(xyz.bufp[xyz.len-2] == EOF) &&
(xyz.bufp[xyz.len-3] == EOF)) {
while (xyz.len && (xyz.bufp[xyz.len-1]
== EOF)) {
xyz.len--;
}
}
}
What this does, is inspect each uploaded block for trailing ^Z = 0x1a
bytes, and strip them. Rationale: xmodem or ymodem may signal
end-of-file with ^Z a.k.a. 'CP/M EOF', and may optionally pad the block
with more ^Z chars. This is live behaviour: sx and sy (0.12.20) under
Linux do ^Z padding in the last block. The xyModem.c code above is
wrong. ^Z chars are stripped at the end of *each block* in stead of at
the end of the file.
This problem surfaced when I enabled zlib in eCos. In one of its tables,
there is a sequence of bytes 26 = 0x1a = ^Z (in
packages/services/compress/zlib/current/src/trees.h, lines 90, 91,
112-114), which may trigger the test above. Depending on the offset in
the file, these 0x1a's hit a block boundary or not, and the file is
telescope-truncated or not. (I noticed that my executable crashed or not
depending on code size, even depending on a number of 'nop' assembly
instructions that I inserted anywhere in the code; it was a beast of a
bug to pin down...)
The fix is nonobvious to me. For ymodem, if #define USE_YMODEM_LENGTH is
on and a file length is specified, any trailing characters are removed
elsewhere: this works correctly. However, for xmodem or ymodem without
file length, any trailing ^Z at the end-of-file must still be removed.
The code above is inherently unaware whether this is the last block or
not: xmodem sends end-of-file control info, but that is consumed only in
the *next* block read. The solution might be to maintain one more
read-ahead block buffer to see if the current block is the last normal
block.
Some random remarks:
As a workaround (I dare not flash the RedBoot in my device, because we
bought it ready-made; I use the code base for my eCos application), I
tried disabling the table in zlib. That lead to another problem, which I
will report separately.
I am in the dark what must be done if a file to be xmodem'd actually
contains trailing ^Z characters. There is nothing that forbids that
outside CP/M or MS-DOS, I'd say.
I also wondered how this bug can have lived for so long in RedBoot. Or
doesn't anyone use xyModem nowadays?
Rutger Hofman
VU Amsterdam
--
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:[~2008-01-11 15:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-11 15:24 Rutger Hofman [this message]
2008-01-22 16:21 ` Rutger Hofman
2008-01-22 23:47 ` Gary Thomas
2008-01-24 7:26 ` Jürgen Lambrecht
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=47878A1F.3070607@cs.vu.nl \
--to=rutger@cs.vu.nl \
--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).