linux-kernel - Re: [RFD] Efficient unit test and fuzz tools for kernel/libc porting

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.20.1607201544220.12251@digraph.polyomino.org.uk>
Date:	Wed, 20 Jul 2016 15:47:35 +0000
From:	Joseph Myers <joseph@...esourcery.com>
To:	"Zhangjian (Bamvor)" <bamvor.zhangjian@...wei.com>
CC:	<linux-kernel@...r.kernel.org>, <linux-arch@...r.kernel.org>,
	<libc-alpha@...rceware.org>, <trinity@...r.kernel.org>,
	<syzkaller@...glegroups.com>, <aponomarenko@...alab.ru>,
	Jess Hertz <jesse.hertz@...group.trust>,
	Tim Newsham <tim.newsham@...group.trust>, <arnd@...db.dea>,
	<catalin.marinas@....com>, <broonie@...nel.org>,
	<maxim.kuvyrkov@...aro.org>, <ynorov@...iumnetworks.com>,
	<pinskia@...il.com>, <schwab@...e.de>, <agraf@...e.de>,
	<marcus.shawcroft@....com>, <dingtianhong@...wei.com>,
	<guohanjun@...wei.com>, <cuibixuan@...wei.com>,
	<lijinyue@...wei.com>, <lizefan@...wei.com>
Subject: Re: [RFD] Efficient unit test and fuzz tools for kernel/libc
 porting

On Wed, 6 Jul 2016, Zhangjian (Bamvor) wrote:

> correct or not. After learn and compare some fuzz tools, I feel that there is
> no such fuzz tools could help me. So, I wrote a new fuzz tools base on the
> trinity and it found several wrapper issues in glibc. I will first explain the
> different with existing fuzz tools and paste my propsosal in the end.

I'm not at all clear on whether any of the people working on AArch64 ILP32 
glibc have run the glibc testsuite and investigated the results in detail 
(the patch submissions have failed to include glibc testsuite results and 
have included bugs that would have been detected by the glibc testsuite).  
But, if you've found bugs in a new glibc port that were not detected by 
the existing testsuite, then tests for those bugs should be contributed to 
glibc (even if no existing port has those bugs, improving the test 
coverage is still a good idea).

-- 
Joseph S. Myers
joseph@...esourcery.com