On 12/16/2010 12:19 AM, Andreas Dilger wrote:
> On 2010-12-15, at 13:52, Eric Dumazet wrote:
>> Le mercredi 15 dÃcembre 2010 Ã 21:33 +0100, Julia Lawall a Ãcrit :
>>> On Wed, 15 Dec 2010, Andreas Dilger wrote:
>>>> I thought my proposed solution was reasonable - add explicit padding fields where there are holes in the structure, which would be unused by the kernel, but since they are defined fields the compiler is obligated to initialize them.
>>>
>>> Is the presence of holes always apparent at the source code level?
>>> Or is it dependent on the compiler or target architecture?
>>
If you let the compiler have the driving sit. But if you take matter
to your own hand, and one should when dealing with external interfaces
that might get accessed from different compilers/languages.
so:
struct export_foo {
u32 m1;
u32 padding1;
u64 m2
....
} __attribute__((aligned(8),packed))
will make sure that even other compilers/versions will do the same
thing. Also the same rule for on the wire structures.
Just choose the biggest type you have in the structure and
specify that, which will make good code for most cases.
At the end this things depend on if sizeof(long) is 8 or 4
>> It depends on target architecture.
>>
>> This means doing a full review to add a named padding only for arches
>> that need it.
>
> There are automated tools like "pahole" (IIRC) that will report the presence
> of these structure holes. However, the memset(0) won't add itself to the code
> either (i.e. it needs an audit to determine if it is needed).
>
I agree. It is always good practice for public structures to be
considered more delicately. All padding should be spelled out.
Not only for security but for future compatibility and maintenance.
> Cheers, Andreas
>
>
Thanks
Boaz
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
