Hello Genode, I have a question regarding Genode Label in Fiasco.OC kernel.
I noticed that Msgbuf_base::label() is the same as the return value of l4_ipc_wait (which is basically genode label):
L4_INLINE l4_msgtag_t l4_ipc_wait(l4_utcb_t *utcb, l4_umword_t *label, l4_timeout_t timeout) L4_NOTHROW;
label is described as following:
* \retval label Label assigned to the source object (IPC gate or IRQ).
But, I can not see any corresponding label in ipc call as we can see below:
L4_INLINE l4_msgtag_t l4_ipc_call(l4_cap_idx_t object, l4_utcb_t *utcb, l4_msgtag_t tag, l4_timeout_t timeout) L4_NOTHROW;
So, here goes the question: Since genode label is passed to the first data of Msgbuf_base::buf, does Fiasco.OC pickup this value and return when l4_ipc_wait function called?
Best regards, Jaeyong
Hi Jaeyong,
On 01/25/2013 12:19 PM, jaeyong yoo wrote:
Hello Genode, I have a question regarding Genode Label in Fiasco.OC kernel.
I noticed that Msgbuf_base::label() is the same as the return value of l4_ipc_wait (which is basically genode label):
L4_INLINE l4_msgtag_t l4_ipc_wait(l4_utcb_t *utcb, l4_umword_t *label, l4_timeout_ttimeout) L4_NOTHROW;
label is described as following:
* \retval label Label assigned to the source object (IPCgate or IRQ).
But, I can not see any corresponding label in ipc call as we can see below:
L4_INLINE l4_msgtag_t l4_ipc_call(l4_cap_idx_t object, l4_utcb_t *utcb, l4_msgtag_ttag, l4_timeout_t timeout) L4_NOTHROW;
So, here goes the question: Since genode label is passed to the first data of Msgbuf_base::buf, does Fiasco.OC pickup this value and return when l4_ipc_wait function called?
In short no. In fact the first item send in each message is the "local_name" of the Genode capability invoked. In general, this has nothing to do with the "label" term of Fiasco.OC.
I guess you are confused by the overloaded term "label" in the Fiasco.OC kernel. "Label" names two different things here. On the one hand there is the "label" specifier in the message descriptor that classifies the message, whether it is e.g.: normal-ipc, pagefault, exception,... . On the other hand there is a "label" assigned to each IPC gate, or IRQ kernel object. If you bind a thread to an IPC gate or IRQ object you can define a label associated to that object. Whenever the gate or IRQ object is invoked, the listening thread will receive that label in addition to the actual message. With other words, when sending a message through an IPC gate, the sender can't specify the label received on the other side. The label is already determined by the IPC gate that was used.
In Genode we use this label mechanism of the Fiasco.OC kernel to encode the Genode capability's "local_name" into it. For each new capability a new IPC gate is created. All messages in Genode are send through such IPC gates. When some client sends a message via a gate, it puts the capability's "local_name" as the first item into the message. On the other side, the server thread receives the message, and the associated label of the gate, which the client invoked. The server will compare the first item of the message - the "local_name"" - with the label received. If they are equal, the request is valid. By this protocol, you can detect fraud on the server side. Otherwise, some client could try to guess the "local_name" of some other session, it doesn't possess.
I hope this clarifies your initial question.
Regards Stefan
Best regards, Jaeyong
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
It indeed clarifies my question!
Thanks a lot. Jaeyong
On Wed, Jan 30, 2013 at 7:01 PM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:
Hi Jaeyong,
On 01/25/2013 12:19 PM, jaeyong yoo wrote:
Hello Genode, I have a question regarding Genode Label in Fiasco.OC kernel.
I noticed that Msgbuf_base::label() is the same as the return value of l4_ipc_wait (which is basically genode label):
L4_INLINE l4_msgtag_t l4_ipc_wait(l4_utcb_t *utcb, l4_umword_t *label, l4_timeout_ttimeout) L4_NOTHROW;
label is described as following:
* \retval label Label assigned to the source object (IPCgate or IRQ).
But, I can not see any corresponding label in ipc call as we can see
below:
L4_INLINE l4_msgtag_t l4_ipc_call(l4_cap_idx_t object, l4_utcb_t *utcb, l4_msgtag_ttag, l4_timeout_t timeout) L4_NOTHROW;
So, here goes the question: Since genode label is passed to the first data of Msgbuf_base::buf, does Fiasco.OC pickup this value and return when l4_ipc_wait function called?
In short no. In fact the first item send in each message is the "local_name" of the Genode capability invoked. In general, this has nothing to do with the "label" term of Fiasco.OC.
I guess you are confused by the overloaded term "label" in the Fiasco.OC kernel. "Label" names two different things here. On the one hand there is the "label" specifier in the message descriptor that classifies the message, whether it is e.g.: normal-ipc, pagefault, exception,... . On the other hand there is a "label" assigned to each IPC gate, or IRQ kernel object. If you bind a thread to an IPC gate or IRQ object you can define a label associated to that object. Whenever the gate or IRQ object is invoked, the listening thread will receive that label in addition to the actual message. With other words, when sending a message through an IPC gate, the sender can't specify the label received on the other side. The label is already determined by the IPC gate that was used.
In Genode we use this label mechanism of the Fiasco.OC kernel to encode the Genode capability's "local_name" into it. For each new capability a new IPC gate is created. All messages in Genode are send through such IPC gates. When some client sends a message via a gate, it puts the capability's "local_name" as the first item into the message. On the other side, the server thread receives the message, and the associated label of the gate, which the client invoked. The server will compare the first item of the message - the "local_name"" - with the label received. If they are equal, the request is valid. By this protocol, you can detect fraud on the server side. Otherwise, some client could try to guess the "local_name" of some other session, it doesn't possess.
I hope this clarifies your initial question.
Regards Stefan
Best regards, Jaeyong
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
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/
Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-
jaeyong yoo -
Stefan Kalkowski