* Gabriel Dos Reis:
>>> Still, it's certainly an improvement on the current
>>> situation and the cost is negligible compared to the call to the
>>> allocator. Since it's a security issue, some form of the patch should
>>> go in.
>>
>> Well, should I resubmit, with the fix for the problem buildin
On Sun, Dec 5, 2010 at 10:21 PM, Joseph S. Myers
wrote:
> On Sun, 5 Dec 2010, Richard Guenther wrote:
>
>> Ah, you're using intrinsics. I thought of re-using the saturating arithmetic
>> and types we have, thus basically do
>>
>> size = (unsigned sat int) count * 4;
>>
>> and defer optimal expa
On Sun, 5 Dec 2010, Richard Guenther wrote:
> Ah, you're using intrinsics. I thought of re-using the saturating arithmetic
> and types we have, thus basically do
>
> size = (unsigned sat int) count * 4;
>
> and defer optimal expansion to an optab. It of course requires saturating
> arithmeti
On Sun, Dec 5, 2010 at 6:49 PM, Chris Lattner wrote:
>
> On Dec 5, 2010, at 3:19 AM, Richard Guenther wrote:
>
>>> $ clang t.cc -S -o - -O3 -mkernel -fomit-frame-pointer -mllvm
>>> -show-mc-encoding
>>> .section __TEXT,__text,regular,pure_instructions
>>> .globl __Z4testl
>>
On Dec 5, 2010, at 9:49 AM, Chris Lattner wrote:
>
> On Dec 5, 2010, at 3:19 AM, Richard Guenther wrote:
>
>>> $ clang t.cc -S -o - -O3 -mkernel -fomit-frame-pointer -mllvm
>>> -show-mc-encoding
>>> .section__TEXT,__text,regular,pure_instructions
>>> .globl __Z4testl
>>>
On Dec 5, 2010, at 3:19 AM, Richard Guenther wrote:
>> $ clang t.cc -S -o - -O3 -mkernel -fomit-frame-pointer -mllvm
>> -show-mc-encoding
>>.section__TEXT,__text,regular,pure_instructions
>>.globl __Z4testl
>>.align 4, 0x90
>> __Z4testl:
On Sun, Dec 5, 2010 at 8:56 AM, Chris Lattner wrote:
>
> On Dec 4, 2010, at 5:22 AM, Florian Weimer wrote:
>
>> * Joe Buck:
>>
>>> It's wasted code if the multiply instruction detects the overflow.
>>> It's true that the cost is small (maybe just one extra instruction
>>> and the same number of te
On Dec 4, 2010, at 5:22 AM, Florian Weimer wrote:
> * Joe Buck:
>
>> It's wasted code if the multiply instruction detects the overflow.
>> It's true that the cost is small (maybe just one extra instruction
>> and the same number of tests, maybe one more on architectures where you
>> have to load
On Sat, Dec 4, 2010 at 7:22 AM, Florian Weimer wrote:
> * Joe Buck:
>
>> It's wasted code if the multiply instruction detects the overflow.
>> It's true that the cost is small (maybe just one extra instruction
>> and the same number of tests, maybe one more on architectures where you
>> have to lo
* Joe Buck:
> It's wasted code if the multiply instruction detects the overflow.
> It's true that the cost is small (maybe just one extra instruction
> and the same number of tests, maybe one more on architectures where you
> have to load a large constant), but it is slightly worse code than what
On Thu, Dec 02, 2010 at 02:47:30PM -0800, Gabriel Dos Reis wrote:
> On Thu, Dec 2, 2010 at 2:20 PM, Joe Buck wrote:
> > On Wed, Dec 01, 2010 at 10:26:58PM -0800, Florian Weimer wrote:
> >> * Chris Lattner:
> >>
> >> > On overflow it just forces the size passed in to operator new to
> >> > -1ULL, w
On Thu, Dec 2, 2010 at 2:20 PM, Joe Buck wrote:
> On Wed, Dec 01, 2010 at 10:26:58PM -0800, Florian Weimer wrote:
>> * Chris Lattner:
>>
>> > On overflow it just forces the size passed in to operator new to
>> > -1ULL, which throws bad_alloc.
>>
>> This is also what my patch tries to implement.
>
On Wed, Dec 01, 2010 at 10:26:58PM -0800, Florian Weimer wrote:
> * Chris Lattner:
>
> > On overflow it just forces the size passed in to operator new to
> > -1ULL, which throws bad_alloc.
>
> This is also what my patch tries to implement.
Yes, but Chris's code just checks the overflow of the mu
* Chris Lattner:
> On overflow it just forces the size passed in to operator new to
> -1ULL, which throws bad_alloc.
This is also what my patch tries to implement.
On Wed, Dec 1, 2010 at 5:36 PM, Chris Lattner wrote:
>
> On Nov 30, 2010, at 3:12 PM, Joe Buck wrote:
>
>> On Tue, Nov 30, 2010 at 01:49:23PM -0800, Gabriel Dos Reis wrote:
>>> The existing GCC behaviour is a bit more perverse than the
>>> C malloc() case as in
>>>
>>> new T[n]
>>>
>>> there
On Nov 30, 2010, at 3:12 PM, Joe Buck wrote:
> On Tue, Nov 30, 2010 at 01:49:23PM -0800, Gabriel Dos Reis wrote:
>> The existing GCC behaviour is a bit more perverse than the
>> C malloc() case as in
>>
>> new T[n]
>>
>> there is no multiplication that could be credited to careless progra
On Tue, Nov 30, 2010 at 01:49:23PM -0800, Gabriel Dos Reis wrote:
> The existing GCC behaviour is a bit more perverse than the
> C malloc() case as in
>
>new T[n]
>
> there is no multiplication that could be credited to careless programmer.
> The multiplication is introduced by GCC.
...
On Tue, Nov 30, 2010 at 3:38 PM, Joseph S. Myers
wrote:
> On Tue, 30 Nov 2010, Florian Weimer wrote:
>
>> Mozilla seems to receive a report of an exploitable operator new[]
>> overflow every couple of months now. Obviously, this is not good.
>>
>> What is necessary so that GCC can fix this code g
On Tue, 30 Nov 2010, Florian Weimer wrote:
> Mozilla seems to receive a report of an exploitable operator new[]
> overflow every couple of months now. Obviously, this is not good.
>
> What is necessary so that GCC can fix this code generation issue?
> I've created a patch, together with a test c
Mozilla seems to receive a report of an exploitable operator new[]
overflow every couple of months now. Obviously, this is not good.
What is necessary so that GCC can fix this code generation issue?
I've created a patch, together with a test case, but it has not been
approved, nor have I been tol
20 matches
Mail list logo
