lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:	Tue, 10 Dec 2013 17:31:46 +0000
From:	Dave Martin <Dave.Martin@....com>
To:	Anurag Aggarwal <a.anurag@...sung.com>
Cc:	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Naveen Kumar <naveen.sel@...sung.com>,
	Narendra Meher <narendra.m1@...sung.com>,
	"nico@...aro.org" <nico@...aro.org>,
	Catalin Marinas <Catalin.Marinas@....com>,
	Will Deacon <Will.Deacon@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ashish Kalra <ashish.kalra@...sung.com>,
	"cpgs ." <cpgs@...sung.com>,
	"anurag19aggarwal@...il.com" <anurag19aggarwal@...il.com>,
	"naveenkrishna.ch@...il.com" <naveenkrishna.ch@...il.com>,
	Rajat Suri <rajat.suri@...sung.com>,
	Poorva Srivastava <poorva.s@...sung.com>,
	Mohammad Irfan Ansari <mohammad.a2@...sung.com>
Subject: Re: [PATCH V6] ARM : unwinder : Prevent data abort due to stack
 overflow

On Tue, Dec 10, 2013 at 03:54:42AM +0000, Anurag Aggarwal wrote:
> >Reviewed-by: Dave Martin <Dave.Martin@....com>
> >
> >I can confirm that the kernel "doesn't crash" with this applied, and
> >that backtracing at least partially works.  But this is not really
> >sufficient to demontrate that the now code works better than the old
> >code in corner cases (which is the point of the patch).
> >
> >Can you give details of what additional testing you have, or plan to
> >do?
> 
> We saw a data abort in unwinder for one of Samsung Project, during a
> Samsung Automation test case. 
> After that I created the initial the patch, and the data abort has not been
> seen till now.
> 
> Is it possible for you to give an idea on what other kind of additional testing 
> do you have in mind.

To be sure how the stack checking code is behaving, it would be good to
see the overflow check being hit.  With just a single test case, it's
possible that the bug is now hidden, rather than fixed.

You could try adding some debug printks to see how the backtrace fails.
You could also try adding a few hand-crafted assembler functions
with appropriate code and unwind directives to trigger different kinds
of backtrace failure.  You might have to add a way to artificially limit
sp_high to check the cases where you run out of stack in the middle of
popping multiple registers.

When thinking about this, I could not think of a good way to integrate
tests upstream without it being very invasive -- it may be best to keep
debug code separate unless you can see a clean way to merge it.


Cheers
---Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ