I have noticed this topic in history of gcc ml, how is that going with
this feature?
I have much interest in this feature and am trying to do sth in these days.
There are some questions about the design you mentioned.
As my understanding, a single gimple pass is not enough for safestack,
for exa
I have noticed this topic in history of gcc ml, how is that going with
this feature?
I have much interest in this feature and am trying to do sth in these days.
There are some questions about the design you mentioned.
As my understanding, a single gimple pass is not enough for safestack,
for exa
Hi,
On Tue, 10 May 2016, Szabolcs Nagy wrote:
> setjmp is defined so that the compiler can treat it
> specially and the caller has to make sure certain
> objects are volatile, cannot appear in arbitrary
> places (e.g. in the declaration of a vla), longjmp
> must be in same thread etc.
>
> all th
On Mon, 2016-05-09 at 12:25 -0700, Ian Lance Taylor wrote:
> On Fri, May 6, 2016 at 10:42 PM, Rich Felker wrote:
> >
> > The *context APIs are deprecated and I'm not sure they're worth
> > supporting with this. It would be a good excuse to get people to stop
> > using them.
>
> The gccgo library
On 09/05/16 22:45, Michael Matz wrote:
> On Mon, 9 May 2016, Rich Felker wrote:
>
>>> Done. I never understood why they left in the hugely unuseful
>>> {sig,}{set,long}jmp() but removed the actually useful *context()
>>> (amended somehow like above).
>>
>> Because those are actually part of the
On Mon, 9 May 2016, Michael Matz wrote:
> Sure. Same QoI bug in my book. (And I'm not motivated enough to find out
> if the various C standards weren't just following POSIX whe setjmp was
> included, or really the other way around).
Standards for setjmp and longjmp date back at least as far a
Hi,
On Mon, 9 May 2016, Rich Felker wrote:
> > Done. I never understood why they left in the hugely unuseful
> > {sig,}{set,long}jmp() but removed the actually useful *context()
> > (amended somehow like above).
>
> Because those are actually part of the C language
Sure. Same QoI bug in my
On Mon, May 9, 2016 at 2:03 PM, Joel Sherrill wrote:
>
> On 5/9/2016 3:41 PM, Ian Lance Taylor wrote:
>>
>> On Mon, May 9, 2016 at 1:07 PM, Joel Sherrill
>> wrote:
>>>
>>>
>>> One complication on RTEMS which is a single process, multi-threaded RTOS
>>> is that we can no longer check the stack bou
On 5/9/2016 3:41 PM, Ian Lance Taylor wrote:
On Mon, May 9, 2016 at 1:07 PM, Joel Sherrill wrote:
One complication on RTEMS which is a single process, multi-threaded RTOS
is that we can no longer check the stack bounds. For threads, we know
where the stack memory is and the range for each th
On Mon, May 09, 2016 at 10:03:02PM +0200, Michael Matz wrote:
> Hi,
>
> On Mon, 9 May 2016, Rich Felker wrote:
>
> > > > The *context APIs are deprecated and I'm not sure they're worth
> > > > supporting with this. It would be a good excuse to get people to
> > > > stop using them.
> > >
> > >
On Mon, May 9, 2016 at 1:07 PM, Joel Sherrill wrote:
>
> One complication on RTEMS which is a single process, multi-threaded RTOS
> is that we can no longer check the stack bounds. For threads, we know
> where the stack memory is and the range for each thread. For ucontext_t,
> it seems this knowl
On 5/9/2016 3:03 PM, Michael Matz wrote:
Hi,
On Mon, 9 May 2016, Rich Felker wrote:
The *context APIs are deprecated and I'm not sure they're worth
supporting with this. It would be a good excuse to get people to
stop using them.
How? POSIX decided to remove the facilities without any ade
On 5/9/2016 2:45 PM, Ian Lance Taylor wrote:
On Mon, May 9, 2016 at 12:41 PM, Joel Sherrill
wrote:
On 5/9/2016 2:25 PM, Ian Lance Taylor wrote:
On Fri, May 6, 2016 at 10:42 PM, Rich Felker wrote:
The *context APIs are deprecated and I'm not sure they're worth
supporting with this. It w
Hi,
On Mon, 9 May 2016, Rich Felker wrote:
> > > The *context APIs are deprecated and I'm not sure they're worth
> > > supporting with this. It would be a good excuse to get people to
> > > stop using them.
> >
> > How? POSIX decided to remove the facilities without any adequate
> > replacem
On Mon, May 9, 2016 at 12:48 PM, Joel Sherrill
wrote:
>
> On 5/9/2016 2:45 PM, Ian Lance Taylor wrote:
>>
>> On Mon, May 9, 2016 at 12:41 PM, Joel Sherrill
>> wrote:
>>>
>>>
>>> On 5/9/2016 2:25 PM, Ian Lance Taylor wrote:
On Fri, May 6, 2016 at 10:42 PM, Rich Felker wrote:
>
On Mon, May 9, 2016 at 12:41 PM, Joel Sherrill
wrote:
>
> On 5/9/2016 2:25 PM, Ian Lance Taylor wrote:
>>
>> On Fri, May 6, 2016 at 10:42 PM, Rich Felker wrote:
>>>
>>>
>>> The *context APIs are deprecated and I'm not sure they're worth
>>> supporting with this. It would be a good excuse to get p
On Mon, May 9, 2016 at 12:35 PM, Rich Felker wrote:
> On Mon, May 09, 2016 at 09:02:33PM +0200, Michael Matz wrote:
>> Hi,
>>
>> On Sat, 7 May 2016, Rich Felker wrote:
>>
>> > > > * sigaltstack and swapcontext are broken too.
>> > >
>> > > We have prototype that supports swapcontext that we're hap
On 5/9/2016 2:25 PM, Ian Lance Taylor wrote:
On Fri, May 6, 2016 at 10:42 PM, Rich Felker wrote:
The *context APIs are deprecated and I'm not sure they're worth
supporting with this. It would be a good excuse to get people to stop
using them.
The gccgo library uses them, because there is n
On Mon, May 09, 2016 at 09:02:33PM +0200, Michael Matz wrote:
> Hi,
>
> On Sat, 7 May 2016, Rich Felker wrote:
>
> > > > * sigaltstack and swapcontext are broken too.
> > >
> > > We have prototype that supports swapcontext that we're happy to
> > > release, but it clearly requires more work bef
On Fri, May 6, 2016 at 10:42 PM, Rich Felker wrote:
>
> The *context APIs are deprecated and I'm not sure they're worth
> supporting with this. It would be a good excuse to get people to stop
> using them.
The gccgo library uses them, because there is no working alternative.
In general coroutine
Hi,
On Sat, 7 May 2016, Rich Felker wrote:
> > > * sigaltstack and swapcontext are broken too.
> >
> > We have prototype that supports swapcontext that we're happy to
> > release, but it clearly requires more work before being ready to merge
> > upstream.
>
> The *context APIs are deprecated
* Rich Felker:
> On Wed, Apr 20, 2016 at 06:09:54PM +0200, Volodymyr Kuznetsov wrote:
>> We have prototype that supports swapcontext that we're happy to
>> release, but it clearly requires more work before being ready to merge
>> upstream.
>
> The *context APIs are deprecated and I'm not sure they
On Wed, Apr 20, 2016 at 06:09:54PM +0200, Volodymyr Kuznetsov wrote:
> On Wed, Apr 20, 2016 at 4:54 PM, Szabolcs Nagy wrote:
> > On 13/04/16 14:01, Cristina Georgiana Opriceana wrote:
> >> I bring to your attention SafeStack, part of a bigger research project
> >> - CPI/CPS [1], which offers compl
On 04/13/2016 07:01 AM, Cristina Georgiana Opriceana wrote:
Hello,
I bring to your attention SafeStack, part of a bigger research project
- CPI/CPS [1], which offers complete protection against stack-based
control flow hijacks. I am interested in developing SafeStack for GCC
and I would like to
On Wed, Apr 20, 2016 at 4:54 PM, Szabolcs Nagy wrote:
> On 13/04/16 14:01, Cristina Georgiana Opriceana wrote:
>> I bring to your attention SafeStack, part of a bigger research project
>> - CPI/CPS [1], which offers complete protection against stack-based
>> control flow hijacks.
>
> i think it do
On 13/04/16 14:01, Cristina Georgiana Opriceana wrote:
> I bring to your attention SafeStack, part of a bigger research project
> - CPI/CPS [1], which offers complete protection against stack-based
> control flow hijacks.
i think it does not provide complete protection.
it cannot instrument the c
On Wed, 13 Apr 2016, Cristina Georgiana Opriceana wrote:
> Hello,
>
> I bring to your attention SafeStack, part of a bigger research project
> - CPI/CPS [1], which offers complete protection against stack-based
> control flow hijacks. I am interested in developing SafeStack for GCC
> and I would
Hello,
I bring to your attention SafeStack, part of a bigger research project
- CPI/CPS [1], which offers complete protection against stack-based
control flow hijacks. I am interested in developing SafeStack for GCC
and I would like to ask for your feedback on this proposal.
SafeStack is a secur
28 matches
Mail list logo
