[ECOS] running ecos application on redboot

[ECOS] running ecos application on redboot

[Atilay Yilmaz]

Hi, I have been trying running an ecos application in elf format.
whether or not I set address, it doesn't work:

RAM: 0x20800000-0x24000000, [0x2081fd80-0x23fed000] available
FLASH: 0x30000000 - 0x30400000, 64 blocks of 0x00010000 bytes each
RedBoot> load -v -m tftp -h 192.168.3.18 PNIO4ECOS
*** Abort! Attempt to load ELF data to address: 0x20800054 which i
s not valid
RedBoot> load -v -m tftp -h 192.168.3.18 PNIO4ECOS -b 0x2081fd80
Address offset = 0x0001fd80
Entry point: 0x2081fee8, address range: 0x2081fd80-0x209802fc
RedBoot> go 0x2081fee8
<no response>

do I have to create a new elf with new memory settings or is there a
way to make it work?

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

Re: [ECOS] running ecos application on redboot

[Andrew Lunn]

On Fri, Mar 27, 2009 at 03:28:09PM +0200, Atilay Yilmaz wrote:
> Hi, I have been trying running an ecos application in elf format.
> whether or not I set address, it doesn't work:
> 
> RAM: 0x20800000-0x24000000, [0x2081fd80-0x23fed000] available

This tells you what is wrong...


> FLASH: 0x30000000 - 0x30400000, 64 blocks of 0x00010000 bytes each
> RedBoot> load -v -m tftp -h 192.168.3.18 PNIO4ECOS
> *** Abort! Attempt to load ELF data to address: 0x20800054 which i
> s not valid

I presume you have a RAM redboot.  You also appear to have a RAM
application. Both want to load at the same location in RAM. This will
not work. You need to move the application up in memory. 0x20820000
would be a good location.

      Andrew

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

Re: [ECOS] RE: Security issue with bsd stack

[Marcos Del Puerto]

A capture of the datagram which caused the error with wireshark or
some other sniffer could be useful. Anyway IMHO the solution would be
as follows:

* Short answer: Replace panic("icmp len") with a logging function
(printf of whatever), then a call to freeit and finish the function
execution with return.

*Explanation: In the BSD TCP/IP stack m->m_data would point to the IP
header and m->m_pktdat to 16 (ethernet header) or 72 bytes (ethernet
header + IP options) before m_data . If (m->m_data - sizeof(struct ip)
< m->m_pktdat) I would say that the IP header was malformed and wasn't
properly parsed in the m_buf so IMHO you can discard it and not
sending the ICMP message. (I think Linux, for example,  expects that
the original datagram's header is properly formed, otherwise no ICMP
answer is sent).

I hope it helps.

Best regards,
Marcos Del Puerto

On Tue, Mar 31, 2009 at 8:33 PM, Saritha Yellanki <ysaritha@broadcom.com> wrote:
>  More info on the ISIC can be found at <http://www.packetfactory.net/projects/ISIC/>
>
> Thanks
> saritha
>
>
> -----Original Message-----
> From: Saritha Yellanki
> Sent: Tuesday, March 31, 2009 11:59 PM
> To: 'ecos-discuss'
> Subject: Security issue with bsd stack
>
> Hi All,
>
> I am testing our ecos system  with bsd tcp/ip stack with ISIC tool (ISIC -- IP Stack Integrity Checker)  and found an issue as mentioned below
>
> Description:
>
> (ISIC is a suite of utilities to exercise the stability of an IP Stack and its component stacks (TCP, UDP, ICMP et. al.) It generates piles of pseudo random packets of the target protocol. The packets be given tendancies to conform to. Ie 50% of the packets generated can have IP Options. 25% of the packets can be IP fragments... But the percentages are arbitrary and most of the packet fields have a configurable tendancy.)
>
> When  we send stream of packets  using the command  "tcpsic -s 10.10.10.10,23 -d 10.10.10.100 -I 100" ,our system hangs ,and we  observed that  the  code ( panic ("icmp len") )  highlighted  below was hit , when  we run the above test case
>
> What should be the correct behaviour?
> Could you please give your inputs or opinion on how to handle this case ?
>
> Thanks
> saritha
>
> Details of the Panic message
> ============================
> In  the file "src/sys/netinet/ip_icmp.c"
>
> /*
>  * Generate an error packet of type error
>  * in response to bad packet ip.
>  */
> void
> icmp_error(n, type, code, dest, destifp)
>  struct mbuf *n;
>  int type, code;
>  n_long dest;
>  struct ifnet *destifp;
>
> {
>  register struct ip *oip = mtod(n, struct ip *), *nip;
>  register unsigned oiplen = IP_VHL_HL(oip->ip_vhl) << 2;
>  register struct icmp *icp;
>  register struct mbuf *m;
>  unsigned icmplen;
>   .......
>   ..........
>
>     /*
>   * Now, copy old ip header (without options)
>   * in front of icmp message.
>     if (m->m_data - sizeof(struct ip) < m->m_pktdat)
>       panic("icmp len");                                                   //////////////////////////////////////////  This PANIC OCCURED when the test case was run  //////////////////////////////////
>
>  ..............
>  ............
>
> }
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
>

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

RE: [ECOS] RE: Security issue with bsd stack

[Saritha Yellanki]

Hi  Marcos Del Puerto,

Thank you for your inputs. We have made the change and it is fine.

 ..................................................
 /*
   * Now, copy old ip header (without options)
   * in front of icmp message.
   */
  if (m->m_data - sizeof(struct ip) < m->m_pktdat)
   {
    diag_printf("error: icmp len!\n");
    m_free(m);
    goto freeit;
    /*  panic("icmp len"); */

   }
 ..............................................

With this change , we have tested it. And it works fine. We sent traffic to the system ( ran the tool)  for substantial  amount of time. We did not see any issues.

Thanks  a lot.
Saritha.


-----Original Message-----
From: Marcos Del Puerto [mailto:mpuertog@gmail.com] 
Sent: Wednesday, April 01, 2009 4:29 PM
To: Saritha Yellanki
Cc: ecos-discuss
Subject: Re: [ECOS] RE: Security issue with bsd stack

A capture of the datagram which caused the error with wireshark or
some other sniffer could be useful. Anyway IMHO the solution would be
as follows:

* Short answer: Replace panic("icmp len") with a logging function
(printf of whatever), then a call to freeit and finish the function
execution with return.

*Explanation: In the BSD TCP/IP stack m->m_data would point to the IP
header and m->m_pktdat to 16 (ethernet header) or 72 bytes (ethernet
header + IP options) before m_data . If (m->m_data - sizeof(struct ip)
< m->m_pktdat) I would say that the IP header was malformed and wasn't
properly parsed in the m_buf so IMHO you can discard it and not
sending the ICMP message. (I think Linux, for example,  expects that
the original datagram's header is properly formed, otherwise no ICMP
answer is sent).

I hope it helps.

Best regards,
Marcos Del Puerto

On Tue, Mar 31, 2009 at 8:33 PM, Saritha Yellanki <ysaritha@broadcom.com> wrote:
>  More info on the ISIC can be found at <http://www.packetfactory.net/projects/ISIC/>
>
> Thanks
> saritha
>
>
> -----Original Message-----
> From: Saritha Yellanki
> Sent: Tuesday, March 31, 2009 11:59 PM
> To: 'ecos-discuss'
> Subject: Security issue with bsd stack
>
> Hi All,
>
> I am testing our ecos system  with bsd tcp/ip stack with ISIC tool (ISIC -- IP Stack Integrity Checker)  and found an issue as mentioned below
>
> Description:
>
> (ISIC is a suite of utilities to exercise the stability of an IP Stack and its component stacks (TCP, UDP, ICMP et. al.) It generates piles of pseudo random packets of the target protocol. The packets be given tendancies to conform to. Ie 50% of the packets generated can have IP Options. 25% of the packets can be IP fragments... But the percentages are arbitrary and most of the packet fields have a configurable tendancy.)
>
> When  we send stream of packets  using the command  "tcpsic -s 10.10.10.10,23 -d 10.10.10.100 -I 100" ,our system hangs ,and we  observed that  the  code ( panic ("icmp len") )  highlighted  below was hit , when  we run the above test case
>
> What should be the correct behaviour?
> Could you please give your inputs or opinion on how to handle this case ?
>
> Thanks
> saritha
>
> Details of the Panic message
> ============================
> In  the file "src/sys/netinet/ip_icmp.c"
>
> /*
>  * Generate an error packet of type error
>  * in response to bad packet ip.
>  */
> void
> icmp_error(n, type, code, dest, destifp)
>  struct mbuf *n;
>  int type, code;
>  n_long dest;
>  struct ifnet *destifp;
>
> {
>  register struct ip *oip = mtod(n, struct ip *), *nip;
>  register unsigned oiplen = IP_VHL_HL(oip->ip_vhl) << 2;
>  register struct icmp *icp;
>  register struct mbuf *m;
>  unsigned icmplen;
>   .......
>   ..........
>
>     /*
>   * Now, copy old ip header (without options)
>   * in front of icmp message.
>     if (m->m_data - sizeof(struct ip) < m->m_pktdat)
>       panic("icmp len");                                                   //////////////////////////////////////////  This PANIC OCCURED when the test case was run  //////////////////////////////////
>
>  ..............
>  ............
>
> }
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
>



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