[openbeosstorage] Re: ddm questions
- From: Tyler Dauwalder <tyler@xxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Fri, 24 Oct 2003 10:57:25 -0700
On 2003-10-24 at 04:39:41 [-0700], you wrote:
> 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.
Yes, but I was asking about copying back out (i.e. what the intended
semantics of the functions are).
> 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
Isn't there one declared in headers/private/kernel/vm.h right next to
user_strlcpy() and friends, and defined similarly in
src/kernel/core/arch/x86/arch_cpu.h, etc?
> - strlen() references the userland pointer in an unsafe environment -
> you must not use it on the original string
Oops, good point.
> - 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)
That would be fine with me (adding a buffer length parameter). Ingo?
> - 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
Damn. Another good point. Thanks.
> > + 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.
Take your pick. :-)
-Tyler
Other related posts:
