[tickets] [opensaf:tickets] #40 IMM: Protect OI-handles against rapid switching of OI role.
- **status**: assigned --> unassigned - **Milestone**: 4.4.FC --> future --- ** [tickets:#40] IMM: Protect OI-handles against rapid switching of OI role.** **Status:** unassigned **Created:** Tue May 07, 2013 11:31 AM UTC by Anders Bjornerstedt **Last Updated:** Tue Sep 17, 2013 10:34 AM UTC **Owner:** Anders Bjornerstedt Migrated from: http://devel.opensaf.org/ticket/3092 -- This is related to the issues in #3072 and #3086. Repeated fast switching of OI role using the same OI handle can in theory result in imma library crashes due to a message being delivered to the "wrong" implementer. That is ImplementerSet??, implementerClear, implementerSet, etc. can result in a callback arriving on the handle when has changed its role from that which the callback was intended for. This ticket could be classed as a defect. The reason we class it as an enhancement is that we have not actually seen this happen yet and the fix is quite complex and thus not without risk. If a role switch occurs when there are messages backloged destined for the old role, but arriving to the OI in the new role, then this will cause the same symptom as the race fix in #3072. The backloged messages may actually reside in two places. Either backlogged in the incomming MDS buffer and not yet processed by the MDS thread, Or backlogged in the process internal IPC queue between the MDS thread and the application thread. The crash actually observed was in the MDS thread which indicates MDS backlog to the old role. We have not seen an incident of the second case, but it is sure to happen sooner or later since we have seen the first case. I propose to fix this issue by adding a generation counter to the client_node/handle. The generation counter is incremented each time a successful reply on implementerClear is received. Messages put to the IPC queue by the MDS thread will be stamped with the generation count at the time of MDS reception. On the other side, saImmOiDispatch() will check that the generation count of the message matches the generation count of the handle at the time of reception in the application thread. If it does not match then the message is discarded. On the server side, the IMMND will also have a generationCount associated with the connection. It will increment the generationCount when it is replying OK on an implementerClear for that connection. The IMMND sending an OI callback message to the client will stamp the message with the generationCount. The MDS thread in the client receiving the message will check that the generation count of the MDS message destined for OI has the same generation count as the generationCount of the handle. If not, the message is discarded. There should be no need for the OI to send the generationCount to the server. This since they are incremented on both sides by the same logical event, a successful implementerClear. There is of course the issue of ERR_TIMEOUT on implementerClear. If this happens then the only practical solution would be to mark the handle as stale and exposed. But this case should be rare. --- Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.-- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #40 IMM: Protect OI-handles against rapid switching of OI role.
- **status**: accepted --> assigned --- ** [tickets:#40] IMM: Protect OI-handles against rapid switching of OI role.** **Status:** assigned **Created:** Tue May 07, 2013 11:31 AM UTC by Anders Bjornerstedt **Last Updated:** Tue May 07, 2013 11:31 AM UTC **Owner:** Anders Bjornerstedt Migrated from: http://devel.opensaf.org/ticket/3092 -- This is related to the issues in #3072 and #3086. Repeated fast switching of OI role using the same OI handle can in theory result in imma library crashes due to a message being delivered to the "wrong" implementer. That is ImplementerSet??, implementerClear, implementerSet, etc. can result in a callback arriving on the handle when has changed its role from that which the callback was intended for. This ticket could be classed as a defect. The reason we class it as an enhancement is that we have not actually seen this happen yet and the fix is quite complex and thus not without risk. If a role switch occurs when there are messages backloged destined for the old role, but arriving to the OI in the new role, then this will cause the same symptom as the race fix in #3072. The backloged messages may actually reside in two places. Either backlogged in the incomming MDS buffer and not yet processed by the MDS thread, Or backlogged in the process internal IPC queue between the MDS thread and the application thread. The crash actually observed was in the MDS thread which indicates MDS backlog to the old role. We have not seen an incident of the second case, but it is sure to happen sooner or later since we have seen the first case. I propose to fix this issue by adding a generation counter to the client_node/handle. The generation counter is incremented each time a successful reply on implementerClear is received. Messages put to the IPC queue by the MDS thread will be stamped with the generation count at the time of MDS reception. On the other side, saImmOiDispatch() will check that the generation count of the message matches the generation count of the handle at the time of reception in the application thread. If it does not match then the message is discarded. On the server side, the IMMND will also have a generationCount associated with the connection. It will increment the generationCount when it is replying OK on an implementerClear for that connection. The IMMND sending an OI callback message to the client will stamp the message with the generationCount. The MDS thread in the client receiving the message will check that the generation count of the MDS message destined for OI has the same generation count as the generationCount of the handle. If not, the message is discarded. There should be no need for the OI to send the generationCount to the server. This since they are incremented on both sides by the same logical event, a successful implementerClear. There is of course the issue of ERR_TIMEOUT on implementerClear. If this happens then the only practical solution would be to mark the handle as stale and exposed. But this case should be rare. --- Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.-- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets