Hi all,
Recently,when I ported some linux drivers to genode, occasionally, there will be such an error "somebody tries to fake us!". To find the cause of the error,I analysed the communication between client and server.
First, client creats the connection to the server, then the server will creat a server object with an valid id, also an Ipc_gate object(binding to the entry_point thread) is created and the id is set as the gate-label. Last, the server returns the cap of the ipc_gate.
I grab the session capability the client obtained after the connection, and get the id（local name）of the session capability. Once I call the interface function the server provided, the id will be encapsulated into Message Register(mr[0]). When the server receives the requesting message, it will compare the id(the server recevied) and label of the gate. I tried to illustrate it by making a simple diagram.Is this correct?
Now I know the value of the id on client side is 0x14dc,the label of the gate is 0x14dc, but the id on server side is 0x4. My doubt is:where the object id could be tampered?
Thanks in advanced.
Hi,
On 10/08/2014 02:43 PM, li94575 wrote:
Hi all,
Recently,when I ported some linux drivers to genode, occasionally, there will be such an error "*somebody tries to fake us!*". To find the cause of the error,I analysed the communication between client and server.
First, client creats the connection to the server, then the server will creat a server object with an valid id, also an Ipc_gate object(binding to the entry_point thread) is created and the id is set as the gate-label. Last, the server returns the cap of the ipc_gate.
I grab the session capability the client obtained after the connection, and get the id（local name）of the session capability. Once I call the interface function the server provided, the id will be encapsulated into Message Register(mr[0]). When the server receives the requesting message, it will compare the id(the server recevied) and label of the gate. I tried to illustrate it by making a simple diagram.Is this correct?
Your analysis of the communication behavior is perfectly fine.
Now I know the value of the id on client side is 0x14dc,the label of the gate is 0x14dc, but the id on server side is 0x4. My doubt is:where the object id could be tampered?
I assume that your message buffer when sending a message to the server is corrupt, so that it contains a "0x4" as first word within the message. Although it is not impossible that we've a general bug in the base-foc code, we didn't observed such behavior in the past, though we test it heavily regularly. Therefore I think you've a memory corruption problem within your client, or did you also touched other code (e.g.: something in the parent tree of your client). Where is your connection initiated, within the BSS segment, heap, or stack?
Maybe you can provide some code snippet that helps to reproduce the problem?
Regards Stefan
Thanks in advanced.
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.cl...
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Thank you for your reply！
At 2014-10-14 19:08:17, "Stefan Kalkowski" <stefan.kalkowski@...1...> wrote:
Hi,
I assume that your message buffer when sending a message to the server is corrupt, so that it contains a "0x4" as first word within the message. Although it is not impossible that we've a general bug in the base-foc code, we didn't observed such behavior in the past, though we test it heavily regularly. Therefore I think you've a memory corruption problem within your client, or did you also touched other code (e.g.: something in the parent tree of your client). Where is your connection initiated, within the BSS segment, heap, or stack?
The location of the connection is at “.../ports-foc/src/Lib/L4lx/Genode_i2c.cc”, like this:
static I2C::Connection *i2c() { static bool initialized = false; static I2C::Connection *i = 0; if (!initialized) { try { static I2C::Connection t; i = &t; } catch(...) {} initialized = true; } return i; }
Maybe you can provide some code snippet that helps to reproduce the problem?
The frequency of this error is not very high, sometimes several times a day, sometimes not once a week. So, it is difficult to determine which part of the code causes the error. Ourselves also don't know how to reproduce the error. Now, the error is mainly printed by I2C driver, also by some other drivers,such as Modem driver. The client is l4android.
When the error occurs, there is a phenomenon that the ID on server side is always "0x4", no matter what value of the label is.
Regards Stefan
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.cl...
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-- Stefan Kalkowski Genode Labs
http://www.genode-labs.com/ · http://genode.org/
Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi,
On 10/17/2014 03:24 PM, li94575 wrote:
Thank you for your reply！
At 2014-10-14 19:08:17, "Stefan Kalkowski" <stefan.kalkowski@...1... mailto:stefan.kalkowski@...1...> wrote:
Hi,
I assume that your message buffer when sending a message to the server is corrupt, so that it contains a "0x4" as first word within the message. Although it is not impossible that we've a general bug in the base-foc code, we didn't observed such behavior in the past, though we test it heavily regularly. Therefore I think you've a memory corruption problem within your client, or did you also touched other code (e.g.: something in the parent tree of your client). Where is your connection initiated, within the BSS segment, heap, or stack?
The location of the connection is at “.../ports-foc/src/Lib/L4lx/Genode_i2c.cc”, like this:
static I2C::Connection *i2c() { static bool initialized = false; static I2C::Connection *i = 0; if (!initialized) { try { static I2C::Connection t; i = &t; } catch(...) {} initialized = true; } return i; }
Ok, if you use a Genode framework version prior to 14.02 (which is not recommended anyway!) the stack of the first thread in a task is fixed within the BSS segment. If you get a stack overflow it isn't detected, and memory corruption might occur. If you use a newer version the stack of the first thread lies within the threads context area, and stack overflows are detected. Then memory corruption, which I assume is the problem here, is caused probably by your own code.
To further debug that problem, you might use the kernel debugger of Fiasco.OC e.g. to set a watchpoint at the first word of the message buffer, to see what code might overwrite it. Of course, it is problematic to debug as long as the problem occurs sporadically.
When it comes to sporadic memory corruption, thread synchronization suggests itself. Is your program using multiple threads? Again you might use the kernel debugger to ensure the number of threads in your task.
Maybe you can provide some code snippet that helps to reproduce the problem?
The frequency of this error is not very high, sometimes several times a day, sometimes not once a week. So, it is difficult to determine which part of the code causes the error. Ourselves also don't know how to reproduce the error.Now, the error is mainly printed by I2C driver, also by some other drivers,such as Modem driver. The client is l4android.
I understand, so from my perspective probably the client side (l4android) is the problem, although the server side prints the error message. There are plenty possibilities to shoot oneself in the foot, when it comes to Linux kernel drivers using Genode device backends, and it's hard to give a general advice here. You've to ensure to fulfill the required sematic of the corresponding device class in the Linux kernel, e.g. with respect to SMP-safeness etc.. You've to ensure to always mask the interrupts in the kernel before doing a Genode IPC call, when the VCPU executing the Linux kernel code is doing the IPC by itself. Obvoiusly, you've to ensure that all threads: kernel's VCPU, as well as device backend threads are synchronized accordingly.
If you provide your full scenario: source code, run-script to reproduce the problem, as well as full log output of the error case, I might have a look at it.
Regards Stefan
When the error occurs, there is a phenomenon that the ID on server side is always "0x4", no matter what value of the label is.
Regards Stefan
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.cl...
genode-main mailing list genode-main@lists.sourceforge.net mailto:genode-main@...98....net https://lists.sourceforge.net/lists/listinfo/genode-main
-- Stefan Kalkowski Genode Labs
http://www.genode-labs.com/ · http://genode.org/
Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net mailto:genode-main@...134...et https://lists.sourceforge.net/lists/listinfo/genode-main
Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
The version we used now is 13.05, maybe that's the problem. But it will take some time to move existing drivers to the latest version of genode. If we finish the job, but the error still exists, I will ask again. Thank you so much.
At 2014-10-20 17:18:10, "Stefan Kalkowski" <stefan.kalkowski@...1...> wrote:
Hi,
On 10/17/2014 03:24 PM, li94575 wrote:
Thank you for your reply！
At 2014-10-14 19:08:17, "Stefan Kalkowski" <stefan.kalkowski@...1... mailto:stefan.kalkowski@...1...> wrote:
Hi,
I assume that your message buffer when sending a message to the server is corrupt, so that it contains a "0x4" as first word within the message. Although it is not impossible that we've a general bug in the base-foc code, we didn't observed such behavior in the past, though we test it heavily regularly. Therefore I think you've a memory corruption problem within your client, or did you also touched other code (e.g.: something in the parent tree of your client). Where is your connection initiated, within the BSS segment, heap, or stack?
The location of the connection is at “.../ports-foc/src/Lib/L4lx/Genode_i2c.cc”, like this:
static I2C::Connection *i2c() { static bool initialized = false; static I2C::Connection *i = 0; if (!initialized) { try { static I2C::Connection t; i = &t; } catch(...) {} initialized = true; } return i; }
Ok, if you use a Genode framework version prior to 14.02 (which is not recommended anyway!) the stack of the first thread in a task is fixed within the BSS segment. If you get a stack overflow it isn't detected, and memory corruption might occur. If you use a newer version the stack of the first thread lies within the threads context area, and stack overflows are detected. Then memory corruption, which I assume is the problem here, is caused probably by your own code.
To further debug that problem, you might use the kernel debugger of Fiasco.OC e.g. to set a watchpoint at the first word of the message buffer, to see what code might overwrite it. Of course, it is problematic to debug as long as the problem occurs sporadically.
When it comes to sporadic memory corruption, thread synchronization suggests itself. Is your program using multiple threads? Again you might use the kernel debugger to ensure the number of threads in your task.
Maybe you can provide some code snippet that helps to reproduce the problem?
The frequency of this error is not very high, sometimes several times a day, sometimes not once a week. So, it is difficult to determine which part of the code causes the error. Ourselves also don't know how to reproduce the error.Now, the error is mainly printed by I2C driver, also by some other drivers,such as Modem driver. The client is l4android.
I understand, so from my perspective probably the client side (l4android) is the problem, although the server side prints the error message. There are plenty possibilities to shoot oneself in the foot, when it comes to Linux kernel drivers using Genode device backends, and it's hard to give a general advice here. You've to ensure to fulfill the required sematic of the corresponding device class in the Linux kernel, e.g. with respect to SMP-safeness etc.. You've to ensure to always mask the interrupts in the kernel before doing a Genode IPC call, when the VCPU executing the Linux kernel code is doing the IPC by itself. Obvoiusly, you've to ensure that all threads: kernel's VCPU, as well as device backend threads are synchronized accordingly.
If you provide your full scenario: source code, run-script to reproduce the problem, as well as full log output of the error case, I might have a look at it.
Regards Stefan
When the error occurs, there is a phenomenon that the ID on server side is always "0x4", no matter what value of the label is.
Regards Stefan
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.cl...
genode-main mailing list genode-main@lists.sourceforge.net mailto:genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-- Stefan Kalkowski Genode Labs
http://www.genode-labs.com/ · http://genode.org/
Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net mailto:genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-- Stefan Kalkowski Genode Labs
http://www.genode-labs.com/ · http://genode.org/
Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-
li94575 -
Stefan Kalkowski