RE: [PATCH 2/4] Drivers: hv: Support the newly introduced KVPmessages in the driver

From: KY Srinivasan
Date: Thu Mar 15 2012 - 19:36:21 EST




> -----Original Message-----
> From: Dan Carpenter [mailto:dan.carpenter@xxxxxxxxxx]
> Sent: Monday, March 12, 2012 9:04 AM
> To: KY Srinivasan
> Cc: gregkh@xxxxxxxxxxxxxxxxxxx; ohering@xxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx; virtualization@xxxxxxxxxxxxxx; Alan Stern;
> devel@xxxxxxxxxxxxxxxxxxxxxx
> Subject: Re: [PATCH 2/4] Drivers: hv: Support the newly introduced KVP
> messages in the driver
>
> On Mon, Mar 12, 2012 at 12:36:53PM +0000, KY Srinivasan wrote:
> > Dan,
> > I am sorry for not being as precise as I should be:
> > utf16s_to_utf8s() takes two length parameters - the length of the utf16 string
> > that is to be converted and the second the length of the utf8 output string.
> > The windows host manipulates all string in utf16 encoding and the string we get
> > from the host is guaranteed to be less than or equal to MAX value that we have
> > including the terminating character. In my code, I simply pass the length of the
> > utf16 string as received from the host.
> >
> > The parameter that I am currently passing MAX length value is the "maxout"
> > parameter of the utf16s_utf8s() function. This by definition is the size of the
> > output buffer and in this case it happens to be MAX characters big.
> >
>
> I also think I'm not being as clear as I should... I understand
> that you trust the input; I'm say that for correctness sake you
> should specify a output size which leaves room for the NUL char.
>
> I can't say I know this code very well so I could be wrong, but it's
> what we do inside usb_string() for example. Can someone who knows
> the code check if we should do something like this:
>

Dan,

Sorry I could not get back to you earlier. You are right, in that I am trusting
the host! I am of the firm belief that in a virtualized environment, if you don't trust
the host, there is not a whole lot you can do in a guest! I have had this arguments
with other on this mailing list in the past. Having said that, I think we have spent more
time debating this than we should; your proposal is reasonable and I will go ahead and
re-spin those patches based on your comments. I should be posting them shortly.

Regards,

K. Y

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/