On Fri, Nov 13, 2020 at 9:03 AM Alexei Starovoitov
<alexei.starovoitov@xxxxxxxxx> wrote:
>
> Linus,
> I think you might have an opinion about it.
> Please see commit log for the reason we need this fix.
Why is BPF doing this?
The thing is, if you care about the data after the strncpy, you should
be clearing it yourself.
The kernel "strncpy_from_user()" is *NOT* the same as "strncpy()",
despite the name. It never has been, and it never will be. Just the
return value being different should have given it away.
In particular, "strncpy()" is documented to zero-pad the end of the
area. strncpy_from_user() in contrast, is documented to NOT do that.
You cannot - and must not - depend on it.
If you want the zero-padding, you need to do it yourself. We're not
slowing down strncpy_from_user() because you want it, because NOBODY
ELSE cares, and you're depending on semantics that do not exist, and
have never existed.
So if you want padding, you do something like
long strncpy_from_user_pad(char *dst, const char __user *src, long count)
{
long res = strncpy_from_user(dst, src, count)
if (res >= 0)
memset(dst+res, 0, count-res);
return res;
}
because BPF is doing things wrong as-is, and the problem is very much
that BPF is relying on undefined data *after* the string.
And again - we're not slowing down the good cases just because BPF
depends on bad behavior.
You should feel bad.
Linus
