On Sep 19 2017, Jeff Law wrote:
> I know some early bits had hardcoded "8" in some places, but I didn't
> think those had ever been posted -- I may have given them to Matz for
> him to play with. Are you using those perhaps?
Yes, that looks like what's been happening.
Andreas.
--
Andreas Sch
On 09/19/2017 03:08 AM, Andreas Schwab wrote:
> On Sep 18 2017, Jeff Law wrote:
>
>> On 09/18/2017 10:09 AM, Andreas Schwab wrote:
>>> On Sep 18 2017, Jeff Law wrote:
>>>
Can you confirm if the probe was in the red zone vs the live areas on
the stack?
>>>
>>> It overwrites a nearby var
On Sep 18 2017, Jeff Law wrote:
> On 09/18/2017 10:09 AM, Andreas Schwab wrote:
>> On Sep 18 2017, Jeff Law wrote:
>>
>>> Can you confirm if the probe was in the red zone vs the live areas on
>>> the stack?
>>
>> It overwrites a nearby variable. sp + 8 happens to be the address of
>> file_ent
On 09/18/2017 10:09 AM, Andreas Schwab wrote:
> On Sep 18 2017, Jeff Law wrote:
>
>> Can you confirm if the probe was in the red zone vs the live areas on
>> the stack?
>
> It overwrites a nearby variable. sp + 8 happens to be the address of
> file_entries_new_size.
>
>0x000140e8 <+1172>:
On 09/18/2017 10:09 AM, Andreas Schwab wrote:
> On Sep 18 2017, Jeff Law wrote:
>
>> Can you confirm if the probe was in the red zone vs the live areas on
>> the stack?
>
> It overwrites a nearby variable. sp + 8 happens to be the address of
> file_entries_new_size.
>
>0x000140e8 <+1172>:
On Sep 18 2017, Jeff Law wrote:
> Can you confirm if the probe was in the red zone vs the live areas on
> the stack?
It overwrites a nearby variable. sp + 8 happens to be the address of
file_entries_new_size.
0x000140e8 <+1172>: mov r6, sp
0x000140ec <+1176>: add r3, r3, #7
On 09/18/2017 03:29 AM, Andreas Schwab wrote:
> On Jul 30 2017, Jeff Law wrote:
>
>> This patch introduces generic mechanisms to protect the dynamically
>> allocated stack space against stack-clash attacks.
>>
>> Changes since V2:
>>
>> Dynamic allocations can be emitted as unrolled inlined probe
On 09/18/2017 03:29 AM, Andreas Schwab wrote:
> On Jul 30 2017, Jeff Law wrote:
>
>> This patch introduces generic mechanisms to protect the dynamically
>> allocated stack space against stack-clash attacks.
>>
>> Changes since V2:
>>
>> Dynamic allocations can be emitted as unrolled inlined probe
On Mon, 18 Sep 2017, Andreas Schwab wrote:
> Does that work correctly when the VLA is smaller than the probe size
> (word_mode by default)? I see a failure in glibc on armv7 where
> ldconfig is using a zero-size VLA, which is invalid in C, but it could
> also end up using a VLA of size 1.
FWIW,
On 09/18/2017 03:29 AM, Andreas Schwab wrote:
> On Jul 30 2017, Jeff Law wrote:
>
>> This patch introduces generic mechanisms to protect the dynamically
>> allocated stack space against stack-clash attacks.
>>
>> Changes since V2:
>>
>> Dynamic allocations can be emitted as unrolled inlined probe
On Jul 30 2017, Jeff Law wrote:
> This patch introduces generic mechanisms to protect the dynamically
> allocated stack space against stack-clash attacks.
>
> Changes since V2:
>
> Dynamic allocations can be emitted as unrolled inlined probes or with a
> rotated loop. Blockage insns are also pro
On 08/18/2017 08:05 AM, Richard Biener wrote:
> On Mon, Jul 31, 2017 at 7:38 AM, Jeff Law wrote:
>>
>> This patch introduces generic mechanisms to protect the dynamically
>> allocated stack space against stack-clash attacks.
>>
>> Changes since V2:
>>
>> Dynamic allocations can be emitted as unrol
On Mon, Jul 31, 2017 at 7:38 AM, Jeff Law wrote:
>
> This patch introduces generic mechanisms to protect the dynamically
> allocated stack space against stack-clash attacks.
>
> Changes since V2:
>
> Dynamic allocations can be emitted as unrolled inlined probes or with a
> rotated loop. Blockage
On 07/13/2017 04:54 PM, Jeff Law wrote:
> On 07/12/2017 07:44 PM, Segher Boessenkool wrote:
>> I don't really see why this is so complicated, and why the rs6000
>> target changes (a later patch) are so big. Why isn't it just simple
>> patches to allocate_stack (and the prologue thing), that check
On 07/13/2017 04:54 PM, Jeff Law wrote:
> On 07/12/2017 07:44 PM, Segher Boessenkool wrote:
>>> /* The default is not to move the stack pointer. */
>>> +/* The default is not to move the stack pointer, unless we are using
>>> + stack clash prevention stack checking. */
>>> #ifndef STACK_CHECK
On 07/12/2017 07:44 PM, Segher Boessenkool wrote:
> On Tue, Jul 11, 2017 at 03:20:12PM -0600, Jeff Law wrote:
>> * conifg/mips/mips.c (mips_expand_prologue): Likewise.
>
> Typo ("conifg").
Will fix.
>
>> --- a/gcc/defaults.h
>> +++ b/gcc/defaults.h
>> @@ -1408,8 +1408,11 @@ see the files CO
On Tue, Jul 11, 2017 at 03:20:12PM -0600, Jeff Law wrote:
> * conifg/mips/mips.c (mips_expand_prologue): Likewise.
Typo ("conifg").
> --- a/gcc/defaults.h
> +++ b/gcc/defaults.h
> @@ -1408,8 +1408,11 @@ see the files COPYING3 and COPYING.RUNTIME
> respectively. If not, see
> #endif
>
>
17 matches
Mail list logo
