* Ingo Molnar wrote:
> Yes, -Ow would be very useful, if it can 'guarantee' that no false negatives
> slip
> through:
> [...]
> This way no undeterministic, random, uninitialized (and worst-case: attacker
> controlled) values can ever enter the program flow (from the stack) [...]
Note that
* Jakub Jelinek wrote:
> On Thu, Mar 03, 2016 at 02:47:16PM +0100, Ingo Molnar wrote:
> > I tried to distill a testcase out of it, and the following silly hack seems
> > to
> > trigger it:
>
> ...
>
> This is a known issue, which we don't have a solution for yet.
> The thing is, GCC has 2 un
* Jakub Jelinek wrote:
> On Thu, Mar 03, 2016 at 02:47:16PM +0100, Ingo Molnar wrote:
> > I tried to distill a testcase out of it, and the following silly hack seems
> > to
> > trigger it:
>
> ...
>
> This is a known issue, which we don't have a solution for yet.
> The thing is, GCC has 2 un
On Thu, Mar 03, 2016 at 02:47:16PM +0100, Ingo Molnar wrote:
> I tried to distill a testcase out of it, and the following silly hack seems
> to
> trigger it:
...
This is a known issue, which we don't have a solution for yet.
The thing is, GCC has 2 uninitialized warning passes, one is done
very
* Jakub Jelinek wrote:
> On Thu, Mar 03, 2016 at 02:24:34PM +0100, Ingo Molnar wrote:
> > 6 hours of PeterZ time translates to quite a bit of code restructuring
> > overhead to
> > eliminate false positive warnings...
>
> I'll file a bugzilla enhancement request for this (with new attribute),
* Ingo Molnar wrote:
> So it's all highly inefficient and fragile.
>
> There's also another cost, the cost of finding the bugs themselves - for
> example
> here's a recent upstream kernel fix:
>
> commit e01d8718de4170373cd7fbf5cf6f9cb61cebb1e9
> Author: Peter Zijlstra
> Date: Wed J
On Thu, Mar 03, 2016 at 02:24:34PM +0100, Ingo Molnar wrote:
> 6 hours of PeterZ time translates to quite a bit of code restructuring
> overhead to
> eliminate false positive warnings...
I'll file a bugzilla enhancement request for this (with new attribute),
perhaps we could do it in FRE that is
* Jakub Jelinek wrote:
> On Thu, Mar 03, 2016 at 01:19:44PM +0100, Ingo Molnar wrote:
> > struct sigaction sa;
> >
> > ...
> >
> > sigfillset(&sa.sa_mask);
> > sa.sa_sigaction = segfault_handler;
> > sigaction(SIGSEGV, &sa, NULL);
> >
> > ... which uninitia
On Thu, Mar 03, 2016 at 01:19:44PM +0100, Ingo Molnar wrote:
> struct sigaction sa;
>
> ...
>
> sigfillset(&sa.sa_mask);
> sa.sa_sigaction = segfault_handler;
> sigaction(SIGSEGV, &sa, NULL);
>
> ... which uninitialized sa.sa_flags field GCC merrily accepted
* Arnaldo Carvalho de Melo wrote:
> Em Wed, Mar 02, 2016 at 02:21:27PM +0100, Peter Zijlstra escreveu:
> > On Wed, Mar 02, 2016 at 10:03:50AM -0300, Arnaldo Carvalho de Melo wrote:
> > > > Would not something like:
> > > >
> > > > sa = (struct sigaction){
> > > > .sa_sig
Em Wed, Mar 02, 2016 at 02:21:27PM +0100, Peter Zijlstra escreveu:
> On Wed, Mar 02, 2016 at 10:03:50AM -0300, Arnaldo Carvalho de Melo wrote:
> > > Would not something like:
> > >
> > > sa = (struct sigaction){
> > > .sa_sigaction = segfault_handler,
> > > };
> > > sigfillset(&sa.
On Wed, Mar 02, 2016 at 10:03:50AM -0300, Arnaldo Carvalho de Melo wrote:
> > Would not something like:
> >
> > sa = (struct sigaction){
> > .sa_sigaction = segfault_handler,
> > };
> > sigfillset(&sa.sa_mask);
> >
> > Be better?
>
> I thought about that, but isn't that s
Em Wed, Mar 02, 2016 at 01:59:01PM +0100, Peter Zijlstra escreveu:
> On Wed, Mar 02, 2016 at 12:55:22PM +, Colin King wrote:
> > From: Colin Ian King
> >
> > The sa_flags field is not being initialized, so a garbage value is
> > being passed to sigaction. Initialize it to zero.
> >
> > Sign
Em Wed, Mar 02, 2016 at 12:55:22PM +, Colin King escreveu:
> From: Colin Ian King
>
> The sa_flags field is not being initialized, so a garbage value is
> being passed to sigaction. Initialize it to zero.
>
> Signed-off-by: Colin Ian King
Thanks, applied.
- Arnaldo
On Wed, Mar 02, 2016 at 12:55:22PM +, Colin King wrote:
> From: Colin Ian King
>
> The sa_flags field is not being initialized, so a garbage value is
> being passed to sigaction. Initialize it to zero.
>
> Signed-off-by: Colin Ian King
> ---
> tools/perf/arch/x86/tests/rdpmc.c | 1 +
> 1
15 matches
Mail list logo
