Re: Sound updating, security of strlcpy and a question on pci v

[Albert Cahalan]

Mitchell Blank Jr writes:
> Mikulas Patocka wrote:

>> What's the difference there? strlcpy always creates null-terminated
>> string, strncpy doesn't. strncpy in kernel (unlike user strncpy) does not
>> pad the whole destination buffer with zeros (see comment and
>> implementation in lib/string.c), so I don't see any point why strncpy
>> should be more secure.
>
> Not only that, I think the point is usually moot anyway.
> If you're filling in a structure to pass to userspace like:
>
>  struct whatever foo;
>  strncpy(foo.name, "My Driver", sizeof(foo.name));
>  foo.count = 1;
>  [...]
>
> then you're STILL probably at risk of data leakage if "struct whatever"
> requires padding on any architecture.  The real fix is to make sure
> that "foo" is explicitly zero'ed out first.  Then strlcpy-vs-strncpy
> becomes a non-issue.

gcc -Wpadding ...

If the compiler has to add padding, then the programmer
most likely messed up. The warning catches stupidity.
Necessary padding can be explicit.