when to size_t for representing length instead of int ?

when to size_t for representing length instead of int ?

[none]

Hello,

I wanted to known the rules in coding guidelines concerning the use of 
size_t.
It seems the signed int type is used most of the time for representing 
string sizes, including in some parts written by Linus in /lib.
They’re can buffer overflows attack if ssize_t if larger than 
sizeof(int) (though I agree this isn’t the only way, but at least it´s 
less error prone).

So is it guaranteed for all current and future cpu architectures the 
Linux kernel support that ssize_t will always be equal to sizeof(int) ?

regards,

Re: when to size_t for representing length instead of int ?

[Al Viro]

On Fri, Oct 14, 2016 at 12:12:43AM +0200, none wrote:
> Hello,
> 
> I wanted to known the rules in coding guidelines concerning the use of
> size_t.
> It seems the signed int type is used most of the time for representing
> string sizes, including in some parts written by Linus in /lib.
> They’re can buffer overflows attack if ssize_t if larger than sizeof(int)
> (though I agree this isn’t the only way, but at least it´s less error
> prone).

Huh?  size_t is the type of sizoef result; ssize_t is its signed counterpart.

> So is it guaranteed for all current and future cpu architectures the Linux
> kernel support that ssize_t will always be equal to sizeof(int) ?

Of course it isn't.  Not true on any 64bit architecture we support...
What attacks are, in your opinion, enabled by that fact?  I'm sure that
libc (and C standard) folks would be very interested, considering that
e.g. strlen() is declared as function that takes a pointer to const char and
returns size_t...

Re: when to size_t for representing length instead of int ?

[none]

Le 2016-10-14 01:37, Al Viro a écrit :
> On Fri, Oct 14, 2016 at 12:12:43AM +0200, none wrote:
>> Hello,
>> 
>> I wanted to known the rules in coding guidelines concerning the use of
>> size_t.
>> It seems the signed int type is used most of the time for representing
>> string sizes, including in some parts written by Linus in /lib.
>> They’re can buffer overflows attack if ssize_t if larger than 
>> sizeof(int)
>> (though I agree this isn’t the only way, but at least it´s less error
>> prone).
> 
> Huh?  size_t is the type of sizoef result; ssize_t is its signed 
> counterpart.
With large strings, you can make buffer overflows by turning ints into 
negative values (this lead to cwe 195). However, they just crash the 
process and thus can’t be used for remote code execution. So as long as 
the truncation can’t lead to positive values there’s nothing to fear 
(which mean using in instead of size_t is acceptable if the machine 
isn’t big_endian).
> 
>> So is it guaranteed for all current and future cpu architectures the 
>> Linux
>> kernel support that ssize_t will always be equal to sizeof(int) ?
> 
> Of course it isn't.  Not true on any 64bit architecture we support...
No this is guaranteed, at least for amd64 because of -mcmodel=kernel
> What attacks are, in your opinion, enabled by that fact?  I'm sure that
> libc (and C standard) folks would be very interested, considering that
> e.g. strlen() is declared as function that takes a pointer to const 
> char and
> returns size_t...
Plenty  attacks which leads to plenty types of cwe (192 or 190)… 
Basically you feed the software with a string which can fit in size_t 
but not in an unsigned int.
I call this “size_t to positive int truncation” attacks (too bad that 
there’s no specific cwe for it). This rely on the following abi 
characteristics :
— being able to get a variable representing the length of a string 
(which uses size_t because of malloc) to a positive value of a variable 
which use the “int” type
— being on little endian machine makes the remote execution easier 
(because bettes every odd values which count the number of times of 
sizeof(int) the buffer overflow will be positive).

But the best illustration of this is probably myself being listed in the 
top ten of https://bounty.github.com because of that kind of bug in git 
:)
iii