Problem with 'test-pci'

[Frank Kaiser]

Hello, Norman

 

Your guess is right: The page fault is caused while parsing the config file. The trigger is the method Xml_node::content(), which tries to copy the process’ filename from the config file, but the root cause is a nasty bug in function Genode::strncpy() which is used to obtain the filename. In the function’s first line Genode::strlen() is used to determine the length of the source string. In the given case, where the source is a tagged item of the config file having no null termination, strlen() runs thru the memory until it randomly finds a null character. For my opinion Genode::strncpy() is not allowed to parse the source string beyond the given size argument. Your suggestion of appending a null character to the config file (by the way: how is this to be done w/o corrupting the XML syntax?) heals a symptome, but does not solve the root cause.

I tried to fix Genode::strncpy() myself. Since there is no function Genode::strnlen(), I made the following change:

        size_t i = 0;

        while (i < size)

        {

            if (src[i] == 0)

            {

                size = i;

                break;

            }

            ++i;

        }

Interestingly this seem to trigger another problem. Now I get on all platforms the following two errors:

virtual Genode::Session_capability Genode::Core_parent::session(const char*, const char*): service_name="RM" arg="ram_quota=4K" not handled

virtual Genode::Session_capability Genode::Core_parent::session(const char*, const char*): service_name="PD" arg="ram_quota=4K" not handled

Could it be that there are already some workarounds for buggy Genode::strncpy(), which do not work anymore once the function is fixed?

 

Frank

> -----Original Message-----

> From: Norman Feske [mailto:norman.feske at ...1...]

> Sent: Sunday, August 02, 2009 5:38 PM

> To: Genode OS Framework Mailing List

> Subject: Re: Problem with 'test-pci'

> 

> Hello Frank,

> 

> I think, you hit an issue with the handling of boot modules on

> OKL4. In contrast to running on Qemu, on real hardware, the padding

> space between boot modules is not cleared on startup so that there is

> the chance that the actual data is followed by bit garbage. This is

> particularly annoying for the config file. We directly pass the locally

> mapped config file to our XML parser, which expects a null termination.

> However, without initial clearing of memory, there may be no such

> termination. So the XML parser continues parsing until it hits the

> following (not mapped) page. The next release will fix the problem by

> allowing a length limit to be specified to the XML parser. For now, you

> can use the short-term fix to manually append a zero character to your

> config file.

> 

> I would be grateful to know if I'm guessing right and if this quick fix

> works for you.

> 

> Regards

> Norman

> 

> Frank Kaiser wrote:

> > Hello

> >

> >

> >

> > As a preparation of a certain task I want to check the PCI resources of

> > my platform (IVI platform with Intel ATOM). For this purpose I built

> > Genode-on-OKL4, only consisting of a minimum driver set and the

> > /test-pci/ application. Running this image in /qemu/ looks good, but on

> > the IVI platform the /init/ process fails with a page fault before or

> > when starting the PCI driver which is the first entry in the /config/

> > file. The error message is:

> >

> > no RM attachment (READ pf_addr=6000 pf_ip=2001286 from 01)

> >

> > I have no clue what this message is trying to tell me. The given IP

> > points to the function /Genode::strncpy()/. I also wonder why the system

> > wants to read from virtual address 0x6000, because all modules are

> > allocated beginning at virtual address 0x02000000. Checking /init’s/

> > pagetable with OKL4’s KDB on /qemu/ shows a number of allocations below:

> >

> > ...

> >

> > I’d like to get some hints where to look into the code for finding the

> > cause of the problem. Since I cannot debug the platform, I probably have

> > to add more trace messages to get additonal information about what is

> > going on.

> >

> >

> >

> > Regards

> >

> > Frank

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20090803/8e0bffea/attachment.html>