This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: RE: Fixes to RedBoot "load" command
- From: Gary Thomas <gary at mlbassoc dot com>
- To: Gary Parnes <GaryP at logicpd dot com>
- Cc: eCos Discussion <ecos-discuss at ecos dot sourceware dot org>
- Date: Fri, 23 Apr 2004 15:17:56 -0600
- Subject: Re: [ECOS] RE: Fixes to RedBoot "load" command
- Organization: MLB Associates
- References: <31ADFA827355984B9E2A161514595B560E41A8@lpdsrv04.logicpd.com>
On Fri, 2004-04-23 at 14:56, Gary Parnes wrote:
> I see a potential vulnerability in the CYG_ASSERT() that is watching for
> code that overshoots the opts[] array. It is checking the value of
> num_options against a constant. But, num_options is also resident on the
> stack. Writing beyond the bounds of the opts[] array COULD end up
> corrupting the value of num_options itself (it all depends on how the
> compiler arranges things on the stack), and so it could result in a "false
> positive" in the CYG_ASSERT().
Appreciated, but how far must one go? Stack overflows can cause all
sorts of erratic behaviour and little is ever certain after it occurs.
The assert clearly states what the requisites are. If someone alters
a routine which uses such a variable array, it should be clear from
reading the code what to be careful of. If he doesn't read the code,
then the peril is on only himself.
>
> I starting to think that the options mechanism needs to be reworked.
> Perhaps the opts[] array could be embedded in a structure that tracks the
> count and the max?
I think that it's already too heavy (it got out of hand over time) and
I have no inclination to make it more so.
Thanks for your input and the discovery of the error which has now been
repaired.
--
Gary Thomas <gary@mlbassoc.com>
MLB Associates
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss