On Thu, Nov 27, 2003 at 10:19:28PM +0000, Russell King wrote:
Note: we should really fix the generic strncpy() - there are places in
the kernel source which rely on the x86 strncpy() behaviour today (eg,
binfmt_*.c core file generation.)
Sorry, bad example. Hmm, from a glance around, it seems that all of
the places which use strncpy() implicitly zero the buffer prior to
using strncpy().
This means that the x86 strncpy is doing unnecessary zeroing. I do
remember Alan complaining about the last set of strlcpy() stuff
introducing information leaks - maybe those got fixed though.
Ok, I don't know where the kernel stands on this issue anymore.
Can someone definitively provide a statement of exactly what the
kernel expects of strncpy() ?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
Russell King wrote:
Sorry, bad example. Hmm, from a glance around, it seems that all of
the places which use strncpy() implicitly zero the buffer prior to
using strncpy().
This means that the x86 strncpy is doing unnecessary zeroing. I do
remember Alan complaining about the last set of strlcpy() stuff
introducing information leaks - maybe those got fixed though.
The problem is that most places you're filling in an array in a struct.
So even if you use strncpy() everywhere you can still get bitten if the
compiler inserts any padding for alignment on some architecture (since
even if you fully initialize each char[] array in the structure using
strncpy you might still leak info in padding bytes)
The safest thing to do in these cases is:
1. memset() the array before you start
2. strlcpy() for filling each char[] array (since strncpy would just
re-zero those bytes it's wasteful)
Yes, the full memset() is a small waste, but its safe. In 99% of these
cases we're talking about some weird ioctl() or something that's way off
the fast path anyways.
I pointed this out some months ago and someone (forgot who) replied that
there shouldn't be any padding in any struct exported from the kernel.
They added a compiler warning for structure padding in the -mm series for
a few days, but I guess it caused so many warnings that they took it right
out again, so I believe that there ARE plenty of places that user-visible
struct's get padded by the ABI of some platforms. If there's some difinitive
evidence that padding never happens I'd like to see it.
-Mitch