• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 729 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DSPLink internals: accessing a user space pointer from within the kernel driver

Piotr Pydych1
Prodigy 30 points

Hello,

I have a question concerning the DSPLink. To be more precise, this is about accessing (dereferencing) a user space pointer from within the DSPLink driver (Linux kernel space). Let's look on the CMD_MSGQ_LOCATE. The MSGQ_Queue *msgqQueue is such a pointer. Created and assigned in the user space, the pointer is subsequently passed to the driver and is finally dereferenced in ZCPYMQT_locate. On the way, DRV_Ioctl copies the command's arguments with the copy_from_user. But no conversion is done to the pointer itself - it is just copied byte-by-byte. How is it done in DSPLink, that the pointer (address) from the user space is still valid and can be dereferenced in the kernel space? Shouldn't it be marshalled with an extra copy_from_user/get_user, etc.? The platform is OMAP L138.

 

Thank you in advance for any info on it,
Piotr.

 

  • 0
    TI__Genius 12865 points

    Hi Piotr,

    I think you are right that extra calls to copy_from_user should ideally be done on 'embedded' pointers, so that it can make sure that the memory is accessible and provide more secure memory access. For whatever reason the existing code is not doing it, so it is not as robust as it should be. However, the code should still be able to access the correct values. Are you hitting a problem with this?

    Best regards,

    Vincent 

  • 0 in reply to Vincent W.
    Prodigy 30 points

    Hello Vincent,
    thank you for your quick response.

    It's a little bit strange, but what I observe in my application is that the correct value of 0, assigned to the *msgqQueue in the ZCPYMQT_locate, sometimes "resets" to its initial value of MSGQ_INVALIDMSGQ. The resetting happens in the vicinity of the ioctl call in the drv_api.c (to be more precise, I see it in the user space, just after the ioctl call finishes). It's important that the MSGQ_locate mechanism usually works with no issues and the resetting described here is pretty rare and happens in c.a. one occurence out of a thousand trials. This is why I am considering, among other scenarios, whether the method of assigning and returning the *msgqQueue is reliable. Have you ever faced with such a problem?

    My application bases with no significant changes on the \dsplink\gpp\src\samples\message/message.c example.

    With regards,
    Piotr.

  • 0 in reply to Piotr Pydych1
    TI__Genius 12865 points

    Hi Piotr,

    I haven't seen reports of such a problem before. Are you saying that immediately after the ioctl call, you see the correct value of 0? At what point does the value change? If it returned the right value and it changes later during execution then I doubt it is anything to do with copy_from_user/to_user. 

    I am looking at ZCPYMQT_locate and I see that msgqQueue can return MSGQ_INVALIDMSGQ for various reasons, e.g. queue not found, or DSP not ready.  Have you verified the value of msgqQueue at the end of ZCPYMQT_locate to make sure it is not returning MSGQ_INVALIDMSGQ? Maybe that is the 'correct' value after all.

    Best regards,

    Vincent

  • 0 in reply to Vincent W.
    Prodigy 30 points

    Hello,

    unfortunately yes - the issue is observed "immediately" after the ioctl returns. I verified the value of *msgqQueue at the end of ZCPYMQT_locate. DSP responses properly with the value of 0, and the value is assigned in ZCPYMQT_locate and then returned to the upper layers. I also checked it at the end of LDRV_MSGQ_locate, PMGR_MSGQ_locate, DRV_CallAPI and DRV_Ioctl and it is still correct.
    It seems that I have to do more investigation now.
    Anyway, thank you for your response!