[openbeosstorage] Re: ddm questions

Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
> All right, I'm back in action. :-) I got some ddm questions:
> 
> + Do I need to copy out the data in the pointer arguments (all of 
> which are 
> names) for the 
> _kern_validate_set_partition_{name,content_name,type}() 
> functions? I can't really see any reason to other than truncating 
> long 
> names, but I was planning on returning B_NAME_TOO_LONG in those 
> instances 
> anyway.

You have to copy all pointer references from userland applications 
using the provided user_*() copy calls. The reason is simple: there is 
no guarantee that this memory stays valid during the execution. So if 
any kernel function has to access the memory the pointer points to, you 
need to copy it first into kernel space to make sure it stays valid.

But there are some problems in your code:
- there is apparently no user_strcpy() function in the kernel - you 
could either implement it (by calling user_memcpy()), or just call 
user_memcpy() directly - which is the preferred way, if you already 
know the length
- strlen() references the userland pointer in an unsafe environment - 
you must not use it on the original string - maybe a user_strdup() 
would be better instead of user_strcpy(). However, the best way to do 
this is to call strlen() in userland and pass the parameter length as 
an extra argument, and then use malloc() and user_memcpy() to copy the 
data - operating with userland strings is not really very safe (because 
they don't need to be null-terminated)
- you only check the return value of user_strlcpy() for >= max. name 
length - that's not correct; you also have to check it against values <
 B_OK - that's what it returns to report an error

> + Do we have a limit on the length of those parameter strings? I'm 
> currently assuming no.

I don't think there is a limit. However, to be more robust, we should 
introduce one, 32K or 64K.

Bye,
   Axel.

Other related posts: