Subject: Re: Sound updating, security of strlcpy and a question on pci v
	unload
From: Albert Cahalan <albert@users.sf.net>
To: linux-kernel <linux-kernel@vger.kernel.org>
Cc: mitch@sfgoth.com
Content-Type: text/plain
Organization: 
Message-Id: <1058018597.749.1317.camel@cube>
Mime-Version: 1.0
Date: 12 Jul 2003 10:03:17 -0400
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1244
Lines: 35

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.


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